Kernel Live Dump Code Reference
This section contains descriptions of common kernel live dump codes that may occur. Live dumps do not reset the OS, but allow for the capture of memory information for abnormal situations where the operating system can continue.
Note
This topic is for programmers. If you are a customer whose system has displayed a blue screen with a bug check code, see Troubleshoot blue screen errors.
Kernel live dump compared to bug check
With a traditional bug check, the PC resets and the user's work is disrupted. The goal of kernel live dump is to gather data to trouble shoot an abnormal situation, but allow the OS to continue operation. This reduces downtime when compared to a bug check for “non-fatal” but high-impact failures and hangs. Kernel live dumps are used when it is possible to recover the OS to a known good state. For example a hardware reset of a subsystem, such as video/display, USB3 or Wi-Fi can allow those systems to return to a known good state, with minimal user impact.
A kernel live dump creates a consistent snapshot of kernel memory and saves it to a dump file for the future analysis. To minimize impact on the performance, memory copy techniques are used to create the dump file in a short period of time. In addition, the collection of live dumps is throttled, so that user impact is minimized.
A kernel live dump is effective for a category of problems where something is taking a long time, and yet nothing is technically failing. A watchdog timer can be initialized when an operation is started. If the watchdog expires before operation completes with in the expected time, a live dump of the system can be taken. Then the dump can be analyzed by traversing the call stack and related wait chain for that operation to investigate why it is not completing with the expected time frame.
System logs work well when something fails and the code owner has recorded the cause of the failure and can identify the cause. Live dumps that use watchdog timers attempt to catch failure paths that were not anticipated and logged. But as with every failure, the system logs may identify other issues that may provide clues to the specific root cause of the failure.
Kernel live dump file contents
Similar to regular dump files, live dump files may contain minidumps (with secondary data), and full kernel dumps, which may also include user mode memory, similar to active dumps. For general information about dump file contents, see Varieties of Kernel-Mode Dump Files. Some live dumps only attempt to capture minidumps, as they are designed to capture specific hardware-related data, while others may attempt to capture a larger kernel live dump.
For performance, file size and for the reliability of dump captures, some information is not included, such as pages from the stand by list and file caches.
Live dump files typically contain memory pages such as:
- KdDebuggerBlock
- Loaded Module List
For each processor the following information is captured in kernel dumps:
- KiProcessorBlock
- PRCBs
- Current stack
- Current page directory table
- KI_USER_SHARED_DATA
- NTOS Kernel Image
- HAL Image
Additional information in kernel dumps may include:
- Thread / memory state
- In-memory logging
Some live dumps may contain user-mode process pages.
Additional domain specific data, for example USB specific data for USB failures, may be included for some live dumps.
Partial kernel live dump file
A partial kernel live dump file may be generated in situations when live dump cannot reliably capture all intended memory pages. The information that is captured in a partial dump is filtered and prioritized, by capturing pages that contain important data required to generate a valid dump before other pages. For instance, the kernel pages are prioritized over user pages, when the live dump includes user pages. In some situations there are not enough resources available to capture all intended optional memory pages, so memory may be missing from the dump file. The dump file should still be recognized by the WinDbg debugger but may show errors when trying to dump memory. If the debugger shows an error when attempting to dump memory at an address, you can use the !pte extension to check whether the PTE for an address is valid or not. This can help to determine if the memory address is really invalid, or if the page is valid but just not available in the dump file.
Analyzing live dump files
When a live dump occurs, the dump file can be analyzed using the same techniques used for other memory dump files. To understand the contents of memory during a failure, knowledge of processor memory registers and assembly programming is required.
For more information, see:
Using WinDbg to display live dump stop code information
If a specific live dump code does not appear in this topic, use the !analyze extension in the Windows Debugger (WinDbg) with the following syntax (in kernel mode), replacing <code> with a live dump code:
!analyze -show <code>
Entering this command causes WinDbg to display information about the specified live dump code. If your default number base (radix) is not 16, prefix <code> with 0x.
Provide the live dump code parameters to the !analyze command to display any available parameter information. For example, to display information on Bug Check 0x144 BUGCODE_USB3_DRIVER, with a parameter 1 value of 0x3003, use !analyze -show 0x144 0x3003 as shown here.
0: kd> !analyze -show 0x144 0x3003
BUGCODE_USB3_DRIVER (144)
This bugcheck usually happens when the USB3 core stack detects an invalid
operation being performed by a USB client. This bugcheck may also occur
due to hardware failure on a USB Boot Device.
Arguments:
Arg1: 0000000000003003, USB3_WER_BUGCODE_USBHUB3_DEVICE_ENUMERATION_FAILURE
A USB device failed enumeration.
Arg2: 0000000000000000, USBHUB3_LIVEDUMP_CONTEXT
Arg3: 0000000000000000, 0
Arg4: 0000000000000000, 0
To download WinDbg, see Debugging Tools for Windows. To learn more about the WinDbg development tools, see Getting Started with Windows Debugging.
Live dump file locations
The live dumps by default are stored in the 'C:\WINDOWS\LiveKernelReports' directory.
Full dumps: %systemroot%\LiveKernelReports\*.dmp
Minidumps: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
A directory structure is used to store live dumps for different components.
NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG
Live dump registry keys
For more information on configuration options for system-generated live kernel reports, see WER Settings.
Use PowerShell to manually trigger a live dump
Open and Administrator PowerShell prompt.
Get the StorageSubsystem friendly name by using Get-StorageSubSystem PowerShell command.
C:\> Get-StorageSubSystem
FriendlyName HealthStatus OperationalStatus
------------ ------------ -----------------
Windows Storage on 10-2411-PC Healthy OK
- Use Get-StorageDiagnosticInfo to generate a live dump for the above subsystem (along with other diagnostic logs). For more information see Get-StorageDiagnosticInfo.
C:\> Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName "Windows Storage on 10-2411-PC" -IncludeLiveDump -DestinationPath C:\destinationfolder
- The output will indicate that the requested information is being generated.
Gathering storage subsystem diagnostic information
Running
[oooooooooooo ]
- The dump will be inside
[DestinationPath]\localhost.
C:\> dir C:\destinationfolder\localhost\*.dmp
Directory: C:\destinationfolder\localhost
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/5/2016 1:08 PM 867135488 LiveDump.dmp
- Using the debugger to run !analyze on the dump file will indicate that this is a live dump code of LIVE_SYSTEM_DUMP (161).
Kernel live dump codes
The following table provides links to kernel live dumps codes.
These stop codes can be used for live dumps or to bug check the device.
| Code | Name |
|---|---|
| 0x00000124 | WHEA_UNCORRECTABLE_ERROR |
| 0x00000144 | BUGCODE_USB3_DRIVER |
| 0x00000164 | WIN32K_CRITICAL_FAILURE |