Using CrashFinder
As you just saw, reading a MAP or P2M file isn't too terribly difficult. It is rather tedious, however, and certainly not a scalable solution to others on your team, such as quality engineers, technical support staff, and even pointy haired managers. To address the issue of scalability in CrashFinder, I decided to make CrashFinder usable for all members of the development team, from individual developers, through test engineers, and on to the support engineers so that all crash reports include as much information as possible about the crash. If you follow the steps outlined in Chapter 2 for creating the appropriate debug symbols, everyone on your team will be able to use CrashFinder without a problem.
When using CrashFinder in a team setting, you need to be especially vigilant about keeping the binary images and their associated PDB files accessible because CrashFinder doesn't store any information about your application other than the paths to the binary images. CrashFinder stores only the paths to your binary files, so you can use the same CrashFinder project throughout the production cycle. If CrashFinder stored more detailed information about your application, such as symbol tables, you'd probably need to produce a CrashFinder project for each build. If you take this advice and allow easy access to your binaries and PDB files, when your application crashes, all your test or support engineers will have to do is fire up CrashFinder and add a vital piece of information to the bug report. As we all know, the more information an engineer has about the particular problem, the easier correcting the problem will be.
Depending on your application, you might want to have multiple CrashFinder projects for it. For example, you could have one project that points to the daily build location as well as different projects for each milestone release. If you opt to include system DLLs as part of your CrashFinder project, you'll need to create separate CrashFinder projects for each operating system you support. You'll also need to have a CrashFinder project for each version of your application that you send to testers outside your immediate development team, so you'll have to store separate binary images and PDBs for each version you send out.
CrashFinder has been quite a bit of fun to develop. I've been extremely honored by all the people who have told me that they've found it invaluable on their projects and that it's helped them do their jobs better. What's been even cooler is how many smart developers have jumped in with Ui and capabilities improvements. The CrashFinder version with this edition had lots of great work added by Scott Bloom, Ching Ming Kwok, Jeff Shanholtz, Rich Peters, Pablo Presedo, Julian Onions, and Ken Gladstone. I want to thank them for the code and for making CrashFinder even better.
Figure 12-4 shows the CrashFinder user interface with one of my personal projects loaded as a project. The top portion of the child window is a tree control that shows the executable and its associated DLLs. The green check marks indicate that the symbols for each of the binary images have been loaded properly. If CrashFinder couldn't load the symbols, a red X would indicate a problem. Additionally, the tree for the problem item would be expanded to show you exactly why CrashFinder could not properly load the binary.
|
CrashFinde |
r - [DisD,cfp] |
BBS | |
|
File Edit |
View Window Help |
JflJ xj | |
|
D & Q |
% | ||
• Loaded image COMCTL3 2.DLL SUGSLAYERUTIL.DLL
/ DISASMD.DLL USER32.DLL PEIMAGED.DLL RPCPT4,DLL ■J' MSVCRT.DLL
• Loaded image COMCTL3 2.DLL SUGSLAYERUTIL.DLL
/ DISASMD.DLL USER32.DLL PEIMAGED.DLL RPCPT4,DLL ■J' MSVCRT.DLL
0K7782 0000
Wed Dec 01 02:37:27 1999 SymPdb
E:\UINNT\5Y5TEH3 2\VERSION.DLL
\\hume\UebSymbols\version.dbg\3844D03 77000\version.dbg
Hexadecimal Address(es):
Post a comment