What is this Process and Why is it Running【一】

本文解析了多个常见的电脑进程,如MsMpeng.exe、WindowsShellExperienceHost等,提供了识别和解决异常进程的方法,包括更新、配置调整和安全检查。

在电脑被木马攻击之后一般情况下会产生与原有进程相似度极高的两个及以上进程,为了快速的解决木马, 就要能尽最快速度分辨出哪些进程是正常的,哪些是不正常的。

提出一个通用的解决办法,就是当找到相应的木马进程之后,可以尝试对某一个甚至某几个进程进行结束进程树操作,然后删除服务端和注册表程序。

MsMpeng.exe进程

此进程是微软自家安全软件Microsoft security Essential和windows Defender的主要进程,是Microsoft windows Defender Antispyware的简称。

WindowsDefender(原名WindowsAntispyware)是微软出品的一款反间谍软件的产品,能帮你检查和清除系统西面的间谍软件和广告及其他具有潜在危险性的软件,WindowsDefender只适合再基于NT技术的Windows2000以上的系统中使用。

卸载办法

卸载MsE(Microsoft security Essentials)

  1. 在系统盘中找到Backup文件,此文件下有一个mp_ambits文件和msse文件,将这两个文件卸载;
  2. 进入控制面板中的删除程序,找到Microsoft security Essentials的项目,卸载;
  3. 或者直接对此进程进行操作,选中进行全盘扫描,处理100%CPU占用的故障。

Windows Shell Experience Host

此进程是管理Metro系统界面以及系统特效的进程,能够处理许多与Windows小程序相关的图形元素,他处理诸如开始菜单、通知的视觉效果甚至任务栏透明度等元素。

一般正常情况下Windows Shell Experience Host的CPU和内存使用率是非常低的,也会自动回收系统资源,但有时候会出现异常,长时间保持比较高的CPU和内存使用率。

修复异常	
  1. 执行Windows的更新,有可能是是旧版本的 Bug,新版本肯定会有相应的补丁;
  2. 关闭壁纸自动切换;
  3. 取消自动选取主题色;
  4. 关闭Windows动画和透明效果.

IAStorDataSvc

无威胁文件,属于Intel Corporation,此进程一般都是驱动程序版本有问题

不一定最新的驱动就一定不会出问题,通常最终问题的解决都是靠旧版本的驱动去覆盖新版本。

CPU占用过高

http://www.111cn.net/office/194/59816.htm为解决办法

Antimalware Service Executable

此进程是微软杀毒软件Windows Defender的相关系统进程,详细名称为MsMpEng.exe,可以对进程选择转到详细信息

如果开机占用系统资源较高,一半是因为它在扫描硬盘文件所致,用于移除、隔离和预防间谍软件等。

开机CPU占用太高

正常情况下我们不能结束这些进程,但是我们可以设置Windows Defender扫描时排除欸系统盘,以及相关文件:

  1. 排除扫描非系统盘,打开Windows Defender,点击设置,切换到排除的文件和位置选项,通过浏览添加的方式将非系统盘从自动扫描中排除;
  2. 停用Windows Defender,在设置界面,管理员权限下取消启动该应用

ChsIME.exe

The process know as Microsoft IME belongs to software Microsoft Windows Operating System by Microsoft.(此进程被称为微软输入法,属于Windows操作系统)

原始ChsIME.exe是Windows的重要组成部分,很少会导致问题。当然ChsIME.exe也可能是恶意软件所伪装,或造成的一些问题。因此,应该检查PC上的ChsIME.exe进程,看看它是否是威胁。

建议使用Security Task Manager来检查计算机的安全性。这是华盛顿邮报和PC World的热门下载精选之一。

resolve ChsIME issues
  1. 使用cleanmgrsfc / scannow清理硬盘;
  2. 卸载不需要的程序,检查自启系统(使用msconfig),并启用Windows‘s Automatic Updata
  3. 经常记得执行定期备份,或至少设置还原点。

非常重要的一点是:如果遇到实际问题,尝试回忆最后做的事情,或者在问题首次出现之前做的事情,用resman命令识别导致问题的进程,即使严重的问题,也不要轻易重装及更高的版本,执行Windows,最好修复,或者对于Windows8及更高的版本,执行DISM.exe / Online / Cleanup-image / Restorehealth 命令,这允许在不丢失数据的情况下修复操作系统。

searchIndexer.exe

此进程是一种服务,微软桌面搜索索引程序,用户可以在硬盘上的电子邮件和文档以及其他数据,效率要高于Windows自带的查找功能。

搜索功能达到了飞越,资源占用不大,但对于CPU频率不够高的电脑来说,如果不进场搜自己电脑的我呢见,可以禁用此类服务。

CPU频率不够高

win + r 打开运行,输入services.msc ,进入服务,点击键盘上的w然后确定,在以w开头的服务中找到Windows Search 服务,选择禁止即可。

svchost.exe

经常注意自己电脑的小伙伴应该清楚,这个进程是在不断下载数据的,所以总有人认为它是一个病毒进程,但它是Windows操作系统中的系统文件,官方解释是:svchost.exe 是从动态链接库 (DLL) 中运行的服务的通用主机进程名称。

这个进程对于系统的正常运行是非常重要的,不能被结束,许多程序都依赖于这个这个服务,通过注入才能启动,所以会有多个该文件的进程。

在Windows中一般有多个此进程,在Windows操作系统中,不会继续多个服务共享一个svchost.exe进程,而会为每个服务都分配一个独立的svchost.exe进程,所以有会看到进程列表中有n个此进程。

smartscreen.exe

新装了Windows之后,经常会出现 “Windows Defender SmartScreen 已阻止启动一个未识别应用。运行此应用可能会导致你的电脑存在安全风险”

Smart Screen筛选器是一种检测仿冒网站的功能,同时还可以阻止安装恶意软件。有助于针对可能从事钓鱼攻击,或尝试通过社交软件攻击分发恶意软件的网站提供早期警告系统。

安装过程的繁琐

打开运行,输入regedit 进入注册表,找到start项,双击start修改里面的数值为3,在任务管理器界面找到启动页,在启动分页找到Windows Defender 选项,禁用就行。

ctfmon.exe CTF

此进程是Microsoft Office 产品套装的一部分,是有关输入法的一个可执行程序,可以选择用户文字输入程序。输入法不显示可能就是因为不小心关了此进程导致的。

ctfmon.exe本是无毒软件,但在使用过程中经常浏览一些网站和移动设备的时候有些病毒及那个此进程篡改导致出现问题,易被人们认为这是一个病毒进程。

篡改
  1. 电脑不要经常访问一些不知名的或没听过的网站;
  2. 安装实用的杀毒软件,及时检查电脑,更新病毒库;
  3. 防止外来U盘和手机卡等设备。

ApplicationFrameHost.exe

ApplicationFrameHost.exe is known as Microsoft® Windows® Operating System, it also has the following name Wondershare Studio or or Microsoft? Windows?(ApplicationFrameHost.exe 称为Microsoft®Windows®操作系统,它还具有以下名称Wondershare Studio或Microsoft?视窗?)目前未产生任何警报

Is ApplicationFrameHost.exe using too much CPU or memory ? It’s probably your file has been infected with a virus. Let try the program named DriverIdentifier to see if it helps(一般情况下不会占用过多的CPU资源和存储,有可能文件中病毒,推荐加黑的软件寻找帮助)

中病毒

如果在使用过程中出现异常,可以进行删除,删除操作与卸载软件相似。

Let try to run a system scan with Speed Up My PC to see any error, then you can do some other troubleshooting steps.
If you think this is a driver issue, please try DriverDouble.com【加黑的网站可以帮助解决进程恢复问题】

引入文献:
https://www.howtogeek.com/268337/what-is-this-process-and-why-is-it-running/

请告诉我具体的实验步骤: Lab: system calls In the last lab you used system calls to write a few utilities. In this lab you will add some new system calls to xv6, which will help you understand how they work and will expose you to some of the internals of the xv6 kernel. You will add more system calls in later labs. Before you start coding, read Chapter 2 of the xv6 book, and Sections 4.3 and 4.4 of Chapter 4, and related source files: • The user-space "stubs" that route system calls into the kernel are in user/usys.S, which is generated by user/usys.pl when you run make. Declarations are in user/user.h • The kernel-space code that routes a system call to the kernel function that implements it is in kernel/syscall.c and kernel/syscall.h. • Process-related code is kernel/proc.h and kernel/proc.c. To start the lab, switch to the syscall branch: $ git fetch $ git checkout syscall $ make clean If you run make grade you will see that the grading script cannot exec trace and sysinfotest. Your job is to add the necessary system calls and stubs to make them work. Using gdb (easy) In many cases, print statements will be sufficient to debug your kernel, but sometimes being able to single step through some assembly code or inspecting the variables on the stack is helpful. To learn more about how to run GDB and the common issues that can arise when using GDB, check out this page. To help you become familiar with gdb, run and then fire up gdb in another window (see the gdb bullet on the guidance page). Once you have two windows open, type in the gdb window: make qemu-gdb (gdb) b syscall Breakpoint 1 at 0x80002142: file kernel/syscall.c, line 243. (gdb) c Continuing. [Switching to Thread 1.2] Thread 2 hit Breakpoint 1, syscall () at kernel/syscall.c:243 243 { (gdb) layout src (gdb) backtrace The layout command splits the window in two, showing where gdb is in the source code. The backtrace prints out the stack backtrace. See Using the GNU Debugger for helpful GDB commands. Answer the following questions in answers-syscall.txt. Looking at the backtrace output, which function called syscall? Type a few times to step past struct proc *p = myproc(); Once past this statement, type , which prints the current process's proc struct (see kernel/proc.h>) in hex. np /x *p What is the value of p->trapframe->a7 and what does that value represent? (Hint: look user/initcode.S, the first user program xv6 starts.) The processor is running in kernel mode, and we can print privileged registers such as sstatus (see RISC-V privileged instructions for a description): (gdb) p /x $sstatus What was the previous mode that the CPU was in? In the subsequent part of this lab (or in following labs), it may happen that you make a programming error that causes the xv6 kernel to panic. For example, replace the statement num = p->trapframe->a7; with num = * (int *) 0; at the beginning of syscall, run , and you will see something similar to: make qemu xv6 kernel is booting hart 2 starting hart 1 starting scause 0x000000000000000d sepc=0x000000008000215a stval=0x0000000000000000 panic: kerneltrap Quit out of qemu. To track down the source of a kernel page-fault panic, search for the sepc value printed for the panic you just saw in the file kernel/kernel.asm, which contains the assembly for the compiled kernel. Write down the assembly instruction the kernel is panicing at. Which register corresponds to the variable num? To inspect the state of the processor and the kernel at the faulting instruction, fire up gdb, and set a breakpoint at the faulting epc, like this: (gdb) b *0x000000008000215a Breakpoint 1 at 0x8000215a: file kernel/syscall.c, line 247. (gdb) layout asm (gdb) c Continuing. [Switching to Thread 1.3] Thread 3 hit Breakpoint 1, syscall () at kernel/syscall.c:247 Confirm that the faulting assembly instruction is the same as the one you found above. Why does the kernel crash? Hint: look at figure 3-3 in the text; is address 0 mapped in the kernel address space? Is that confirmed by the value in scause above? (See description of scause in RISC-V privileged instructions) Note that scause was printed by the kernel panic above, but often you need to look at additional info to track down the problem that caused the panic. For example, to find out which user process was running when the kernel paniced, you can print out the process's name: (gdb) p p->name What is the name of the binary that was running when the kernel paniced? What is its process id (pid)? This concludes a brief introduction to tracking down bugs with gdb; it is worth your time to revisit Using the GNU Debugger when tracking down kernel bugs. The guidance page also has some other other useful debugging tips.
最新发布
11-16
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值