Exception Handling and Crash Reporting - Part 1
Introduction
One of the biggest challenges for a developer is to debug a program that has been put into production or shipped to a customer. On the developer's workstation, the program works fine. But on the customer's system, there are random crashes. There is often no Direct Access To The Customer's System, Because of distance. Writing to the Event log or other log file may be Helpful, But Can Only Point In a Direction, Not Give a Precise Location.
This was the state I was in when I read Bruce Dawson's paper on Release Mode Debugging. Dawson's paper discusses several techniques that I had never encountered before, including how to capture the instruction pointer (ip) of a crash, and how to plug the ip INTO VC and Go Directly to the Source Line of the Crash. (I am Talking About VC 6.0 Here, Not .NET).
These new techniques led me toward the holy grail of developers: being able to see a stack trace of each function that led up to the crash At several points along the way, I thought to myself, "Well, this is pretty complete, there's. Nothing more to add. "But Then I Would See the ANOTHER Approach, Another API I Had overlooked, And i Kept ON.
Bruce Dawson's Techniques
The key to Dawson's approach is to generate debug symbols for the release build (I will discuss how later on.) Then whenever you release a new version, you archive the pdb file along with the exe file. Here is one thing I did not know : you can open an exe in DevStudio, step into it, enter an ip, and you will immediately be looking at the source line This is assuming, of course, that you have the pdb file that corresponds with the exe Oh, yes.. , and you will need the instruction pointer (ip) .This was the second revelation for me. Tucked away in Dawson's article was a link to some source code that he had published in Game Developer Magazine. The code included an exception handler that captured the ip, system info, and stack at the time of the crash. Best of all, there was also code that could be included in any MFC application, that would automatically call Dawson's exception handler. Here are Dawson's step-by-step directions to add An Exception Handler To Any MFC App:
Preparation
SET UP YOUR Release Build To Generate Debug Symbols (PDB)
In your VC project, go to Project |. Settings Make sure the Release configuration is selected in the Settings For combobox on the left Go to the C / C tab, select the General category, and select Program Database in the Debug Info combobox.. This Tells The Compiler to Generate Debug Information.
Go to the Link tab and check Generate debug info. This tells the linker to collate debug information into .pdb files. The linker also puts the name of the .pdb file in the executable, so the debugger can find it.
On the same Link tab, enter / OPT:. REF at the end of the Project Options list This tells the linker to eliminate functions and / or data that are never referenced This is the usually the default for release builds, but it gets turned. Off when you tell the linker to generate debug information. Failing to Specify / Opt: Ref Will Cause Your Executables and Dlls To Get 10-20% Larger.include these Files in your project:
Exceptionattacher.cpp
ExceptionHandler.cpp - Should Be Set To Not Use PRecompiled Headers on The C / C Tab (Precompiled Headers).
ExceptionHandler.h
Getwinver.cpp
Getwinver.h
MiniVersion.cpp
Miniversion.h
Crashfilenames.h
....................................
THEORY INTO PRACTICE
When your app crashes, it will now call an exception handler that writes out the ip, system info, and stack to a file called ERRORLOG.TXT. In the download there is a sample project called Test1 that demonstrates this use of Dawson's exception handler.
Here is what the first part of errorlog.txt looks like:
TEST1 Caused An Access Violation (0xC0000005)
In Module Test1.exe AT 001B: 00402CC0. <=== Here is The IP
Exception Handler Called in ExceptionAttacher.cpp - AfxwinMain.
Error Occurred AT 10/18/2003 19:05:08.
D: /TEMP1/XcrashReporttest/1/test1/release/test1.exe, run by hdietrich.
Operating System: Windows XP (5.1.2600).
1 Processor (s), TYPE 586.
32% Memory in Use.
1024 MBYTES Physical Memory.
687 MBYTES Physical Memory Free.
2462 mBytes paging file.
MBYTES PAGING FILE FREE.
2048 MBYTES User Address Space.
2033 mbytes user address space free.write to location 00000000 Caused An Access Violation.
CONTEXT:
EDI: 0x0012FE70 ESI: 0x004043c0 Eax: 0x00000000
EBX: 0x00000001 ECX: 0x0012FE70 EDX: 0x00000000
EIP: 0x00402cc0 EBP: 0x0012F82C SEGCS: 0x0000001B
Eflags: 0x00010246 ESP: 0x0012F820 SEGSS: 0x00000023
BYTES AT CS: EIP:
C7 05 00 00 00 00 00 00 C3 90 90 90 90 90
Stack:
0x0012F820: 73DD23D8 004043C0 00000111 0012F85C. #. Sc @ ..... ...
0x0012F830: 73DD22AE 0012FE70 000003E8 000000. "SP ...........
0x0012F840: 00402CC0 00000000 0000000c 00000000., @ .............
0x0012F850: 00000000 0012FE70 000003E8 0012F880 .... P ...........
0x0012F860: 73DD8FC5 000003E8 00000000 000,000 ... S .........
0x0012F870: 00000000 000003E8 0012FE70 00000000 ........ P ...
0x0012F880: 0012F8D0 73DD2976 000003E8 00000000 .... v) .s ........
0x0012F890: 00000000 00000000 0012FE70 0012FE70 ........ p ... p ...
.
.
.
OK, NOW WE HAVE AN IP, PLUS The EXE AND ITS PDB File. The next step is to file | open and browse to the release build of your exe (in this case, ../test1/ Release / test1.exe). Next Click on Step Into (F11). You Should Now See this:
Go to View | Debug Windows | Registers. You will see the registers window:
Now click before the hex value of the EIP register and enter the crash ip (from ERRORLOG.TXT, we know this is 00402cc0) You can not cut and paste -.. You must type this in When typing it in, the changed address will be Displayed in red:
When you are finished Typing It in, Hit Enter, And You Will See this:
Summary
. We have just gone from a crashed app to the (approximate) source line with just one piece of information - the crash instruction pointer We have obtained this crash ip fairly simply - without having to modify any existing source code The cost: the size. of the release app (Test1.exe) went from 21 KB to 29 KB. For most commercial apps today, this size differential is insignificant.Knowing where an app crashed is important, but sometimes you also need to know how it got to where it This is what I will discuss in part 2.
Non-MFC Applications
Dawson's ExceptionHandler.cpp Can Also Be used in non-mfc Applications. Here is an esample what shows how to use it IT IN A WIN32 Application:
Int WinApi Winmain (Hinstance Hinstance, Hinstance Hprevinstance,
LPTSTR LPCMDLINE, INT NCMDSHOW)
{
INT NRESULT = -1;
__TRY
{
NResult = DOSMESTUFF (Hinstance, Hprevinstance, LPCMDline, NCMDSHOW);
}
__except (RecordExceptioninfo (getExceptioninFormation (), "Winmain"))
{
// do nothing here - RecordExceptioninfo () HAS Already DONE
// everyhes you is needed. Actually this code Won't Even
// GET CALLED UNSS you Return Exception_execute_handler from
// the __except clause.
}
Return Nresult;
}
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 expressy. I accept no liability for any Damage or loss of business tris Software
