Debugging Windows Error Reporting

  • Article

If you’re a software developer, chances are that you have written an application, and this application has crashed. When this happened, it probably put up a dialog that looks something like this:

Windows Error Reporting dialog

 How do you figure out what went wrong?

Strategy #1: Extract the minidump from Windows Error Reporting

Windows Error reporting has already created a minidump of the crash. So one way to find out what went wrong is just to look at the minidump. This works really well if your application is written in native code and there is no debugger on the machine where the crash occurs. You can use it for managed code too, but you will need to use sos.dll to analyze the dump (see MSDN). Open a command prompt (Start->Run, cmd.exe), and switch to your temp directory:

C:\Documents and Settings\greggm>cd /d %tmp%

Look for the dump file that Windows Error Reporting produced. It will have a '.dmp' or '.mdmp' extension and the date should be shortly after the crash happened:

C:\DOCUME~1\greggm\LOCALS~1\Temp>dir *.*dmp
 Volume in drive C has no label.
 Volume Serial Number is 70E3-6676

 Directory of C:\DOCUME~1\greggm\LOCALS~1\Temp

05/24/2007  08:54 AM           109,570 4A88835.dmp
               1 File(s)        109,570 bytes
               0 Dir(s)  25,379,823,616 bytes free

Mark the file as read-only. This will prevent Windows Error Reporting from deleting the file after you dismiss the dialog:

C:\DOCUME~1\greggm\LOCALS~1\Temp>attrib +r 4A88835.dmp

Now dismiss windows error reporting and copy the dump file wherever you want. You can analyze the dump in Visual Studio by opening the dump file as a project (File->Open Project), and start debugging (F5).

 

Strategy #2: Access the dump from Online Crash Analysis

Microsoft has a program to allow ISVs to access the crashes in their applications that have been submitted by users. If the person experiencing the crash is a customer, this is a great way to find out what happened. See the winqual site for more information.

 

Strategy #3: Debug the crash through Just-In-Time Debugging

Probably everyone already knows about this, so I won’t spend much time discussing it. However, as long as the application is crashing on a computer that has a debugger installed, this is the easiest option. The only thing tricky that I will mention is that in Windows Vista, depending on your computers Windows Error Reporting settings, you might actually need to click the 'Send information' button before Windows Vista will present you with a second dialog that allows you to debug.