For applications that are crashing or hanging, you will need to have the Debugging Tools for Windows present on the machine, and use the script ADPlus.vbs to attach the command line debugger (cdb.exe) to create dump files.

To keep the examples simple I will assume the tools were installed in the folder C:\Debuggers, and the before entering any adplus.vbs commands you have entered the command:

cd /d C:\Debuggers

NOTE: Do not copy/paste any of the commands from here or from formatted emails, as hyphens can get replaced with different characters which are not recognised and the commands will fail – type out the commands as they appear.

 

Crash & Burn

For crashing processes, you attach the debugger and wait for the exception to occur, then the OS passes the exception to it before terminating the process and releasing its resources.

To attach the debugger to a running process FOO.EXE in crash mode, open a command prompt and enter the following:

adplus.vbs –crash –ctcf –pn FOO.EXE –quiet –o C:\Dumps

When the exception is thrown, CDB will catch it and create a new folder in the output folder specified (C:\Dumps in the above example) – the name of the folder will contain the process name, PID and time of the dump so it will always be unique.

 

In some situations “first chance” exceptions are used as an internal message-passing system and we need to ignore these as we are specifically interesting in the unhandled (“second chance”) exceptions, meaning the process is definitely on its way down.

The Print Spooler service (spoolsv.exe) is one such case, and we use another switch to ignore the first chance exceptions that get thrown all the time:

adplus.vbs –crash –ctcf –NoDumpOnFirst –pn SPOOLSV.EXE –quiet –o C:\Dumps

 

Hang ’em High

For processes that hang, there is no exception to catch and so attaching the debugger beforehand will not help – instead you need to wait until the hang is occurring and then open a command prompt to enter this command to create a dump of hung process FOO.EXE:

adplus.vbs –hang –ctcf –pn FOO.EXE –quiet –o C:\Dumps

 

Sometimes it can be useful to take several dumps a few seconds apart, as a hung UI might not indicate a hung process – the threads might be very busy in the background and the main thread is not sending any updates for the user until a big job is complete (think of apps which become “Not Responding” after an action is performed such as loading a file, but then after a while return to life).

The “-r” switch takes 2 parameters: the number of dumps to produce, and the number of seconds to wait between dumps.
So the following example will produce 3 dumps at 10-second intervals from FOO.EXE:

adplus.vbs –hang –ctcf –r 3 10 –pn FOO.EXE –quiet –o C:\Dumps

 

The other scenario you might want to take multiple “hang” dumps is for processes consuming a lot of CPU time (therefore quite clearly not hung) – though typically a better starting position for these cases is to use Process Explorer to look at the call stacks for the busy threads whilst the problem is present and see which modules (and possibly APIs) are involved.

As dumps are like photographs, they can’t give you a good idea of what a thread or process was doing before, or will do after the picture was taken – bear this in mind when trying to make sense of CPU-bound process dumps.

 

Taking the PIDs

If there are multiple instances of a particular process and only 1 is experiencing a crash/hang, then you can specify the unique Process ID (PID) instead of the executable name.

To find out the PID for a particular process you can use any of the following:
- tasklist.exe (at a command prompt)
- Task Manager
- Process Explorer

PIDs are generated at process creation time, so they are not consistent between machines or even on the same machine.

e.g. To take a hang dump of process with PID 1234:

adplus.vbs –hang –ctcf –p 1234 –quiet –o C:\Dumps

 

This can be useful in the case of svchost.exe dumps, for example, when there are always going to be multiple instances.