Dr Watson Log

Dr. Watson is default windows program provided by operating system to capture application crash and its details. This program will be invoked when any run-time error (crash in application) occurs in any application in a system. This collects all possible log information about a specific crash in application to help a developer in analyzing cause of a crash. This utility creates two files drwtsn32.log and user.dmp.

When any program crash’s in windows system, system will search for a program error handler. If system is not able to find any error handler, it verifies if a program is running under debugger and transfers the control to debugger by allowing developer to examine the run-time state of a program. If not, system searches in registry for a debugger program to transfer control to handle this unhandled error.

System looks in a registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug for entries “Debugger” and “Auto”. “Debugger” key holds the value of a debugger which needs to run to analyze this unhandled error.

“Auto” key is set to 0 or 1. If the value is 0, then system will give Dialog box with two options “OK” and “Cancel”. If you select option “OK” it terminates current running program. If you select option “Cancel” then it launches the debugger to allow this crash to debug. If the value of “Auto” key is 1, it launches automatically debugger and allows to debug the runtime problem. This error handler is installed and “Auto” key is set to 1 by default.

Dr. Watson can generate more exact information if you provide the symbols of a Operating system. These symbols are available in a windows CD and you need to install based on the version of OS and Service pack.

Installing/Uninstalling Dr Watson Debugger

Installing Dr. Watson: For installing this utility, run command

Drwtsn32.exe -I

This replaces existing debugger (if any) in a “Debugger” registry Key. All programs uses this error handler tool for creating log file if there is any application crash. If you install Visual C++ after this it will overwrite this key and makes VC++ as default debugger.

Uninstalling Dr Watson: You have to remove key “AeDebug” from registry. This will disable. If there is no debugger installed for any program crash, it will just exit the program without giving any dialog box to indicate that something is crashed. But, if you check a Event log, you can identify which application is crashed.

Dr. Watson log file sections

Drwtsn32.log contains several sections and by analyzing these sections developer can try to identify what went wrong in an application. This log has following sections:

  • Application name and exception number: This section mentions which application is crashed including full path of file, Exception number, Date & Time when it is crashed and process ID.

  • System Information: This includes Computer name, User name who has logged currently, Terminal session, No of CPU, Processor Type, Windows version, Current build of windows, Service pack number, Current processor Type, Register organization and owner.

  • Task list: This contains list of current running applications and services during the crash of the application.

  • Module list: This list contains all DLL or loadable modules of a crashed application.

  • Stack dump for crash thread: This data is most important data and needs understanding of ASM code. This section includes all CPU registers of a crashed thread state. EIP register will point to a crashed instruction. “FAULT” point indicates which instruction it is crashed. I compiled following sample:

This source sample, I am assigning address as 6 and I am trying to copy the string to the same address. Dumped instruction in a log file is as follow:

Marked instruction is a faulty and if you decode this simple program, you can identify that it is trying to move a content of ECX register to address 6 (check 0023:00000006), this value is assigned in source file as a address. To decode this kind of error it needs ASM skills and Experience in debugging the programs. The more you debug the crashes, the more you get idea how to approach and understand this tools data.

0x0040100b – EIP register value where it is crashed. 0x8908 – This is opcode of a instruction which caused this crash.

  • Stack back trace: This section includes complete Call stack. This stack is decoded and displayed in format of: RetAddress, Arguments to child (for a function), Function name or address who called it. Using this method you can try to check who called some function and try to track it back.

If we don’t have any symbol installed in a local system, we get message of “Symbol file count not found”. You will get more accurate in this log file, if you have symbols installed for OS files and for your application.

  • Raw stack dump: This is useful if you want to see what all data was there during the crash of a application. If you don’t have any clue about a crash and if u have any strings present in a stack, you can try searching for it in source code to start debugging it. In Previous section it will display only half formatted strings how the data is pushed based on the stack data.


Marked data is displayed in previous section in formatted way.

  • Symbol table: This section will just list the entire symbol this crashed application is using.

Check crashed instruction location it is 0x0040100b which is very near to 0x00401000 of marked location. You will get a clue from where to start searching.

After getting this log file follow the steps to search for further clues:

  • Compile the same version of source code
  • Insert a breakpoint in starting of program
  • In Runtime, blindly switch to Disassembly window where it displays Assembly code for each respective source code
  • Press CTRL+G then enter address 0x0040100b of a crashed location. Once you reach this stage, you can search for clues here and there. Take a look at following figure for marked box’s for clues:

Look for these clues: Our crashed function is _main function, There is text “This is Test” and crashed instruction of location 0x0040100b

This log file goal is to give clues and not to solve your problem, so look as much as clues to solve your night mare problems.

Mini Dump/Full Dump

This dump file includes all the info which was there in drwatson.log file and allows you to analyze the problem using Windbg of Visual studio 2005 IDE. This will allow developer to search for clues in interactive way.

Usage of Dr. Watson (Drwtsn32.exe)

  • Specify file path for storing drwtsn32.log and user.dmp. You can specify same path for both of them.
  • WAV File, if you like some music when there is any crash, but I don’t think developer like this option, since after crash there will be music already for them to stay late.
  • Number of instructions: This helps how many instruction you want to store in a log file for a crashed thread.
  • Numbers of errors to save: How many crash you want to save in those mentioned file.
  • Dump symbol table: This helps you to understand ASM code better, if there is any function is referred from a DLL, instead of giving plan ASM instruction ( like CALL 0x100000 ), It will show like CALL strcpy.
  • Dump all thread contexts: This will help to see how many threads are running and CPU register value of each thread.
  • Append to Existing Log file
  • Visual Notification
  • Sound notification
  • Create Crash Dump file: Enable if you want just log file or also .dmp file.
  • Crash dump type: go for FULL option, since it includes whole program memory, program image, handle table, etc… which is very useful to analysis in debugger.