用WinDbg分析Dump文件,转自WinDbg帮助文件

   MS出的WinDbg是内核级调试利器,但我喜欢用它来调试客户端程序崩溃生成的Dump文件(运行状态生成Dump文件的方法可参见另一封转贴 http://blog.csdn.net/boythl/archive/2008/09/02/2868344.aspx). 

   Windbg中常用分析命令是: !analyze -v ,然后在分析结果里可以直接看到详细的调用堆栈; 另一个命令是: lmv ,该命令可以列举当前加载模板的详细数据.

   下文贴转自windbg的帮助文件; 第一部分是介绍,第二部分列举 !analyze 命令详解. 第三部分列举 lm 命令详解.

============================================================================

Analyzing a User-Mode Dump File with WinDbg

User-mode memory dump files can be analyzed by WinDbg. The processor or Windows version that the dump file was created on does not need to match the platform on which WinDbg is being run.

Installing Symbol Files

Before analyzing the memory dump file, you will need to install the symbol files for the version of Windows that generated the dump file. These files will be used by the debugger you choose to use to analyze the dump file. For more information about the proper installation of symbol files, see Installing Windows Symbol Files.

You will also need to install all the symbol files for the user-mode process, either an application or system service, that caused the system to generate the dump file. If this code was written by you, the symbol files should have been generated when the code was compiled and linked. If this is commercial code, check on the product CD-ROM or contact the software manufacturer for these particular symbol files.

Starting WinDbg

To analyze a dump file, start WinDbg with the -z command-line option:

windbg -y SymbolPath -i ImagePath -z DumpFileName 

The -v option (verbose mode) is also useful. For a full list of options, see WinDbg Command-Line Options.

If WinDbg is already running and is in dormant mode, you can open a crash dump by selecting the File | Open Crash Dump menu command or pressing the CTRL+D shortcut key. When the Open Crash Dump dialog box appears, enter the full path and name of the crash dump file in the File name text box, or use the dialog box to select the proper path and file name. When the proper file has been chosen, click Open.

You can also open a dump file after the debugger is running by using the .opendump (Open Dump File) command, followed with g (Go).

It is possible to debug multiple dump files at the same time. This can be done by including multiple -z switches on the command line (each followed by a different file name), or by using .opendump to add additional dump files as debugger targets. For information about how to control a multiple-target session, see Debugging Multiple Targets.

Dump files generally end with the extension .dmp or .mdmp. You can use network shares or Universal Naming Convention (UNC) file names for the memory dump file.

It is also common for dump files to be packed into a CAB file. If you specify the file name (including the .cab extension) after the -z option or as the argument to an .opendump command, the debugger can read the dump files directly out of the CAB. However, if there are multiple dump files stored in a single CAB, the debugger will only be able to read one of them. The debugger will not read any additional files from the CAB, even if they were symbol files or executables associated with the dump file.

Analyzing a Full User Dump File

Analysis of a full user dump file is similar to analysis of a live debugging session. See the Debugger Commands reference section for details on which commands are available for debugging dump files in user mode.

Analyzing Minidump Files

Analysis of a user-mode minidump file is done in the same way as a full user dump. However, since much less memory has been preserved, you are much more limited in the actions you can perform. Commands that attempt to access memory beyond what is preserved in the minidump file will not function properly.

Additional Techniques

For techniques that can be used to read specific kinds of information from a dump file, see Extracting Information from a Dump File.

© 2007 Microsoft Corporation
Send feedback on this topic
Debugging Tools for Windows / DRAFT VERSION
April 22, 2007

Build machine: CAPEBUILD

===============================================

!analyze

The !analyze extension displays information about the current exception or bug check.

Syntax

User-Mode

!analyze [-v] [-f | -hang] [-D BucketID] 
!analyze -c [ -load KnownIssuesFile | -unload | -help ]

Kernel-Mode

!analyze [-v] [-f | -hang]  [-D BucketID] 
!analyze -c [ -load KnownIssuesFile | -unload | -help ]
!analyze -show BugCheckCode [BugParameters] 

Parameters

-v

Displays verbose output.

-f

Generates the !analyze exception output. Use this parameter to see an exception analysis even when the debugger does not detect an exception.

-hang

Generates !analyze hung-application output. Use this parameter when the target has experienced a bug check or exception, but a hung state analysis is more relevant to your problem. In kernel mode, !analyze -hang investigates locks that the system holds and then scans the DPC queue chain. In user mode, !analyze -hang analyzes the thread stack analysis to determine whether any threads are blocking other threads.

Before you run this extension in user mode, consider changing the current thread to the thread that you think has stopped responding (that is, hung), because the exception might have changed the current thread to a different one.

-D BucketID

Displays only those items that are relevant to the specified BucketID.

-show

Displays information about the specified bug check code.

-c

Continues execution when the debugger encounters a known issue. If the issue is not a "known" issue, the debugger remains broken into the target.

You can use the -c option with the following subparameters. These subparameters configure the list of known issues. They do not cause execution to occur by themselves. Until you run !analyze -c -load at least one time, !analyze -c has no effect.

-load KnownIssuesFile

Loads the specified known-issues file. KnownIssuesFile specifies the path and file name of this file. This file must be in XML format. You can find a sample file in the sdk/samples/analyze_continue subdirectory of the debugger installation directory. (You must have performed a full install of Debugging Tools for Windows to have this file. For more information about a full installation, see Debugger Installation.)

The list of known issues in the KnownIssuesFile file is used for all later !analyze -c commands until you use !analyze -c -unload, or until you use !analyze -c -load again (at which point the new data replaces the old data).

-unload

Unloads the current list of known issues.

-help

Displays help for the !analyze -c extension commands extension in the Debugger Command window.

BugCheckCode

Specifies the bug check code to display.

BugParameters

Specifies up to four bug check parameters. Separate these parameters with spaces. This parameter enables you to further refine your search.

DLL

Windows NT 4.0	Ext.dll
Windows 2000	Ext.dll
Windows XP and later	Ext.dll

Comments

In user mode, the !analyze and !analyze -v extensions display information about the current exception.

In kernel mode, these extensions display information about the most recent bug check. If a bug check occurs, the !analyze display is automatically generated. You can use !analyze -v to show additional information. If you want to see only the basic bug check parameters, you can use the .bugcheck (Display Bug Check Data) command.

You can use the !analyzebugcheck -show extension command to display information about an individual bug check code. This display is not affected by the current status of the target computer.

The following example shows the results of !analyze after a breakpoint is hit.

0:000> !analyze
Last event: Hit breakpoint 10000

Additional Information

For sample analysis of a user-mode exception and of a kernel-mode stop error (that is, crash), and for more information about how !analyze uses the triage.ini file, see Using the !analyze Extension.

 

================================================

lm (List Loaded Modules)

The lm command displays the specified loaded modules. The output includes the status and the path of the module.

Syntax

lm Options [a Address] [m Pattern | M Pattern] 

Parameters

Options

Any combination of the following options:

o

Displays only loaded modules.

l

Displays only modules whose symbol information has been loaded.

v

Causes the display to be verbose. The display includes the symbol file name, the image file name, checksum information, version information, date stamps, time stamps, and information about whether the module is managed code (CLR). This information is not displayed if the relevant headers are missing or paged out.

u

(Kernel mode only) Displays only user-mode symbol information.

k

(Kernel mode only) Displays only kernel-mode symbol information.

e

Displays only modules that have a symbol problem. These symbols include modules that have no symbols and modules whose symbol status is C, T, #, M, or Export. For more information about these notations, see Symbol Status Abbreviations.

c

Displays checksum data.

1m

Reduces the output so that nothing is included except the names of the modules. This option is useful if you are using the .foreach token to pipe the command output into another command's input.

In addition, you can include only one of the following options. If you do not include any of these options, the display includes the symbol file name.

i

Displays the image file name.

f

Displays the full image path. (This path always matches the path that is displayed in the initial load notification, unless you issued a .reload -s command.) When you use f, symbol type information is not displayed.

n

Displays the image name. When you use n, symbol type information is not displayed.

p

Displays the mapped image name. When you use p, symbol type information is not displayed.

t

Displays the file time stamps. When you use t, symbol type information is not displayed.

a Address

Specifies an address that is contained in this module. Only the module that contains this address is displayed. If Address contains an expression, it must be enclosed in parentheses.

m Pattern

Specifies a pattern that the module name must match. Pattern can contain a variety of wildcard characters and specifiers. For more information about the syntax of this information, see String Wildcard Syntax.

Note  In most cases, the module name is the file name without the file name extension. For example, if you want to display information about the Flpydisk.sys driver, use the lm mflpydisk command, not lm mflpydisk.sys. In some cases, the module name differs significantly from the file name. For more information, see Executable Image Path.

M Pattern

Specifies a pattern that the image path must match. Pattern can contain a variety of wildcard characters and specifiers. For more information about the syntax of this information, see String Wildcard Syntax.

Environment

Modes	User mode, kernel mode
Targets	Live, crash dump
Platforms	All

Comments

The lm command lists all of the modules and the status of symbols for each module.

Microsoft Windows Server 2003 and later versions of Windows maintain an unloaded module list for user-mode processes. When you are debugging a user-mode process or dump file, the lm command also shows these unloaded modules.

This command shows several columns or fields, each with a different title. Some of these titles have specific meanings:

• module name is typically the file name without the file name extension. In some cases, the module name differs significantly from the file name. For more information, see Executable Image Path.
• The symbol type immediately follows the module name. This column is not labeled. For more information about the various status values, see Symbol Status Abbreviations. If you have loaded symbols, the symbol file name follows this column.
• The first address in the module is shown as start. The first address after the end of the module is shown as end. For example, if start is "faab4000" and end is "faab8000", the module extends from 0xFAAB4000 to 0xFAAB7FFF, inclusive.
• lmv only: The image path column shows the name of the executable file, including the file name extension. Typically, the full path is included in user mode but not in kernel mode.
• lmv only: The loaded symbol image file value is the same as the image name, unless Microsoft CodeView symbols are present. If CodeView symbols are present on Microsoft Windows NT 4.0, this value is the full path of the .dbg file.
• lmv only: The mapped memory image file value is typically not used. If the debugger is mapping an image file (for example, during minidump debugging), this value is the name of the mapped image.

The following code example shows the lm command with a Windows Server 2003 target computer. This example includes the m and s* options, so only modules that begin with "s" are displayed.

kd> lm m s*
start    end        module name
f9f73000 f9f7fd80   sysaudio     (deferred)                 
fa04b000 fa09b400   srv          (deferred)                 
faab7000 faac8500   sr           (deferred)                 
facac000 facbae00   serial       (deferred)                 
fb008000 fb00ba80   serenum      e:/mysymbols/SereEnum.pdb/.......
fb24f000 fb250000   swenum       (deferred)                 

Unloaded modules:
f9f53000 f9f61000   swmidi.sys
fb0ae000 fb0b0000   splitter.sys
fb040000 fb043000   Sfloppy.SYS

© 2007 Microsoft Corporation
Send feedback on this topic
Debugging Tools for Windows / DRAFT VERSION
April 22, 2007

Build machine: CAPEBUILD