Tracking down crashes on Win32 systems

<< Multi-version concurrency control | Database technology articles | Tracking down crashes on Linux >>

Tracking down crashes on Win32 systems

Authors: Nickolay Samofatov, January 8th 2004, updated Octer 17th 2005 and July 6th 2007 by Vlad Horsum. Copyright IBPhoenix.com.

Firebird 2.x

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. 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

Firebird 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.

Firebird 1.0x

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_MACHINE\SOFTWARE\Microsoft\DrWatson]
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 its 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.

NOTE: You can install the Firebird PDB on your machine and see source code information in Dr.Watson itself whilst the crash is actually happening.

Further reading:
Database corruption
Database validation
Firebird database housekeeping utility
GFIX
GBAK and GSPLIT
Backup database
Restore database
System objects
Forced writes
Database properties
Firebird for the database expert: Episode 3 - On Disk Consistency
Preventing data loss
Alternative database repair methods
Detect and avoid database errors
Structure of a header page
How to analyse and repair a corrupted database