Debugging Tools for Windows - Snapping a Process, Part 2

Last time we discussed how to snap a process; lets build  on that a little further.

Scenario

An exception is not being handled and it causes the process to terminate abnormally. The runtime has given any callers in the call stack a chance to handle the exception and none have done so. This type of exception is then passed back to the kernel who then invokes the default exception handler, which terminates the process to preserve system integrity.

Identify the Process

Typically, you know which process is crashing; it’s your process after all. Open up your favorite system tool and take note of the process identifier (PID).

If you don’t own the process, it gets a little trickier. For example, all BizTalk code executes in one, or more, instances of the BTSNTSvc.exe host process. ASP.NET has a similar host model, at least with IIS 6.0, in that code can run in multiple instances of the IIS worker process W3WP.exe.  Reporting Services also has its multiple hosts: ReportingServices.exe and W3WP.exe.

Unfortunately, using the standard Windows process tool, Task Manager, you may not be able to get enough of the information to identify the specific process your code is executing in. Never fear! Process Monitor is here! Process Monitor, now Microsoft Sysinternals, is the end all, be all system information tool. It can help you identify which process instance you are truly interested in.

For BizTalk, using Process Explorer, you can identify the command line of the specific service instance your interested in. Remember, since BizTalk has a generic host instance for code to run in, the way it determines which code will run where is by GUID. This GUID, and a user friendly host name, is passed to the service at startup on the command line.  You can view this command line information by adding the 'command line' column from Process Monitor.

For Reporting Services and ASP.NET applications, the name of the IIS Application Pool will be passed on the command line as well. If you are in a situation where you have multiple W3WP.exe processes running for a given Application Pool, it gets a little more complicated. You can manually attach/snap the individual processes based on the command line identifiers. Fortunately, the tools team realized how many programmers hate repetition and gave us an easy out. Just pass the –iis flag to Adplus. This will probably create more dumps than your interested in, but you’ll make sure you get everything. This will dump each instance of an IIS related process: INETINFO.EXE, DLLHOST.EXE and W3WP.EXE.

Alternatively, you can also use the –pn flag and execute the same Adplus commands against all processes with the same name.

Now that you've got the correct process instance your interested in, its time to actually setup the trap and capture the crash!

Capture the Crash

Open a command prompt
Change to the Debugging Tools for Windows directory
Execute adplus –crash –p xxxx (where xxxx is the PID of the process you want to capture the crash, e.g. 1234)

This will open a new debugger host process which has attached to the specified process. Now, you either wait for the crash to happen during the normal course of events, or if you know how to trigger the crash that will speed things along. E.g. you know that when BizTalk processes a particular message, a certain report is executed, or a certain user event in your web application triggers the unhandled exception.

Of course, this only captures those exceptions which are unhandled by anyone. What happens when you suspect there are exceptions that are being handled? That’s where the –FullOnFirst flag for Adplus comes into play. When using –FullOnFirst, Adplus will create a full memory snap the first time it sees an exception.

Capture the Crash (First Chance Exceptions)

Open a command prompt
Change to the Debugging Tools for Windows directory
Execute adplus –crash –p xxxx -FullOnFirst (where xxxx is the process id of the process you want to capture the crash)

One word of warning, if this is something that happens frequently, you can get a LOT of snaps in a very short period of time.  Remember, since we are snapping the state of the process, this includes all its memory.  If its 400MB in memory, it will be 400MB on disk!