Getting near to the cause of an application crash once one has a crash dump is one of the easiest debugging tasks. The main problem in these cases is how to actually acquire a crash dump. This post discusses some basic scenarios for getting a crash dump.

To test the basic scenarios, we’ll use an application where crash occur no so randomly as in real-life – the CrashMe application from

All one needs to do to make this application crash is to press one of the buttons from the “Crash Actions” group like “Stack overflow” or “Division by NULL”.


Using the Windows error reporting mechanism

Windows has its own error reporting mechanism which detects when an application is crashing and attaches a debugger automatically. The details about this are provided in:

In short: there is the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

The default value of this is: DRWTSN32 -p %ld -e %ld –g . This will change if you install other software, like, for instance, Visual Studio.

Using ADPlus from Debugging tools for Windows (CDB) 

The Adplus script is very useful when one can easily reproduce a crash. This comes with the Debugging Tools for Windows (which include WinDBG, CDB and other debugging tools).


The newest version of Debugging Tools for Windows is part of the Windows Driver Kit 7.1.0, release 26th February 2010:



For the old Adplus script, we just need the following steps:

a)       Get the PID of the application that will crash using “tasklist” from Command Prompt or the PID column from Task Manager (Processes -> View -> Select columns…)

b)       From Command Prompt, run:

cscript adplus.vbs –crash –p [PID]


This will attach the CDB debugger to the crashing process and will collect 1st chance Mini Dumps and 2nd chance full dumps for the attached process.

The dumps will normally be stored in the same folder where Adplus is installed into a special folder. The DMP files will have meaningful names like:



Obviously, there are a lot of options available for Adplus. Just run it without any argument and you’ll see the whole range of options.


Note:The newest version of Debugging Tools for Windows contains an executable for Adplus as well as the old version Adplus_old.vbs


Using WinDBG 

WinDBG provides more or less the same functionality as CDB with regards to collecting crash dumps. You can configure the exception handling in the debugger to break only for on 2nd chance exceptions (check the WinDBG help).


To get a dump from WinDBG you will need to run the command .dump. Sample usage:

.dump /mfh /u C:\crash.dmp       

The /u switch is very useful because it appends the date, time and PID to the name of the generated dump file.


What to do when the crashing process will be started in the future 

An application crash is not always as easily reproducible as the ones from the CrashMe application. The special case when you know that a certain application will crash but don’t know under which circumstances can be handled in at least two ways:

a)       Configuring the Windows Error Reporting to collect a customized dump when an application crashes. Here is a sample how to configure CDB to get dumps when any application crashes in Windows:

Set the following registry values of the key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

Debugger = "C:\Debuggers\cdb.exe" -p %ld -e %ld -g -c "~*k;.dump /mfh /u C:\Dumps\crash.dmp;.kill;qd"

Auto = “1”


-“C:\Debuggers\cdb.exe” is the path to the CDB debugger, which might vary depending on the installation path of Debugging Tools for Windows.

 -%ld will be provided by Windows and represents the PID of the process where the 2nd chance exception occurs.

- After the crash is collected, the crashing process is killed (this is specified by passing a custom command to CDB using the –c switch).


b)       Monitoring for a certain process to start and to crash:


adplus.exe -crash -pmn notepad -o C:\Dumps


The parameter passed to adplus in –pmn is the name of the process to monitor and the parameter after –o is the directory where the DMP files will be collected.



What to do when the crashing process uses a custom resiliency mechanism

Microsoft Office uses a custom resiliency mechanism for handling exceptions. It automatically calls Doctor Watson and disregards the Windows Error Reporting.

To work around this, the easiest thing to do is to rename the registry key:







This way Office will not be able to pass the exceptions to DW and Windows will be able to handle them. Please be careful with this change as it is not a supported scenario. The Office Dr. Watson buckets are very useful for collecting mini dumps from customers and identifying critical problems (so please click on Send next time you see a “Send”/”Don’t send” dialog popping up).