How To Debug Windows Crash Dumps (Minidump)Find out what crashed your computer with this tutorial on using the Microsoft Debug Tools to analyse Windows Crash Dumps.
Fed up with those pesky Blue Screen of Deaths? Find out what crashed your computer with this short tutorial on using the Microsoft Debug Tools to analyse unexpected system reboots and locate the driver or programs responsible.
Each time Windows crashes with a blue screen, it will create a minidump file which contains loads of information about the system at the time of the system crash. It includes information about drivers that are loaded, Windows Updates, memory locations and a memory dump of the kernel. This minidump can then be loaded into the debug tools and the cause of the problem can be determined.
The first thing you need is the debug tools from Microsoft. You do not need Visual Studio or any other program to analyse minidump files.
Once installed you will have a link to "Debugging Tools for Windows (x86)" on the Start Menu under which you can run WinDbg.
Installing Debugging Tools for Windows
The first time you run the tool you will need to set up the symbol path which tells the tool about the environment. Symbols are needed so that the tools know about the various components and that the tool has access to the debug information within the components.
Within WinDbg you need to select from the File Menu » Symbol File Path. This will present a dialogue with an empty box where you can enter a path. Using the path below, WinDbg will download the symbols it needs from the Microsoft website.
SRV * c:symbols * http://msdl.microsoft.com/download/symbols
Click on OK and then File » Save Workspace so we don't have to set the path again.
Anaylyse Windows Crash Dumps - What Caused BSOD
From the File menu in WinDbg select "Open Crash Dump" and browse to a crash minidump file (typically located within C:\WINDOWS\Minidump). The filenames are stored with a date stamp in the format of mmddyy). When you open a file it will ask to save workspace information, select no, and it will then begin processing the minidump file and give you a bug check analysis.
In this example, I am debugging a crash file from another machine so some of the files cannot be checked.
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Mini062908-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Sun Jun 29 11:06:27.767 2008 (GMT+1)
System Uptime: 7 days 1:18:54.062
Loading Kernel Symbols
.............................................................................................................
Loading User Symbols
Loading unloaded module list
........................
Unable to load image SYMTDI.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for SYMTDI.SYS
*** ERROR: Module load completed but symbols could not be loaded for SYMTDI.SYS
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyse -v to get detailed debugging information.
BugCheck 1000000A, {c0000000, 2, 0, 80505c1f}
*** WARNING: Unable to verify timestamp for Rtnicxp.sys
*** ERROR: Module load completed but symbols could not be loaded for Rtnicxp.sys
Probably caused by : SYMTDI.SYS ( SYMTDI+13a4a )
Followup: MachineOwner
--------- We can see here that the problem is likely to have been caused by SYMTDI.SYS. We can use the !analyze -v command to get more detailed information about the bug check. Commands can be entered at the bottom of the screen at the "kd>" prompt.
Identify What Crashed in Windows Crash Dumps
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available to get the stack backtrace.
Arguments:
Arg1: c0000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 80505c1f, address which referenced memory It will also spew out the stack trace and raw hex dump, but we are not interested in that.
We now know that SYMTDI.SYS was the cause of the problem and we know about the error message that the system generated. A quick look on Google shows us that SYMTDI.SYS is part of Norton Antivirus, so I can now look for updates or patches for this software.
