Why sometimes Windows cannot kill a process?

Right now I'm trying to Run/Debug my application in Visual Studio, but it cannot create it because the last instance of the app.vshost.exe is still running. Then, by using the Task Manager I'm trying to kill it, but it just remains there with no signal of activity.

Beyond that particular case (maybe a Visual Studio bug), I'm very curious about the technical reasons why sometimes Windows cannot kill a process?

Can, an enlighted OS related developer, please try to explain?

(And please don't start a Unix/Linux/Mac battle against Windows.)

The cause is usually some unresponsive driver which has unfinished I/O requests in progress.

See Mark Russinovich's blog entry Unkillable Processes (archive)

One possible reason: You can't kill a task that's attached to a debugger.

The only way to stop the task is from the debugger itself.

My only OS-level development experience was in grad school, but I suspect what is happening is this (or something similar):

An error happened while running the last instance that the debugger tried to handle, but some other issue caused that to fail (maybe a debug assertion was encountered, but before you could click on the dialog to Abort/Retry/Ignore, another break was triggered, maybe due to a null pointer). The result, after you stopped debugging, was that the debugger was still waiting for your response to the first debug assertion, so it wouldn't let the process terminate. But then the debugger terminated when you stopped debugging (or did it?), turning the process into a zombie, or its tree into zombies. When you tried to kill the zombie process, an error similar to this happened, but task manager didn't tell you about it:

C:\Windows\system32>taskkill /pid 9564 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.

Should you decide to try the same thing on the parent (in my case the parent was the debugger process, msvsmon.exe), it fails the same way:

C:\Windows\system32>taskkill /pid 22520 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.
ERROR: The process with PID 22520 (child process of PID 13964) could not be
terminated.
Reason: There is no running instance of the task.

The parent was started by the IDE, but the IDE cut the umbilical cord, so now you have two zombie processes. You can't attach a debugger to the process you were debugging, because there is already a (zombie) debugger attached, and you can't attach a debugger to the (zombie) debugger because, as Visual Studio will tell you when you try:

Unable to attach to the process. An operation is not legal in the current state.

The zombies are still in the process table sufficiently well to prevent you from running another instance through the debugger, but you could probably start another instance outside of the IDE just fine.

This addresses the more specific issue of having VS create a zombie process. But, zombie processes often don't die. Well, often on Windows, sometimes on Linux, not until you shoot them with a shotgun. Or was that a shutdown? But beware the accidental application of pending Windows updates.

I got excited at some of the earlier answers that suggested attaching with the debugger, but the above is the result I got. So I'm submitting my answer and rebooting to clean out the process table.

One reason would be that you don't have permission to kill it. E.g. if the process is running as administrator and you are a normal user.

Open the Properties page for the project, go to the Debug tab, and check "Enable unmanaged code debugging". Or, uncheck the option for using the host process.