Re: [GD-Windows] Finding routine that's crashing
Brought to you by:
vexxed72
From: Colin F. <cp...@ea...> - 2002-08-08 01:21:11
|
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 |