The Old Joel on Software Forum: Part 4 (of 5)

Automatic bug reports

Hi all,
So I've read Joel's FogBUGZ bit on automatic crash reporting and I've been trying to implement something that would do this for c++ projects (visual studio 6)

(http://www.fogcreek.com/FogBUGZ/help/UsingFogBUGZtoGetCrashRep.html)

The main problem I have is that when you build the project in release mode all of the debugging information is stripped, so whilst I can be notified of a crash I'm not really given anything useful to go on. And even when I build with debug information turned on, it relies on the .pdb file to determine the line number of the crash, and that is something I don't really want to distribute.

So can any clever people enlighten me as to how I can get file name and line number reporting without all the debug symbols required. And if that's not possible, then just how useful is crash reporting, if all I can get is the system version, program version and, possibly, an error code?

Thanks,
Ben

Ben
Friday, February 13, 2004

Just be sure whenever you implement something like this you send the reports to an email alias, not a real email address.

I'm still getting bug and status reports from my last job. :)

Philo

Philo
Friday, February 13, 2004

You do not have to distribute the pdb file to the end user.

If your error reporting provides information about the location (address) of the crash (typically through a structure exception handler) then you can convert that information to a modle / file / line number later.

This can be done either manually using a map file generated by the linker (painful, but character building!) or automatically using the map file or a pdb file. I think John William's book 'Debugging Windows Applications' has a tool for this.

You might also want to do some research on the DbgHelp library that lets you work with PDB files.

See http://msdn.microsoft.com/library/en-us/debug/base/debug_help_library.asp

Rob Walker
Friday, February 13, 2004

You will need the exception address, the PDB files (for lookup) and the source code (optionally, to debug). The application, the PDB files and the source files have to be in synch. The PDB files and the source files (evidently) can be on a different computer.

Also *you have to know* the base address of the dlls in the running process on the target machine. These addresses may vary every time the application is started unless you rebased your dlls. If you didn't rebase the dlls you will have problems since the crash address will be useless unless you get access to the target machine and get a snapshot of the process.

If all these conditions are met, you can use the CrashFinder utility from here:
http://www.wintellect.com/about/instructors/robbins/code.aspx
to look-up the crash address and find the method that failed.

coresi
Friday, February 13, 2004

Thanks guys, that'll give me something to play with over the weekend.

Incidentally, I've just used a map file to find the location of a crash by hand from a release build. I never knew I could do that before, it's exhilarating!

Ben
Friday, February 13, 2004

Microsoft includes their symbol server technology with their free debugging tools for windows. It's really good for handling PDBs - you can just set up your build process to add your PDBs to the server then when you hit a breakpoint in a debugger or load up a core dump the debugger fetches the correct PDB from the server on the fly and if you need any symbols for Microsoft DLLs they have a public symbol server that you can connect to as well. You can download the debugging tools from the link below. Take a look in the WinDbg help file for symbol server details.
http://www.microsoft.com/whdc/ddk/debugging/

r1ch
Friday, February 13, 2004

Oh, and Microsoft also have seem to have a corresponding source server which pulls the source file versions that correspond to the PDB out of the version control system but they won't release it :-(

r1ch
Friday, February 13, 2004

I've had some success with adding structured exception handlers and walking the stack via the ExceptionRecords. Writing this code certainly makes you question your choice of implementation language, but if you are already invested in C++, it will make troubleshooting easier.

I found ISBN:0-7356-0886-5 (John Robbins, Debugging Windows Applications) very helpful in this exercise.

Danil
Friday, February 13, 2004

Post-Mortem Debugging Your Application with Minidumps and Visual Studio .NET:

http://www.codeproject.com/debug/postmortemdebug_standalone1.asp

Although you don't actually have to build your app with VS.NET. The article explains how to implement the Watson functionality present in Office XP and Windows XP (all that 'do you want to send an error report?' stuff).

John C
Saturday, February 14, 2004

Microsoft released their source server which pulls the source file versions that correspond to the PDB out of the version control system as of WinDBG version 6.3.17.0

Guillaume B.
Tuesday, June 15, 2004