Translating EXCEPTION_POINTERS Structures

[Previous] [Next]

Now that you've written your exception handlers and crash handlers, it's time to talk about those EXCEPTION_POINTERS structures each is passed. Because these structures are where all the interesting information about the crash is stored, I wanted to develop a set of functions that you can call to translate the information into human-readable form. With these functions, all you need to concentrate on is the display of information to the user in a manner that's appropriate for your particular application. You can find all these functions in Listing 9-5.

I tried to keep the functions as simple as possible. All you need to do is to pass in the EXCEPTION_POINTERS structures. Each function returns a pointer to a constant string that holds the text. If you looked at the code, you might have noticed that each function has a corresponding function whose name ends in "VB". I tried to come up with a way for Visual Basic to use the same static buffers that the C functions use. I used the static buffers because the EXCEPTION_POINTERS-handling functions will be called in crash situations, and I can't rely on allocated memory or use too much stack space when my crash handler functions are called. Unfortunately, I couldn't come up with a clean way other than having Visual Basic use its own string buffer that you must pass in. With the C versions, because I could return the static string buffers directly, I wanted to make the functions easier to use. When calling the crash handler functions from Visual Basic, declare a global string variable early in the program so that the memory is available.

The GetRegisterString function simply returns the formatted register string. The GetFaultReason function is a little more interesting in that it returns a complete description of the problem. The returned string shows the process, the reason for the exception, the module that caused the exception, the address of the exception, and—if symbol information is available—the function, source file, and line number where the crash occurred.

CH_TESTS.EXE caused an EXCEPTION_ACCESS_VIOLATION in module CH_TESTS.EXE at  001B:004010FB, Baz()+0064 bytes, CH_Tests.cpp, line 0060+0003 bytes 

The most interesting functions are GetFirstStackTraceString and GetNextStackTraceString. As their names indicate, these functions let you walk the stack. As with the FindFirstFile and FindNextFile API functions, you can call GetFirstStackTraceString and then continue to call GetNextStackTraceString until it returns FALSE to walk the entire stack. In addition to an EXCEPTION_POINTERS structure, these functions take a flag option parameter that lets you control the amount of information that you want to see in the resultant string. The following string shows all the options turned on:

 001B:004018AA (0x00000001 0x008C0F90 0x008C0200 0x77F8FE94) CH_TESTS.EXE, main()+1857 bytes, CH_Tests.cpp, line 0341+0007 bytes 

The values in parentheses are the first four possible parameters to the function. Table 9-1 shows the options flags and what each will include in the output string.

Table 9-1 GetFirstStackTraceString and GetNextStackTraceString Options

Option	Output
0	Just the stack address
GSTSO_PARAMS	The first four possible parameters
GSTSO_MODULE	The module name
GSTSO_SYMBOL	The symbol name of the stack address
GSTSO_SRCLINE	The source file and line number information of the stack address

To see these functions in action, I included two sample test programs on the companion CD. The first, CH_TEST, is a C/C++ example. The second program, CrashTest, is a Visual Basic_based example. Between these two programs, you should get a pretty good idea of how to use all the functions I've presented. Figure 9-1 shows CrashTest displaying its crash dialog box.

Figure 9-1 CrashTest dialog box