Tracking Down Crashes on Windows Systems
On Systems without Dr. Watson
Firebird since 1.5
In the firebird.conf file, there is a new parameter - BugcheckAbort, which by default is set to 0, if set to 1 and uncommented, this parameter determines whether to call abort()or BUGCHECK when an internal Firebird error occurs. If set to 1 and a bugcheck occurs the server will invoke a post-mortem debugger which will cause a traceable core dump to be produced that can be used for further analyis.
You need to set up Dr.Watson as your default windows crash handler. It is installed normally as default, but various development tools e.g Delphi, etc., may have replaced it. To do this, you need to run run "drwtsn32 -i" from the command prompt (drwtsn32 is an utility that is shipped with Windows).
Set up Dr.Watson as follows:
- Set the "Log File Path"
- Check "Dump All Thread Contexts" and Append To Existing Log File"
- Uncheck "Dump Symbol Table", "Visual Notification", "Sound Notification" and "Create Crash Dump File"
- Set the "Number of Instructions" to at least to 25
- You can leave the "Number of Errors To Save" at the default value of (10)
You should have something that looks like this picture:
- You may want to create crash dump or one of the project developers may have asked you to create it. To do this check the "Create Crash Dump File".
- You may also download the "pdb" (Debug) Firebird installation and extract its contents to the bin folder - This will allow Dr.Watson to create a much more useful and detailed log file. This is optional but highly recommended to do. The more detail the better.
- Don't use the Guardian! The Guardian prevents Dr.Watson from creating the crash log. So make sure the Guardian is turned off.
- Since Firebird V1.5 there is a new parameter in the firebird.conf file. This parameter is BugcheckAbort, which by default is set to 0. If it is set to 1 and uncommented, this parameter determines whether to call abort() or BUGCHECK when an internal Firebird error occurs. If set to 1 and such an error occurs the server will invoke a post-mortem debugger which will cause a traceable core dump to be produced that can then be used for further analyis. So make sure you edit firebird.conf and set BugcheckAbort = 1 (don't forget to remove leading # to uncomment)
- [Re]Start Firebird
- After the crash occurs you need to send Dr.Watson's the crash log (found at the "Log File Path" folder) to the one of project developers.
If you need to get information from a Firebird process that has hung, then you need to do the following
- Kill the process using Dr.Watson
- drwtsn32 -p
- where the PID is the ID of the hung process
PDB is the program database that is generated along with binaries during the compilation process on Win32. It maps binary instructions to lines and variables in the source code. By reproducing the crash conditions while running under a binary built with the appropriate PDB, it is possible to dump useful information to track down the causes of the crash.
Begin by downloading the appropriate PDB package, Windows Debug Build, or the Embedded Server Debug Build for Windows.
Set Up For Debugging
Install the ZIP package.
Set up Dr.Watson as your windows crash handler. It is installed there by default, but various tools like Delphi, etc., may replace it. To do this, use the "drwtsn32" utility shipped with Windows.
Set it up for creating full dumps. Although newer Dr.Watson versions have a GUI, one way to do this is to set the Registry keys as follows:
System Key: [HKEY_LOCAL_MACHINESOFTWAREMicrosoftDrWatson] Value Name: CreateCrashDump DataType: REG_DWORD (DWORD Value) Value Data: (0 = disabled, 1 = enabled)
Reproduce the problem and send resulting DUMP to a person who can reconcile it. This individual can hope that one of the facts below is true:
Newer versions of Visual Studio can use the PDB from an older version of the compiler used to produce release binaries.
An older version of Visual Studio can open dumps produced by a recent version of Dr.Watson. It is possible for full dumps, but it ability to open a minidump is unlikely, since this first appeared in Windows XP.
If both facts are false or VS7+ is unavailable then one has to resort to getting useful data using the WinDBG tool, which can be pretty hard work.
However, even the crash address on its own, or a Dr.Watson crash log, can give useful clues on the nature of the problem if there is appropriate PDB available.
You can install the Firebird PDB on your machine and see source code information in Dr.Watson itself whilst the crash is actually happening.