like he said, kernel problem. Most likely a driver holding on to a handle opened by a process by not cancelling I/O properly. to my recollection the most common case, but could be similar other reasons.
I think it also used to be able to kill msmpeng.exe but it now fails with access denied. I assumed it was intentional because they don't want to kill antivirus. But it is a CPU hog, often at critical times, so I used to find myself killing it a lot in past releases.
In windows processes have an access control list, just like file permissions. MsMpEng.exe (and other sometimes other critical system processes and antivirus scanners etc) can't be killed because only system has permission, not administrators.
Process Explorer allows you to view and modify a process access control list (if you have permission).
If you use psexec to run process explorer as system, then you can get into the access control list of these processes and add permission for administrator (or just kill them from there...)
I am ex msft. I have written windows code in kernel mode. I know that there are acls. I know about psexec too. I was not talking about any of that, but Task Manager as this thread was about.
Personally if I were killing with psexec I would try invoking taskkill.exe.
Ah, ok, sorry I was just trying to be helpful, I wasn't trying to teach you to suck eggs :)
But my main point was (that I implied, but I didn't say) is yes, I remember killing off early versions of microsoft security essentials (when that was its name) with task manager too. Logically, back then the process didn't have a restricted ACL, but it now does.
I didn't actually know you could specify the system user when killing a process with taskkill, thanks
