Using Symbol Files and Debuggers
You
can also analyze memory dump files by using a kernel debugger. Kernel
debuggers are primarily intended to be used by developers for in-depth
analysis of application behavior. However, kernel debuggers are also
useful tools for administrators troubleshooting Stop errors. In
particular, kernel debuggers can be used to analyze memory dump files
after a Stop error has occurred.
A
debugger is a program that users with the Debug Programs user right (by
default, only the Administrators group) can use to step through
software instructions, examine data, and check for certain conditions.
The following two examples of kernel debuggers are installed by
installing Debugging Tools For Windows.
Kernel Debugger
Kernel
Debugger (Kd.exe) is a command-line debugging tool that you can use to
analyze a memory dump file written to disk when a Stop message occurs.
Kernel Debugger requires that you install symbol files on your system.
WinDbg Debugger
WinDbg Debugger (WinDbg.exe) provides functionality similar to Kernel Debugger, but uses a GUI interface.
Both
tools allow users with the Debug Programs user right to analyze the
contents of a memory dump file and debug kernel-mode and user-mode
programs and drivers. Kernel Debugger and WinDbg Debugger are just a
few of the many tools included in the Debugging Tools For Windows
installation. For more information about these and other debugging
tools included with Debugging Tools For Windows, see Help in Debugging
Tools For Windows.
To use WinDbg to analyze a crash dump, first install the debugging tools available at http://www.microsoft.com/whdc/devtools/debugging/.
To
gather the most information from a memory dump file, provide the
debugger access to symbol files. The debugger uses symbol files to
match memory addresses to human-friendly module and function names. The
simplest way to provide the debugger access to symbol files is to
configure the debugger to access the Microsoft Internet-connected
symbol server.
To configure the debugger to use the Microsoft symbol server, follow these steps:
1. | Click
Start, point to All Programs, point to Debugging Tools For Windows,
right-click WinDbg, and then click Run As Administrator.
|
2. | On the File menu, click Symbol File Path.
|
3. | In the Symbol path box, type:
SRVlocalpathhttp://msdl.microsoft.com/download/symbols
where localpath
is a path on the hard disk that the debugger will use to store the
downloaded symbol files. The debugger will automatically create localpath when you analyze a dump file.
For example, to store the symbol files in C:\Websymbols, set the symbol
file path to
“SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols.”
|
4. | Click OK.
Debuggers do not require access to symbol files to extract the Stop
error number and parameters from a memory dump file. Often, the
debugger can also identify the source of the Stop error without access
to symbols.
|
Note
You can also download symbol files for offline use from http://www.microsoft.com/whdc/devtools/debugging/. |
To analyze a memory dump file, follow these steps:
1. | Click
Start, point to All Programs, point to Debugging Tools For Windows,
right-click WinDbg, and then click Run As Administrator.
|
2. | On the File menu, click Open Crash Dump.
|
3. | Type the location of the memory dump file, and then click Open. By default, this location is %systemroot%\memory.dmp.
|
4. | In the Save Workspace Information dialog box, click No.
|
5. | Select the Command window.
As shown in Figure 7,
the Bugcheck line tells you the Stop error number. The Probably Caused
By line indicates the file that was being processed at the time of the
Stop error.
|
The
Command window displays feedback from the debugger and allows you to
issue additional commands. When a crash dump is opened, the Command
window automatically displays the output of the !analyze command. In
many cases, this default information is sufficient to isolate the cause
of the Stop error.
If the default
analysis does not provide all the information you need for
troubleshooting, run the following command in the Command window:
This command will display the stack,
which contains a list of method calls preceding the Stop error. This
might give clues to the source of a Stop error. For example, the
following stack trace output, created by calling !analyze –v, correctly
indicates that the Stop error was related to the removal of a USB
device:
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
ba4ffb2c ba26c6ff 89467df0 68627375 70646f52 0x8924ed33
ba4ffb5c ba273661 88ffade8 8924eae0 89394e48 usbhub!USBH_PdoRemoveDevice+0x41
ba4ffb7c ba26c952 88ffaea0 89394e48 00000002 usbhub!USBH_PdoPnP+0x5b
ba4ffba0 ba26a1d8 01ffaea0 89394e48 ba4ffbd4 usbhub!USBH_PdoDispatch+0x5a
ba4ffbb0 804eef95 88ffade8 89394e48 88eac2e0 usbhub!USBH_HubDispatch+0x48
ba4ffbc0 ba3f2db4 88eac228 88eac2e0 00000000 nt!IopfCallDriver+0x31
ba4ffbd4 ba3f4980 88eac228 89394e48 89394e48 USBSTOR!USBSTOR_FdoRemoveDevice+0xac
ba4ffbec b9eed58c 88eac228 89394e48 89394f48 USBSTOR!USBSTOR_Pnp+0x4e
