Debugging Windows Error Reporting


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.


Comments (3)

  1. DanielMoth says:

    For managed code (with a Vista bias), hope you find this relevant:

    http://channel9.msdn.com/ShowPost.aspx?PostID=252788

  2. Satisfy Me says:

    Earlier this week, I provided a couple of glimpses at how product groups listen and respond to customers

  3. A few weeks ago the Visual C++ team delivered two days of technical content to developers down in Northern

Skip to main content