Chapter 12: Finding Source and Line Information with Just a Crash Address

Overview

Your program has crashed. You have the crash address because the operating system is nice enough to give it to you when your application dies. Now what do you do? My friend Chris Sells calls this scenario the "my program went on vacation and all I got was this lousy address" problem. Although having the address is better than nothing, having the source file and the line number of the crash would be much more convenient. I suppose you could always give the source code to your users and have them debug it for you, but I just don't see that happening any time soon.

That crash address is generally all you're going to get if you're very lucky. Microsoft has worked hard to make it easier for their people to track down issues on Microsoft Windows 2000, Windows XP, and Windows Server 2003. Troubleshooting is a little more confusing when your users tell you that your application has had a problem. The default unhandled exception handler displays the fancy new "We are sorry for the inconvenience" dialog box shown in Figure 12-1. The big problem is that the crash dialog box no longer shows you the crash address! This is a classic case of a change that is friendlier for users but worse for us developers.

Figure 12-1: Standard Windows XP crash dialog box

To get the crash address, click the To See What Data This Error Report Contains, Click Here link and, in the next dialog box, click the To View Technical Information About The Error Report, Click Here link. In the Error Report Contents dialog box, shown in Figure 12-2, you'll see the crash address and all the loaded modules. Additionally, you'll get a really useful stack dump that's big enough to see almost to the beginning of time for the thread that crashed. Amazingly, someone made a really bad decision and put all that great information in a static control, so you can't copy it. I certainly hope Microsoft will fix this annoying oversight in a future service pack of Windows XP. The good news is that Windows 2000 and Windows Server 2003 always show the crash address in the crash dialog box.

Figure 12-2: Error Report Contents dialog box in Windows XP

The good news is that Dr. Watson will still run no matter what button you click in the crash dialog box provided Dr. Watson is set as the debugger to launch, which it should be for default installations. If it's not, have your users run DRWTSN32.EXE –i to set Dr. Watson as the default debugger. To get the information out of Dr. Watson, you'll just need to make sure your users know to start Dr. Watson with the DRWTSN32.EXE command and to copy the crash out of the Dr. Watson user interface (UI). (Refer to Appendix A for detailed information about Dr. Watson logs and how to interpret them.) If you're lucky, your users will be able to send you the minidump files, so make sure they check Create Crash Dump File in the Dr. Watson UI and note where the files are written. Of course, most of us are doing well if we get just a crash address. If you're totally proactive, you'll have your crashing application sending you the minidump automatically, which I'll also discuss in Chapter 13. Obviously, you need a way to convert that crash address to the source file and line number in your application. In this chapter, I'll explain how to accomplish that. I'll concentrate on the two main ways of converting the address: using MAP files and using CrashFinder, a utility included with this book's sample files.

To maximize the techniques in this chapter, you need to have your program compilation set up as I described in Chapter 2. You need to be building your release builds with full debugging symbols and generating MAP files for them. Additionally, you must fix any DLL load address conflicts. If you don't take these steps, the techniques I present in this chapter won't completely work and the only way you'll be able to figure out the source file and line number for a crash address is through pure guessing.