BugSlasher

Sometimes bug happens before you have the chance to attach a debugger to the faulting process. Most of the time it’s because it is launched by another process (a service, the compiler used to create a Xml serializer of a .NET software, a batch script, etc.) and you don’t have the time to get the command line with ProcessExplorer. And even if you can get it, a process may expect some context coming from its parent. And obviously, sometimes you don’t have a clue about how a process is launched, all you know is that it crashes and you need to see what’s inside before it do so.

After a few tryout to pause the process (Process Explorer is your friend) before it crashes, or some tentative to slow down your computer so you have the time to attach a debugger, you’re starting to get frustrated. Hopefully I have some solutions for you.

The easy way: you can easily attach to the parent process, and you love your friend WinDbg

Well, nothing can be simpler: just attach to the parent process with WinDbg, and type the command

.childdbg 1

From now on, any process launched by the process you’re attached on will be debugged, and it’s recursive: child process of child processes will be debugged also. By ‘debugged’ I mean that WinDbg will break as soon as any process starts, it’s enough to do whatever you need.

In this mode of debugging, I advise you to use the WinDbg window called ‘Processes and Threads’ (display it with Alt+9 or menu View->Processes and Threads) as it will display in bold the current process being debugged, with its name and its PID. To show you the result, I just made a simple .NET application using a XmlSerializer, so I expect my application to launch a .NET compiler to create the serialization assembly. Here is some views of the Processes and Threads window as time goes by:

The window when I started

The window after the compiler started

The compiler also starts a resource tool

If you want to have some details about the process you’re currently debugging, you can issue the command

!peb

to have the command line, the environment, etc. Maybe you want to know what is the exact process tree, ie what are the parent <-> child process relation? Well I don’t know how to display it with WinDbg, but Process Explorer displays this tree by default.

The real way: configure GFlags to start WinDbg

I already talked about this technique in a previous post about how to debug the beginning of Windows services. The key is to use GFlags and configure it to start and attach the debugger you want as soon as a process starts:

Don’t forget to remove this setup by unchecking the Debugger check box. In case you don’t know anymore which executable you setup in GFlags, just take a look in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

You will find one key by executable, and a string value named Debugger inside:

Just remove the entire key and you’re done.

The (almost) real way: configure GFlags to start Visual Studio

The idea is pretty much the same than in the previous chapter: use GFlags and type your debugger’s name. There is just one little trick: you cannot use directly Visual Studio to attach to a process with a command line. Instead, you may use VSJitDebugger.exe that you can usually find in the path %windir%\System32 of a computer where Visual Studio is installed (at least with the 2010 version):

I deliberately typed ‘ConsoleApplication1.exe’ instead of ‘csc.exe’ in the previous example because the Visual Studio debugger uses csc.exe also, and debugging csc.exe like this would lead to a funny kind of infinite debugging loop (and eventually crash your system).

When GFlags is properly setup, you can now launch your application. Beware that VSJitDebugger acts a little bit different than WinDbg and will first display a dialog bog saying that the executable crashed:

You HAVE to click on the Debug button, otherwise your application will really crash…After that, you will have a dialog box looking like that:

Then you just have to choose the instance of Visual Studio you want. But remember that this way has a major drawback: Visual Studio will NOT start with the process in break mode: it will continue the execution, and the moment when you want to stop may be gone already…

Happy debugging.