Home > Windows debugging tricks > Who the hell killed my process?

Who the hell killed my process?

April 17, 2011 Leave a comment Go to comments

There is a few reasons that can make a process disappear. It can be:

  • a normal termination (you reach the end of the main function)
  • a call to ExitProcess, potentially located anywhere in your code
  • an exception walking up all through the call stack of its thread, making the process die.
Those three reasons are quite easy to debug. For the first one, just check the code logic that made the program exits. For the second one, a breakpoint put on kernel32!ExitProcess should do the trick. And of course, the third one is caught by any decent debugger because it’s what is called a Second Chance Exception, meaning that you program is about to crash.
But there is another sneaky reason: your process could have been killed by another process. Even between processes, life is hard, and as long as you have sufficient rights, killing another process is just another line of code. It can happen on production systems because of a poorly designed cleaning batch, or it can be malicious software trying to end any process that can harm it: an antivirus software, or a spying tool.
So the question is: how can you know which process killed your lovely software?

Your operating system is Windows Vista or Windows Server 2008

Well I’m very sorry for you guys, but the only solution I know is kernel debugging, and as I’m complete newbie to it, I will not give you any way on how to do it. But my first advice would be to download the Debugging Tools for Windows, put the system on a virtual machine (or buy another PC) and start digging the NT Debugging Blog.

Your operating system is Windows 7 or Windows Server 2008 R2 (or higher I guess…)

Now we can talk. It appears that the last version of the Debugging Tools for Windows is shipped with a version of GFlags that add a new tab: ‘Silent Proces Exit’. No documentation is available for the moment, but the options are pretty clear, just fill in the boxes like that:

Now start your process, kill it with another one, and a new event will appear in the Event Manager (type eventmgr.msc to start it) in the ‘Application’ section, looking like that:

And voilà, you got the name of the killer, and of course the name of the victim.

This is not enough: I want full details about the killer, and also what was the victim doing when it dies.

Well, as you may have noticed by looking at the GFlags options, it can be easily done:

This configuration will create two dumps in %TEMP%\Silent Process Exit, under a directory named with the name of the ‘victim’, its PID and a number who seems to be related to the date and time:

This gives only MiniDumps, but it’s enough for most common troubleshooting investigations. I tried to play with the other options (‘Dump Folder Location’ and ‘Dump Type’) but none seems to have any effect. I don’t know if it is a bug of a misuse, let’s hope that some documentation will soon enlighten those parts.

Categories: Windows debugging tricks Tags: ,

Leave a comment