How to Analyze C++ Crashes on End User Systems

Posted on:September 29 2008

When a program crashes, it usually means that the programmer did something bad. But crashes happen, no matter how good the programmer is. C++ programmers are facing more difficult situations than for example C# or Java programmers when trying to identify and fix the cause of a crash on end users systems. Modern, high level languages are able to report the exact location of crashes and exceptions. After the crash, they usually show the whole stack trace of the problem by default on the screen, which the end user is able to send to the programmer then. C++ programmers are not that lucky, but Windows has a built-in functionality which is able to report the whole crash information and makes it possible to debug a crash after it happened on another PC. And interestingly, not all C++ programmers know about this Minidump-Feature. Basically, all you need to do is
__try{     // execute your code and maybe crash here}__except(WriteYourCrashFile(GetExceptionInformation())){}
where you only need to implement the WriteYourCrashFile they way you like your program to handle crashes, like sending the info out per email or simply write a .dmp to disk. This MSDN article gives a nice example on how to do this. Alternatively, if you don't like __try and __execpt, you can also use SetUnhandledExceptionFilter to install a function to handle the exception instead. The file written by MiniDumpWriteDump() can then be opened in VisualStudio and shows the debugger as if the crash happend on your local PC (assuming you still have have the correct .exe and .pdb file on your disk).
If this is all to much effort for you, the function GetExceptionInformation() already gives enough information to indentify bugs, so you might want to use this one instead.

I personally used this technique in a lot of software I wrote and am currently using this in irrfuscator, where it already helped to identify one mysterious, evil bug which I would never have found otherwise, I think. So I can really recommend it.


Hm, seems nice but is there also a cross plattform or posix way?
2008-09-29 16:41:00

Yes. Release the source. If the program is useful, people will help you to find and fix your bugs because they'll be able to compile it by theirself with lots of debug informations.
2008-09-29 17:23:00

In Linux the core dump gives similar functionality. First "ulimit -c unlimited", then when you want the dump to happen in the programme, SIGQUIT or allow the exception to propagate externally. Then you can post-mortem the core with "gdb prog core". bt gives the backtrace from there.
2008-09-29 22:15:00

right it has a dumb feature..

but is this only for executeables with debugging symbols or for every executeable?
2008-09-30 15:08:00

Without debug information, the backtrace shows only at function level, ie. no line numbers. Still quite useful, but not as useful as with line numbers to be sure.
2008-09-30 16:06:00

Just finished reading the first "Joel on Software" book, he has has a chapter on using this technique for automatic crash reporting, though it's more about deciding which bugs to ignore and which ones to fix when your application goes out to millions of people.
It's a great read and I highly recommend it :)
2008-10-03 02:33:00

About using SetUnhandledExceptionFilter, just have a look at
2008-10-08 14:46:00

Add comment:

Posted by:

Enter the missing letter in: "Interna?ional"




Possible Codes

Feature Code
Link [url] [/url]
Bold [b]bold text[/b]
Quote [quote]quoted text[/quote]
Code [code]source code[/code]