Re: [GD-Windows] Finding routine that's crashing

[Colin F. <cp...@ea...>]

2002 August 7th
Wednesday

First, I want to thank all of the people on this list
who shared their code and offered suggestions on how
to get a stack trace of the location of a crash.
In particular, I want to thank Brian Sharon for
following up my most recent clarification questions.


I am going to describe my paranoid, and very likely
insane, method for getting the crash trace code to
work:


[1] Under Windows 2000, install Visual Studio .NET, and you
should get the following files:

  [a] c:\program files\microsoft visual studio .net\
       vc7\platformsdk\include\dbghelp.h
     (68,880 bytes; June 9, 2001)

  [b] c:\program files\microsoft visual studio .net\
       vc7\platformsdk\lib\dbghelp.lib
     (23,316 bytes; June 9, 2001)

  [c] c:\program files\microsoft visual studio .net\
       common7\ide\dbghelp.dll
     (486,400 bytes; September 5, 2001)


[2] Copy the files mentioned above to a single folder,
   and copy this folder to your Windows 98 machine.

[3] Under Windows 98, copy the files from the folder
   mentioned in step [2] in to the root of your
   C++ application project folder.

[4] Make sure your C++ source file with the symbol
  handling code has something like this:

    #include <windows.h>

    // The following #define prevents an error
    // in "DbgHelp.h" due to deprecation of
    // functions.  I don't know the "proper"
    // way other than using this #define.
    #define _IMAGEHLP_SOURCE_
   
    #include "Dbghelp.h"

[5] It is absolutely critical to use the proper HANDLE to
  indicate the process in all of the symbol handler functions.
  You must determine your platform, and then:

  [a] Under Windows 98, use the following HANDLE:

         ::OpenProcess(PROCESS_ALL_ACCESS, FALSE, ::GetCurrentProcessId());

  [b] Under Windows 2000, Windows XP, Windows Me, use the following HANDLE:

         (HANDLE)GetCurrentProcessId()

  You will use the appropriate HANDLE ([a] or [b]) for all symbol
  handler functions, including the following:

         SymInitialize(...)
         StackWalk(...)
         SymGetModuleInfo(...)
         SymGetSymFromAddr(...)
         SymGetLineFromAddr(...)

Anyhow, these are what I consider to be the critical steps in
getting started with symbol handling and stack tracing.

Here are examples of what you get for various kinds of
"Release" builds:


[1] Default (no debugging info, no program database (PDB)):
-----------------------------------------------------------

FATAL ERROR: Unhandled exception.
             Program address: 0x00401058.
             Offending thread: 0xFFFB678D.
             Exception: Integer divide-by-zero.
             OS info: Windows 98 4.10 (build 1998).
               0x00401058  <CRASH_TRACE>
               0x00401EAB  <CRASH_TRACE>
               0xBFF8B537  <KERNEL32>
               0xBFF8B3E9  <KERNEL32>
               0xBFF89DAC  <KERNEL32>

  NOTE: As you can see, you don't get function names.


[2] Program database (PDB), but no debugging info:
-----------------------------------------------------------

FATAL ERROR: Unhandled exception.
             Program address: 0x00401058.
             Offending thread: 0xFFF9FF69.
             Exception: Integer divide-by-zero.
             OS info: Windows 98 4.10 (build 1998).
               0x00401058  main
               0x00401F0F  mainCRTStartup
               0xBFF8B537  <KERNEL32>
               0xBFF8B3E9  <KERNEL32>
               0xBFF89DAC  <KERNEL32>

  NOTE: In this case you get function names, but no
  line numbers.  (If you have a PDB file for
  kernel32.dll, I suppose you could get function
  names for that module also.)


[3] Program database (PDB), and debugging info
  (Microsoft debugging info format, "Program Database"):
-----------------------------------------------------------

FATAL ERROR: Unhandled exception.
             Program address: 0x00401058.
             Offending thread: 0xFFF84B85.
             Exception: Integer divide-by-zero.
             OS info: Windows 98 4.10 (build 1998).
               0x00401058  main  (crash_trace.cpp, line 17) <CRASH_TRACE>
               0x00401F0F  mainCRTStartup
               0xBFF8B537  <KERNEL32>
               0xBFF8B3E9  <KERNEL32>
               0xBFF89DAC  <KERNEL32>


  NOTE: In this case you can get function names
  and line numbers. (If you have a PDB file for
  kernel32.dll, I suppose you could get function
  names for that module also.)

All of this is really great!  I am really excited by
the prospect of having my release applications essentially
debug themselves when a crash occurs.  Not that my applications
ever crash (except for the contrived example shown above)...
but it's nice to know that if it ever occurs, the app
will supply detailed information.  Maybe the Heisenberg
Uncertainty Principle will lead to pathological cases
in which the mere presence of debugging information in
the application will prevent or cause crashing, but I
will relish the irony!  (I've already experienced the
seriously demented case of an exception handler causing
yet another exception!)

Thanks again!  You know who you are.

--- Colin
cp...@ea...
www.colinfahey.com