30

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.)

migrated from stackoverflow.com Mar 20 '10 at 1:33

This question came from our site for professional and enthusiast programmers.

  • 10
    If I only had a nickel for every time I wanted the answer to this question... – Steven Oxley Mar 20 '10 at 1:20
  • 3
    I appreciate the answers, but I would like to read an Operating Systems developer explaining why an OS of this era cannot kill a non-core/kernel (or whatever adjective is appropriate) process. I believed since the 386 there was a "ring 0" (or something alike) giving special privileges to some code over other, I thinked that was the way a (OS) process has authority over others. Maybe I'm completely wrong, but the question remains unanswered. – Néstor Sánchez A. Jun 18 '11 at 13:24
20

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

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

  • This happens in Linux as well. While the x86 architecture has 4 rings, only two of them are used (ring 3 for userspace, ring 0 for kernel). So everything is either kernel mode or userspace, with nothing in between. But, a possible workaround is "user-mode" drivers which depend on a small reliable kernel-mode stub that merely calls userspace code. I believe most print and USB drivers in Windows are this (graphics drivers used to be in Windows 3.1), but userspace carries a performance penalty. – LawrenceC Aug 20 '11 at 20:00
  • Couldn't the industry (Intel, AMD, ARM, etc.) create a "meta-ring" to finally give to the user (at his own risk) the real capability of kill a process and get rid of this problem once and forever???? – Néstor Sánchez A. Oct 30 '18 at 20:46
16

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.

  • 2
    How do I figure out whether a debugger is attached and which process it is that is attached? Because I'm not debugging anything but the task won't die, not with task manager, not when stopping the service, not with taskkill /f, not with wmic ... call terminate... it keeps saying "error: the process X with pid Y could not be terminated. There is no running instance of this task." – Luc Aug 1 '18 at 15:53
3

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.

3

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.

2

If the last app.vshost.exe is still running, just connect to that process with the debugger.

Should be found in menu under Debug->AttachToProcess then choose the hanging process and connect to it.

2

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.

  • Thanks, this is certainly the best answer that matches my problem. – Pablo Ariel Aug 31 '17 at 14:49
1

Perhaps an examination of some of the tools cited here could lead to answers?

https://stackoverflow.com/questions/49988/really-killing-a-process-in-windows

(Just now I found that pskill was the only of several tools that could kill a process running under one user's Windows 7 session, from another user's session (or credentials, I suppose.)

-1

You can!

Using ProcessHacker (right click on the process) -> Terminator.

-1

If you are using VS to debug process,and you kill it with task manager.Then VS can't deal with it well.

So VS is still debugging the target process but you can't just press stop process in VS.Just quit your VS and you will see your process exit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.