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 an analysis of why an application hung 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 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 BugCheckCode [BugParameters]
Displays information about the bug check specified by BugCheckCode. BugParameters specifies up to four bug check parameters separated by spaces. These parameters enable you to further refine your search.
-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 installation of Debugging Tools for Windows to have this file.)
The list of known issues in the KnownIssuesFile file is used for all later -c commands until you use -c **** -unload, or until you use -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.
DLL
Ext.dll
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.
Remarks
In user mode, !analyze displays information about the current exception.
In kernel mode, !analyze displays 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.
For drivers that use User-Mode Driver Framework (UMDF) version 2.15 or later, !analyze provides information about UMDF verifier failures and unhandled exceptions. This functionality is available when performing live kernel-mode debugging, as well when analyzing a user-mode memory dump file. For UMDF driver crashes, !analyze attempts to identify the responsible driver.
Debugging environments
If your computer has Visual Studio and the WDK installed, then you have six available debugging environments. For descriptions of these environments, see Debugging Environments.
All of these debugging environments provide user interfaces for the same underlying debugging engine, which is implemented in the Windows Symbolic Debugger Engine (Dbgeng.dll). This debugging engine is also called the Windows debugger, and the six debugging environments are collectively called the Windows debuggers.
Windows debuggers
The Windows debuggers can run on x86-based, x64-based, or ARM-based processors, and they can debug code that is running on those same architectures. Sometimes the debugger and the code being debugged run on the same computer, but other times the debugger and the code being debugged run on separate computers. In either case, the computer that is running the debugger is called the host computer, and the computer that is being debugged is called the target computer. The Windows debuggers support the following versions of Windows for both the host and target computers.
- Windows 10 and Windows Server 2016
- Windows 8.1 and Windows Server 2012 R2
- Windows 8 and Windows Server 2012
- Windows 7 and Windows Server 2008 R2