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

  1. Open and Administrator PowerShell prompt.

  2. 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
  1. 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
  1. The output will indicate that the requested information is being generated.
Gathering storage subsystem diagnostic information                                                                         
Running                                                                                                                 
[oooooooooooo                                                                                              ] 
  1. 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
  1. 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.

Code Name
0x000000AB SESSION_HAS_VALID_POOL_ON_EXIT
0x00000117 VIDEO_TDR_TIMEOUT_DETECTED
0x00000141 VIDEO_ENGINE_TIMEOUT_DETECTED
0x00000142 VIDEO_TDR_APPLICATION_BLOCKED
0x00000156 WINSOCK_DETECTED_HUNG_CLOSESOCKET_LIVEDUMP
0x0000015C PDC_WATCHDOG_TIMEOUT_LIVEDUMP
0x0000015D SOC_SUBSYSTEM_FAILURE_LIVEDUMP
0x0000015E BUGCODE_NDIS_DRIVER_LIVE_DUMP
0x0000015F CONNECTED_STANDBY_WATCHDOG_TIMEOUT_LIVEDUMP
0x00000161 LIVE_SYSTEM_DUMP
0x00000165 CLUSTER_CSV_STATUS_IO_TIMEOUT_LIVEDUMP
0x00000166 CLUSTER_RESOURCE_CALL_TIMEOUT_LIVEDUMP
0x00000167 CLUSTER_CSV_SNAPSHOT_DEVICE_INFO_TIMEOUT_LIVEDUMP
0x00000168 CLUSTER_CSV_STATE_TRANSITION_TIMEOUT_LIVEDUMP
0x00000169 CLUSTER_CSV_VOLUME_ARRIVAL_LIVEDUMP
0x0000016A CLUSTER_CSV_VOLUME_REMOVAL_LIVEDUMP
0x0000016B CLUSTER_CSV_CLUSTER_WATCHDOG_LIVEDUMP
0x0000016F CLUSTER_CSV_STATE_TRANSITION_INTERVAL_TIMEOUT_LIVEDUMP
0x00000175 PREVIOUS_FATAL_ABNORMAL_RESET_ERROR
0x00000179 CLUSTER_CLUSPORT_STATUS_IO_TIMEOUT_LIVEDUMP
0x0000017C PDC_LOCK_WATCHDOG_LIVEDUMP
0x0000017D PDC_UNEXPECTED_REVOCATION_LIVEDUMP
0x00000187 VIDEO_DWMINIT_TIMEOUT_FALLBACK_BDD
0x00000188 CLUSTER_CSVFS_LIVEDUMP
0x00000190 WIN32K_CRITICAL_FAILURE_LIVEDUMP
0x00000193 VIDEO_DXGKRNL_LIVEDUMP
0x00000195 SMB_SERVER_LIVEDUMP
0x00000198 UFX_LIVEDUMP
0x0000019D CLUSTER_SVHDX_LIVEDUMP
0x000001A1 WIN32K_CALLOUT_WATCHDOG_LIVEDUMP
0x000001A3 CALL_HAS_NOT_RETURNED_WATCHDOG_TIMEOUT_LIVEDUMP
0x000001A4 DRIPS_SW_HW_DIVERGENCE_LIVEDUMP
0x000001A5 USB_DRIPS_BLOCKER_SURPRISE_REMOVAL_LIVEDUMP
0x000001A6 BLUETOOTH_ERROR_RECOVERY_LIVEDUMP
0x000001A7 SMB_REDIRECTOR_LIVEDUMP
0x000001A8 VIDEO_DXGKRNL_BLACK_SCREEN_LIVEDUMP
0x000001A9 DIRECTED_FX_TRANSITION_LIVEDUMP
0x000001B0 VIDEO_MINIPORT_FAILED_LIVEDUMP
0x000001B8 VIDEO_MINIPORT_BLACK_SCREEN_LIVEDUMP
0x000001C4 DRIVER_VERIFIER_DETECTED_VIOLATION_LIVEDUMP
0x000001C5 IO_THREADPOOL_DEADLOCK_LIVEDUMP
0x000001C9 USER_MODE_HEALTH_MONITOR_LIVEDUMP
0x000001CC EXRESOURCE_TIMEOUT_LIVEDUMP
0x000001D1 TELEMETRY_ASSERTS_LIVEDUMP
0x000001D4 UCMUCSI_LIVEDUMP
0x000001E1 DEVICE_DIAGNOSTIC_LOG_LIVEDUMP
0x000001F5 APPLICATION_HANG_KERNEL_LIVEDUMP
0x000021C8 MANUALLY_INITIATED_BLACKSCREEN_HOTKEY_LIVE_DUMP

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

See also

Bug Check Code Reference

!analyze

Bug Checks (Blue Screens)

Analyze Bug Check Blue Screen Data