What exactly happens when my process is killed?

I have a mixed process with native and managed code, running on Windows server 2003.

When I kill my process from within process explorer it goes into a state of 100% cpu and stays like that for a while (sometimes even 10 minutes) before going away. During this time I cannot "kill" it or do anything else.

What exaclty happens to a process when I kill it via process via process explorer's kill? I believe this does not call any destr开发者_Go百科uctors, so what could be causing such cpu usage?

Thanks, Dan

Obviously something is trying to continue running, which is causing the hang/deadlock condition you are seeing. I could attempt to explain how to use some tools to try and find out what is happening, but I should probably just defer you to the master... Tess - Lab on High CPU Hang

I was able to use the methods she describes to figure out issues with my own applications.

Try it using End Process (on Process tab) of Task Manager instead, and try whether there's a difference if you choose Kill Process Tree on either Task Manager or Winternal's Process Explorer, however I doubt it'll help.

The process is supposed to be killed (almost) instantly, however, there are some sneaky ways to stick around. If you wrote your own application, I assume that isn't the case. It is more then likely that other processes don't like yours being taken away. Set Process Monitor on quick refresh speed and sort the cpu column. You should now see which process is causing the 100% issue. Most likely: system.

In the event that you use a lot of memory, esp. when it's overall more than the physical memory, the system will reorganize (i.e., move memory from disk back to physical memory). A similar behavior occurs (up until freezing my system) when I kill Firefox after I open 500+ tabs, occupying 1.5GB memory. This behavior (slowly reorganizing memory) has improved with later versions of Microsoft Windows.

UPDATE: internally, proc expl. calls TerminateProcess (amongst others), which force-closes all handles and threads. The MSDN API ref says "TerminateProcess initiates termination and returns immediately. This stops execution of all threads within the process and requests cancellation of all pending I/O. The terminated process cannot exit until all pending I/O has been completed or canceled.". Which means so much as: your I/O can block this process (though I wonder how it can bring your process to 100%, I/O usually doesn't do that).

If you have several threads, or other resources that weren't released then it may be trying to wait for everything to be freed before the application is killed.

When your application is killed, ideally it is expected that all resources that are used will be freed, but that is why you should ensure you implement the IDispose interface, to help with this, otherwise you may find that some file is open that can't be re-opened, and your only option is to reboot.

Does this happen when you try to kill other applications, or just this one?

You may want to simplify your program, or try to kill it before it uses too many resources, and see if you can determine at what point you will encounter this problem, and then you may have a better idea what you did that is causing this behavior.

Could you look at the threads in Process Explorer? See what's running and particularly what's taking up 100% CPU. See if you can find the call stack and isolate the specific thread or even function. Post the answer here if you can!

My psychic debugger is that you had a lot of resources still allocated (i.e. file/reg handles, win32k objects, etc) and the kernel is cleaning them up. When you use Process Explorer to crack into the app, does the resource usage look high?