カーネルライブダンプコードリファレンス

[アーティクル]
08/29/2024

このセクションでは、発生する可能性がある一般的なカーネルライブダンプコードについて説明します。ライブダンプでは OS はリセットされませんが、通常とは異なる状況でオペレーティングシステムを続行できる場合のメモリ情報をキャプチャできます。

Note

このトピックはプログラマー向けです。カスタマーのシステムでブルースクリーンとバグチェックコードが表示された場合は、「ブルースクリーンエラーのトラブルシューティング」を参照してください。

カーネルライブダンプとバグチェックの比較

従来のバグチェックでは、PC がリセットされ、ユーザーの作業が中断されます。カーネルライブダンプの目標は、データを収集して通常とは異なる状況のトラブルシューティングを行うことですが、OS の操作は続行することができます。これにより、バグチェックと比較すると "致命的ではない" 場合はダウンタイムが短縮されますが、影響が大きい場合は失敗して停止します。カーネルライブダンプは、OS を既知の正常な状態に回復できる場合に使用されます。たとえば、サブシステムのハードウェアリセット (ビデオやディスプレイ、USB3、Wi-Fi など) を使用すると、ユーザーへの影響を最小限に抑えて、システムを正常な状態に戻すことができます。

カーネルライブダンプは、カーネルメモリの一貫したスナップショットを作成し、将来の分析のためにダンプファイルに保存します。パフォーマンスへの影響を最小限に抑えるために、メモリコピー手法を使用して、短時間でダンプファイルを作成します。また、ライブダンプのコレクションが調整されるため、ユーザーへの影響が最小限に抑えられます。

カーネルライブダンプは、何らかの処理に長時間かかっているものの、技術的な障害は発生していない問題のカテゴリに対して有効です。ウォッチドッグタイマーは、操作の開始時に初期化できます。想定時間内に操作が完了する前にウォッチドッグの有効期限が切れる場合、システムのライブダンプを実行することができます。その後、その操作の呼び出し履歴と関連する待機チェーンを走査してダンプを分析し、想定時間時間内に完了しない原因を調査することができます。

システムログは、何らかのエラーが発生し、コード所有者がエラーの原因を記録して、原因を特定できるときに適切に動作します。ウォッチドッグタイマーを使用するライブダンプでは、予想されず記録されなかったエラーのパスをキャッチしようとします。ただし、すべてのエラーと同様に、システムログによって、エラーの特定の根本原因に関する手掛かりを示す可能性がある他の問題が特定されることがあります。

カーネルライブダンプファイルコンテンツ

通常のダンプファイルと同様に、ライブダンプファイルには、(セカンダリデータを含む) ミニダンプと、アクティブダンプに似ているユーザーモードメモリも含む可能性のある完全なカーネルダンプが含まれることがあります。ダンプファイルコンテンツに関する一般的な情報については、「さまざまなカーネルモードダンプファイル」をご覧ください。特定のハードウェア関連データをキャプチャするように設計されているため、ミニダンプのキャプチャのみを試みるライブダンプもあれば、より大きなカーネルライブダンプのキャプチャを試みるライブダンプもあります。

パフォーマンス、ファイルサイズ、ダンプキャプチャの信頼性のために、スタンドバイ一覧およびファイルキャッシュのページなど、一部の情報は含まれていません。

通常、ライブダンプファイルには、次のようなメモリページが含まれます。

KdDebuggerBlock
読み込まれたモジュール一覧

各プロセッサについて、カーネルダンプでは次の情報がキャプチャされます。

KiProcessorBlock
PRCB
現在のスタック
現在のページのディレクトリテーブル
KI_USER_SHARED_DATA
NTOS カーネルイメージ
HAL イメージ

カーネルダンプの追加情報には、次のものが含まれます。

スレッドまたはメモリの状態
メモリ内のログ

一部のライブダンプには、ユーザーモードのプロセスページが含まれている場合があります。

USB 障害の USB 固有データなど、追加のドメイン固有データが、一部のライブダンプに含まれている場合もあります。

部分的なカーネルライブダンプファイル

部分的なカーネルライブダンプファイルは、ライブダンプがすべての対象のメモリページを確実にキャプチャできない状況において生成される可能性があります。部分的なダンプでキャプチャされた情報は、有効なダンプの生成に必要な重要なデータを含むページを他のページより前にキャプチャすることにより、フィルター処理されて優先順位が設定されます。たとえば、ライブダンプにユーザーページが含まれている場合、カーネルページはユーザーページよりも高い優先順位が設定されます。状況によっては、すべての対象のオプションのメモリページをキャプチャするために使用できるリソースが不足しているため、ダンプファイルにメモリがない可能性があります。ダンプファイルは引き続き WinDbg デバッガーによって認識される必要がありますが、メモリをダンプしようとするとエラーが表示されることがあります。 1 つのアドレスでメモリをダンプしようとするとデバッガーにエラーが表示される場合は、!pte 拡張機能を使ってアドレスの PTE が有効かどうかを確認できます。これは、メモリアドレスが本当に無効であるかどうか、またはページは有効であるものの、単にダンプファイルで使用できないだけかどうかを判断するのに役立ちます。

ライブダンプファイルを分析する

ライブダンプが発生すると、他のメモリダンプファイルに使用されているのと同じ手法を使ってダンプファイルを分析することができます。エラー発生時のメモリのコンテンツを理解するには、プロセッサのメモリレジスタとアセンブリのプログラミングに関する知識が必要になります。

詳細については、以下を参照してください:

WinDbg を使用してライブダンプ停止コード情報を表示する

特定のライブダンプコードがこのトピックに含まれていない場合は、Windows Debugger (WinDbg) の !analyze 拡張機能を (カーネルモードで) お使いください。次の構文に従い、<code> をライブダンプコードで置き換えます。

!analyze -show <code>

このコマンドを入力すると、指定したライブダンプコードに関する情報が WinDbg によって表示されます。既定の基数が 16 ではない場合、<code> の前に 0x を付けます。

ライブダンプコードのパラメーターを !analyze コマンドに指定し、利用可能なパラメーターの情報を表示します。たとえば、バグチェック 0x144 BUGCODE_USB3_DRIVER に関する情報を表示するには、次に示されているように、パラメーター 1 の値に 0x3003 を指定して !analyze -show 0x144 0x3003 を使います。

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

WinDbg をダウンロードするには、Windows 向けデバッグツールを参照してください。 WinDbg 開発ツールの詳細情報については、「Windows のデバッグの概要」を参照してください。

ライブダンプファイルの場所

既定では、ライブダンプは 'C:\WINDOWS\LiveKernelReports' ディレクトリに格納されます。

完全なダンプ: %systemroot%\LiveKernelReports\*.dmp

ミニダンプ: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp

ディレクトリ構造は、さまざまなコンポーネントのライブダンプを格納するために使用されます。

NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG

ライブダンプレジストリキー

システム生成のライブカーネルレポートの構成オプションについて詳しくは、「WER 設定」をご覧ください。

PowerShell を使用してライブダンプを手動でトリガーする

管理者の PowerShell プロンプトを開きます。
StorageSubsystem のフレンドリ名を取得するには、Get-StorageSubSystem PowerShell コマンドを使用します。

 C:\> Get-StorageSubSystem
 FriendlyName                     HealthStatus OperationalStatus
 ------------                     ------------ -----------------
 Windows Storage on 10-2411-PC    Healthy      OK

Get-StorageDiagnosticInfo を使用して、上記のサブシステム (およびその他の診断ログ) のライブダンプを生成します。詳細については、「Get-StorageDiagnosticInfo」をご覧ください。

 C:\> Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName "Windows Storage on 10-2411-PC" -IncludeLiveDump -DestinationPath C:\destinationfolder

出力では、要求された情報が生成されていることが示されています。

Gathering storage subsystem diagnostic information                                                                         
Running                                                                                                                 
[oooooooooooo                                                                                              ]

ダンプは [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

デバッガーを使用してダンプファイルで !analyze を実行すると、これが LIVE_SYSTEM_DUMP (161) のライブダンプコードであることが示されます。