XCrashReport : Exception Handling and Crash Reporting - Part 3

• Download demo project - 435 Kb

Introduction

In Part 1, I discussed the problems of debugging a program that has been put into production or shipped to a customer. On the developer's workstation, the program might work fine, but on the customer's system, there are random crashes. To fix the problem, you need to know where the program is crashing, and in Part 1 I discussed an approach to determining this.

In Part 2, I described a simple way to instrument the source code that would facilitate the analysis of stack dumps. But this technique has its own problems, and in this article I will describe my attempts to improve on this, and how I came to the perfect solution.

Deus Ex Minidump

After I wrote Part 2, I really thought this was as far as stack tracing could be taken, without resorting to a much larger exception handler footprint or other technology that might not work on Win9x systems.

I was aware of a new Visual Studio .Net technology called minidumps, which you could apparently load directly into the .Net debugger and see the call stack, but I could find very little information on how this was done. Not having Visual Studio .Net, it did not seem worth pursuing - even if I could generate a minidump, how could I look at it? Also, there was a question about whether Win9x systems could create a minidump.

Then two things happened. I found out that the dbghelp.dll - which contains the MiniDumpWriteDump() API - could be redistributed. Second, I learned of a way to read the minidumps, without using Visual Studio .Net.

Preparation

The MiniDumpWriteDump() API is pretty easy to use, for what it does. Here is what MSDN says:

The one tricky parameter is the DumpType. The only value for DumpType that I could get to work on Win9x systems was MiniDumpNormal.

Theory Into Practice

In order to get set up to call MiniDumpWriteDump(), we need to open a file for writing and pass its handle to MiniDumpWriteDump(). In the newly revised ExceptionHandler.cpp module, this is how we call MiniDumpWriteDump():

///////////////////////////////////////////////////////////////////////////////
// DumpMiniDump
static void DumpMiniDump(HANDLE hFile, PEXCEPTION_POINTERS excpInfo)
{
    if (excpInfo == NULL) 
    {
        // Generate exception to get proper context in dump
        __try 
        {
            OutputDebugString(_T("raising exception\r\n"));
            RaiseException(EXCEPTION_BREAKPOINT, 0, 0, NULL);
        } 
        __except(DumpMiniDump(hFile, GetExceptionInformation()),
                 EXCEPTION_CONTINUE_EXECUTION) 
        {
        }
    } 
    else
    {
        OutputDebugString(_T("writing minidump\r\n"));
        MINIDUMP_EXCEPTION_INFORMATION eInfo;
        eInfo.ThreadId = GetCurrentThreadId();
        eInfo.ExceptionPointers = excpInfo;
        eInfo.ClientPointers = FALSE;

        // note:  MiniDumpWithIndirectlyReferencedMemory does not work on Win98
        MiniDumpWriteDump(
            GetCurrentProcess(),
            GetCurrentProcessId(),
            hFile,
            MiniDumpNormal,
            excpInfo ? &eInfo : NULL,
            NULL,
            NULL);
    }
}

This new ExceptionHandler.cpp is incorporated into the XCrashReportTest demo program. When the program is run, you may choose different types of crashes:

When you click on one of the buttons, the program crashes and it generates a minidump file called CRASH.DMP Remember when I said that I learned of a way to read the minidumps, without using Visual Studio .Net? Here is how: use WinDbg, that is available for download from Microsoft Debugging Tools. WinDbg requires that the pdb file be in the same directory as the exe and the CRASH.DMP file. After starting WinDbg, go to File | Open Crash Dump and select the CRASH.DMP file. Next enter ALT+1 to switch to the command window, and type .ecxr and hit Enter. You will see:

In the lower window you will see that OnCrash called Crash1 which called Crash2 which called CrashTestFunction, and the crash occurred at line 33 in crashtest.cpp.

Summary

We now have a way of getting the call stack and finding the crash location, without needing to instrument the source code. Downloading and learning to use WinDbg require a few minutes - OK, maybe more than a few if you have dialup. But it is only a one-time thing, and it seems worthwhile. The bottom line: exception handling and minidumps can be added to any existing MFC application by adding a few files, changing three build settings, and recompiling. The only additional work for you is to save the pdb file, each time you make a new version.

I thought this was going to be the last article about crash reporting, but then I came across something so brilliant that I knew I had to incorporate it into my approach to handling exceptions and crash reporting. I will tell you all about it in Part 4.

Revision History

Version 1.1 - 2003 October 19

• Initial public release

Usage

This software is released into the public domain. You are free to use it in any way you like, except that you may not sell this source code. If you modify it or extend it, please to consider posting new code here for everyone to share. This software is provided "as is" with no expressed or implied warranty. I accept no liability for any damage or loss of business that this software may cause.

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 8 of 8 (Total in Forum: 8) (Refresh) FirstPrevNext

Minor bug in references to Part 1 and Part 2 Petr Prikryl 21:25 3 Apr '08   The references to Part 1 and Part 2 in Introduction lead to nowhere. There should be used .aspx instead of .asp. Anyway, thanks for the excelent article. Petr -- Petr Prikryl, Skil s.r.o. Sign In·View Thread·PermaLink Symbol file could not be found Shashidhar Kamath 15:17 20 Nov '07   Hello I have used your technique to debug my program and it was working well couple of years back. But did not use it for last 2 years. Now it does not work anymore. I have my exectuable and .pdb file and crash dump file all in the same folder. When i load the crash.dmp file in WinDbg it says Symbol file could not be found. I am using the latest version of WinDbg version no 6.8.0004.0. My compiler is Visual studio 6.0. I just created a test crash in my program and windbg fails to report. Instead it says *** ERROR: Symbol file could not be found. Defaulted to export symbols for mfc42.dll - But your test program still works fine. Please help me fix this. Shashi Sign In·View Thread·PermaLink 5.00/5 (1 vote) How to use this in a (MFC) DLL? lzandman 5:30 22 Sep '04   Hi, I've got an MFC DLL and I want to use XCrashReport in it. I've included it in my DLL project, but it seems XCrashReport is never attached to my DLL (AfxWinMain() isn't called). This is probably caused by the fact that a DLL doesn't use AfxWinMain() as an entry point. Can anybody please tell me how to use XCrashReport from inside a DLL, so that when an exception occurs inside my DLL the minidump is created? Sign In·View Thread·PermaLink 1.33/5 (3 votes) Re: How to use this in a (MFC) DLL? Darko Vukoje 6:05 18 Apr '07   According to Author: "The bottom line: exception handling and minidumps can be added to any existing MFC application by adding a few files, changing three build settings, and recompiling..." My question is, how this can be added to DLL project that runs in third party application address space as a plug-in? Is there any way to set termination handler for DLL project? I tried addin SetUnhandledTerminationFilter in my Outlook DLL plug-in but termination handler was never called. Any idea? Thanks in advance, Wolf. Sign In·View Thread·PermaLink 1.00/5 (1 vote) working with Unicows. SanDiegoPhil 15:13 23 Apr '04   Has anyone had success getting this to work with Unicows? For some reason, I can't override the default version of AfxWinMain - i.e. I can't get _tWinMain() to call *my* AfxWinMain - suggestions? Sign In·View Thread·PermaLink stack information in release build verinder_bindra 17:36 13 Nov '03   what i need is, I am writing the progrtam from scrach and want to do exception handling in such a way that i can get call stach if i handle the exception and catch exception in my code.. I saw ways to get stack information in structured exceptions.. But that technique doesn't work in MFC ,C++ exceptions ... i have gone through all code guru articles.. none of them work completely in all situations.. problem is if i catch mfc exceptions there is no way to get EXCEPTION_POINTERs information in catch block.. any idea how to do it??? none Sign In·View Thread·PermaLink Re: stack information in release build Hans Dietrich 3:15 29 Nov '03   verinder_bindra wrote: But that technique doesn't work in MFC Structured exception handling works fine with MFC programs. Please take a look at the XCrashReportTest project to see how this is done. Best wishes, Hans Sign In·View Thread·PermaLink 4.40/5 (2 votes) Amazing ! Almost too good to be true ! sdaymond 6:27 29 Oct '03   I was lucky to find this article just one week after it was posted and I feel priviledged to write the first comment. I tested the sample program and it realy works ! It is a Holy Grail for a developer to be able to track the crash in released version. Hans did a brilliant work finding a way to use new technology intended for .Net and applying it to regular VC++ programs. Hans - Congratulations and thanks for sharing it with the public ! Now, I am interested in using that technique in VC++ non-MFC DLL. I will have to investigate if that can be used without any problems. Obviously the exception handler will be in different function (I guess DllMain). When I looked at ExceptionHandler.cpp, there is a comment: "does not require MFC" so I guess I might be lucky. Best Regards, Stan Daymond London, UK Sign In·View Thread·PermaLink 4.40/5 (2 votes)

Last Visit: 11:54 4 Jul '09     Last Update: 11:54 4 Jul '09 1