Re: General dr.watson
From: Oleg Starodumov (com-dot-debuginfo-at-oleg)
Date: 11/26/04
- Next message: Petar Popara: "Efficient debugging"
- Previous message: John Davy: "connecting a datasource for word merging"
- In reply to: Hugo Mind: "General dr.watson"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 26 Nov 2004 09:58:25 +0200
> Has someone a tutorial or can explain me howto read a dr.watson log and
> user.dmp to find back what caused my crash ?
>
Download and install Debugging Tools for Windows:
http://www.microsoft.com/whdc/ddk/debugging/default.mspx
In the Debugging Tools' help, see "Crash Dump Files" section.
In particular, it contains the information about reading Dr. Watson log.
Preconditions to successful analysis:
1) All executables must be built with debug information (now it usually means PDB file).
2) All application DLLs are rebased to unique addresses
3) All released executables and corresponding debug information files
are saved in a safe location
If debug information was available with the executables on the machine
where the crash occurred, Dr.Watson log can contain useful information.
Then you have to locate the faulting address and module in the log, and also
check the call stack to see how the application came to that place.
With the crash address and module, you can locate the source file/line by loading
the application into VS debugger (making sure that the failed module has been loaded),
opening Disassembly window, navigating to the crash address and R-Click + Go To Source.
If debug information was not available with the executables on the machine where
the crash occurred, Dr. Watson log is unlikely to be useful. Then you have
to debug the crash dump.
WinDbg (part of the Debugging Tools) is the most convenient debugger for that.
You usually have to do the following:
1. Open the crash dump in WinDbg.
2. Set image path so that it points to the place where application binaries are located
(the same that were running at the moment of the crash; with full dump it is usually
possible to debug without modules).
3. Set symbol path so that it points to the place where debug information files
for the application binaries are located. You might also need to set up the symbol path
to point to symbol server, so that you can download matching debug information
for system DLLs (and the DLLs themselves, if the crash happened on XP or newer system).
4. Run "!analyze -v" command and read its output.
5. Run ".ecxr;kb" command to get the call stack at the moment of the crash.
You can also debug crash dump files with Visual Studio debuggers,
but they are not as reliable as WinDbg in that area.
Here are good articles about dump debugging with VS.NET debugger:
http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
http://msdn.microsoft.com/library/en-us/vsdebug/html/vxtskCrashDumps.asp
Regards,
Oleg
- Next message: Petar Popara: "Efficient debugging"
- Previous message: John Davy: "connecting a datasource for word merging"
- In reply to: Hugo Mind: "General dr.watson"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
