【windows】dumpの設定およびサーバトラブル例を交えた解析方法

今回は、Windowsサーバーで発生したブルースクリーンなどの問題解決に欠かせない「ダンプファイル」について詳しく解説します。システム障害が発生した際に原因を特定するための強力なツールであるダンプファイルの種類、設定方法、そして実際の解析方法まで丁寧に説明していきます。

Windowsダンプファイルとは？

ダンプファイルの種類

ダンプファイルの設定方法

クラッシュダンプの解析手順

実践例：ブルースクリーンの原因を特定する

よくあるトラブルと対処法

まとめ

Windowsダンプファイルとは？

Windowsダンプファイルとは、システムがクラッシュした時点のメモリ状態を記録したファイルです。これはいわば「事故現場の写真」のようなもので、問題が発生した瞬間の状況を捉えています。

ダンプファイルを解析することで、システム障害の原因となったドライバやプロセス、メモリの状態などを特定できるため、トラブルシューティングにおいて非常に重要な役割を果たします。

特にサーバー環境では、安定した運用が求められるため、問題が発生した際の原因特定と再発防止にダンプファイルの解析スキルは欠かせません。

ダンプファイルの種類

Windowsでは主に4種類のダンプファイルが存在します。それぞれの特徴と用途を理解しましょう。

### 完全メモリダンプ（Complete Memory Dump）

* **特徴**: システムメモリの全内容を記録
* **サイズ**: 物理メモリと同等（例：16GBのRAMなら約16GB）
* **メリット**: すべての情報が含まれるため、詳細な解析が可能
* **デメリット**: サイズが非常に大きく、保存や転送に時間がかかる

### カーネルメモリダンプ（Kernel Memory Dump）

* **特徴**: カーネルが使用しているメモリ領域のみを記録
* **サイズ**: 物理メモリの約1/3程度
* **メリット**: 多くの問題解析に十分な情報を含みつつ、サイズを抑えられる
* **デメリット**: ユーザーモードプロセスの詳細情報は含まれない

### 最小メモリダンプ（Small Memory Dump / Minidump）

* **特徴**: クラッシュ原因の特定に最低限必要な情報のみを記録
* **サイズ**: 通常256KB〜2MB程度
* **メリット**: サイズが小さく、複数保存可能
* **デメリット**: 限られた情報のみのため、詳細な解析には不十分な場合がある

### 自動メモリダンプ（Automatic Memory Dump）

* **特徴**: Windows 8以降のデフォルト設定で、カーネルダンプと似ているが自動的にサイズ最適化
* **サイズ**: システム環境に応じて変動
* **メリット**: 管理が容易
* **デメリット**: カスタマイズ性に欠ける

ダンプファイルの設定方法

ダンプファイルを適切に取得するには、事前に正しい設定をしておく必要があります。以下に、Windows Serverでの設定手順を紹介します。

### システムプロパティからの設定方法

1. **コントロールパネルを開く**
* スタートメニュー → コントロールパネル → システムとセキュリティ → システム → システムの詳細設定
* または、「Win + Pause/Break」キーを押してシステム画面を開き、左側の「システムの詳細設定」をクリック

2. **詳細設定タブの設定**
* 「詳細設定」タブを選択
* 「起動と回復」セクションの「設定」ボタンをクリック

3. **ダンプファイルの設定**
* 「システムエラー」セクションで以下を設定:
* 「システムエラー時に自動的に再起動する」にチェック（推奨）
* 「デバッグ情報の書き込み」で希望するダンプタイプを選択
* ダンプファイルの保存先を指定（デフォルト: %SystemRoot%\MEMORY.DMP）

### レジストリからの設定（上級者向け）

レジストリエディターを使用して直接設定することも可能です：

reg add "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 2 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v DumpFile /t REG_EXPAND_SZ /d "%SystemRoot%\MEMORY.DMP" /f

**注意**: 値の意味は以下の通りです:
* CrashDumpEnabled：0=なし、1=完全ダンプ、2=カーネルダンプ、3=最小ダンプ、7=自動ダンプ

### ページングファイルの設定

ダンプファイルを正しく生成するには、適切なサイズのページングファイルが必要です：

1. システムプロパティ → 詳細設定 → パフォーマンス「設定」ボタン
2. パフォーマンスオプション → 詳細設定タブ → 仮想メモリ「変更」ボタン
3. 以下の設定を推奨:
* システム管理サイズのチェックを外す
* 初期サイズ = 物理メモリ + 257MB
* 最大サイズ = 物理メモリ × 1.5倍以上

クラッシュダンプの解析手順

ダンプファイルを解析するためには、適切なツールが必要です。ここでは、Microsoft提供の無料ツール「Windows Debugging Tools」を使用した解析方法を紹介します。

### 必要なツールの準備

1. **Windows Debugging Tools (WinDbg)のインストール**
* Windows SDKのインストール時にオプションとして選択
* または「Windows ADK」からDebugger Toolsのみをインストール可能

2. **シンボルファイルの設定**
* シンボルファイルは、ダンプ内のアドレスと実際のコード位置を関連付ける重要なファイル
* WinDbgを起動し、以下のコマンドを実行:

.sympath srv*c:\symbols*https://msdl.microsoft.com/download/symbols
.symfix c:\symbols
.reload

### シンボルパスとは？（補足）

シンボルパスとは、WinDbgがデバッグ情報（シンボル）を検索する場所を指定するための設定です。これを正しく設定することが、ダンプ解析の成功において非常に重要です。

* **シンボルの役割**: シンボルは「翻訳者」のような役割を果たします。ダンプファイルには「0xFFFF8000123456」のような意味不明な数字（メモリアドレス）が記録されていますが、シンボルファイルがあれば「ntoskrnl!KeBugCheck+0x123」のような人間が理解できる関数名に変換できます。

* **シンボルパスの構成**:
* `srv*ローカルキャッシュフォルダ*シンボルサーバーURL`の形式で指定
* 例: `.sympath srv*c:\symbols*https://msdl.microsoft.com/download/symbols`
* この設定は「Microsoftのシンボルサーバーからシンボルを取得し、ローカルの`c:\symbols`フォルダにキャッシュする」という意味です

* **なぜオンラインシンボルサーバーが必要か**:
* Windowsには何千ものコンポーネントがあり、それぞれのバージョンごとにシンボルファイルが存在します
* これらをすべてローカルに保存するのは現実的ではないため、必要なときに必要なファイルだけをダウンロードする仕組みになっています

* **シンボルパスの確認方法**:
* WinDbgで`.sympath`コマンドを実行すると現在の設定を確認できます
* シンボルの読み込み状況は`.reload /f`コマンドで確認できます

### 基本的な解析手順

1. **WinDbgの起動とダンプファイルの読み込み**
* WinDbgを管理者権限で起動
* File → Open Crash Dumpからダンプファイルを選択

2. **初期解析の実行**
* 以下のコマンドを実行して基本的な解析を行う:

!analyze -v

* このコマンドでクラッシュの原因と考えられる情報が表示される

3. **スタックトレースの確認**
* クラッシュ時の呼び出し履歴を確認:

kb

4. **関連モジュールの確認**
* 読み込まれているドライバ一覧を確認:

lm

* 特定のモジュール（例: ntoskrnl.exe）の詳細を確認:

lmvm ntoskrnl

実践例：ブルースクリーンの原因を特定する

ここでは、実際のサーバークラッシュ事例をもとに、ダンプ解析の流れを見ていきましょう。

### 事例: ディスクドライバによるBSOD（ブルースクリーン）

サーバーが定期的にブルースクリーンで停止する問題が発生。エラーコードは「SYSTEM_SERVICE_EXCEPTION」。

#### 解析ステップ

1. **初期解析の実行**

!analyze -v

結果例:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80002c4b4d0, Address of the instruction which caused the bugcheck
Arg3: ffffd000237ef7c0, Address of the context record for the exception
Arg4: 0000000000000000, zero

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

EXCEPTION_RECORD:  ffffd000237ef7c0 -- (.exr 0xffffd000237ef7c0)

CONTEXT:  ffffd000237ee9d0 -- (.cxr 0xffffd000237ee9d0)

PROCESS_NAME:  System

ANALYSIS_VERSION: 10.0.22000.1 amd64 fre

TRAP_FRAME:  ffffd000237ef930 -- (.trap 0xffffd000237ef930)

MODULE_NAME: storport

IMAGE_NAME: storport.sys

2. **クラッシュの原因を特定するためのポイント**

上記の結果から、以下の重要な情報を読み取ります：

• エラーコード: 0xc0000005 はメモリアクセス違反を示す標準的なエラーコードです
  • このコードはプログラムが不正なメモリ領域にアクセスしようとしたことを意味します
• 問題モジュール: MODULE_NAME: storport と IMAGE_NAME: storport.sys の行に注目
  • これは問題が発生したドライバを示しています（この場合はストレージドライバ）
• プロセス名: PROCESS_NAME: System はこの問題がカーネルモードで発生したことを示します
• バグチェックコード: SYSTEM_SERVICE_EXCEPTION (3b) はシステムサービス実行中の例外を示します

3. **さらに詳細を調査**

.exr 0xffffd000237ef7c0
.cxr 0xffffd000237ee9d0
kb

上記のコマンドの意味：
* `.exr` – 例外レコードの詳細情報を表示（どの種類のメモリアクセス違反が発生したかなど）
* `.cxr` – スレッドコンテキストを設定（エラー発生時の CPU レジスタの状態）
* `kb` – スタックトレースを表示（どの関数呼び出しの流れでエラーが発生したか）

スタックトレース結果例：

# ChildEBP RetAddr  Args to Child              
00 ffffd000`237ef930 fffff800`031d7369 0000000000000000 0000000000000000 0000000000000000 : storport!StorPortNotification+0x176
01 ffffd000`237ef970 fffff800`031d6cb2 000000000000000e ffffd000237efa50 ffffd000226ef080 : ataport!IdePortNotification+0x85
02 ffffd000`237ef9b0 fffff800`031d5a94 ffffd000226ef080 0000000000000000 0000000000000000 : ataport!IdeCompleteScsiIrp+0x192
...

この結果から分かること：
* 問題はstorport.sysのStorPortNotification関数で発生
* その前にataport.dllの関数が呼び出されている
* スタックトレースを見ると、問題がストレージサブシステム内で発生していることが確認できる

4. **ドライバ情報の確認と詳細解析**

lmvm storport

結果例:
start end module name
fffff800`02c00000 fffff800`02c8f000 storport (deferred)
Image path: \SystemRoot\System32\drivers\storport.sys
Image name: storport.sys
Timestamp: Wed Jun 23 05:44:59 2021
CheckSum: 00082D3C
ImageSize: 0008F000
File version: 10.0.19041.1151
Product version: 10.0.19041.1151

ドライバ情報で確認すべきポイント：
* **バージョン情報**：`File version: 10.0.19041.1151` – Windows 10/Server 2019のバージョン
* **タイムスタンプ**：`Timestamp: Wed Jun 23 05:44:59 2021` – ドライバの日付
* **イメージパス**：`Image path: \SystemRoot\System32\drivers\storport.sys` – ドライバの場所

さらに詳しいドライバ解析：

!drvobj storport 2

これにより、ドライバオブジェクトの詳細（主要な関数ポインタなど）が表示されます。

5. **原因の特定と対策**

• 上記の解析から、次のことが分かります：
  • storport.sysドライバ内でメモリアクセス違反が発生
  • 具体的にはStorPortNotification関数内で問題が発生
  • ストレージサブシステムの処理中にエラーが発生
• 考えられる原因：
  • ドライバのバグ（特定の条件下でのメモリ管理の問題）
  • ハードウェアとの互換性の問題
  • ストレージコントローラのファームウェアの問題
  • 物理的なハードウェアの障害（不安定なディスクなど）
• 対策:
  • Windowsアップデートによるドライバの更新
    • Windows Updateを実行
    • Microsoft Update Catalogから最新のstorport.sysを検索
  • ハードウェアベンダーからの最新ドライバインストール
    • サーバーベンダーのサポートサイトを確認
    • RAID/HBAコントローラのメーカーサイトを確認
  • ストレージ制御カードのファームウェア更新
    • サーバー管理ソフトウェアを使用したファームウェア更新
  • 物理ディスクの診断
    • S.M.A.R.T.データの確認
    • ディスク診断ツールの実行

よくあるトラブルと対処法

ダンプファイルの取得や解析時によくある問題とその対処法をまとめました。

### ダンプファイルが生成されない

* **確認点1**: ページングファイルの設定
* 解決策: 適切なサイズのページングファイルが設定されているか確認

* **確認点2**: ディスク空き容量
* 解決策: システムドライブに十分な空き容量があるか確認（最低でも物理メモリ以上）

* **確認点3**: 書き込み権限
* 解決策: システムアカウントにダンプディレクトリへの書き込み権限があるか確認

### シンボルが読み込めない

* **確認点**: インターネット接続
* 解決策: プロキシ設定の確認またはオフラインシンボルパッケージのダウンロード

* **シンボルパスの手動設定**:

.sympath+ C:\LocalSymbols
.reload

* **シンボルが読み込めない場合の詳細解説**:
* シンボルが読み込めないとは、WinDbgがダンプ内のメモリアドレスを関数名などに変換できない状態です
* 症状: アドレス（0xFFFFF8000123ABCD）は表示されるが、関数名（ntoskrnl!KeBugCheck）が表示されない
* 影響: エラーの原因となったドライバや関数を特定できず、適切な対処ができない

* **シンボル読み込み失敗の主な原因**:
* インターネット接続がなく、Microsoftのシンボルサーバーにアクセスできない
* プロキシ環境での接続設定が不適切
* ローカルシンボルキャッシュフォルダへの書き込み権限がない
* ディスク容量不足でシンボルファイルを保存できない
* サードパーティ製ドライバのシンボルが提供されていない

* **オフライン環境での対応策**:
* 事前にオンライン環境でシンボルをダウンロードしておく
* Microsoft Symbol Packagesを入手（開発者向けサイトから）
* シンボルキャッシュフォルダをオンライン環境からオフライン環境へコピー

### 解析結果が不明確

* **確認点**: 追加のデバッグコマンド実行
* 詳細なスタックトレース: `k 100`
* プロセス情報: `!process 0 0`
* プール情報: `!poolused`

まとめ

Windowsのダンプファイルは、システム障害の原因を特定するための強力なツールです。特にサーバー環境では、ダウンタイムの最小化と根本原因の特定のために、適切なダンプファイルの設定と解析スキルは欠かせません。

本記事で学んだポイントをまとめます：

1. **適切なダンプタイプの選択**
* サーバー環境では通常、カーネルダンプまたは自動メモリダンプが推奨される
* 詳細な分析が必要な場合は完全メモリダンプを検討

2. **正しい環境設定**
* 十分なページングファイルサイズの確保
* 適切なディスク空き容量の確保
* 定期的なテスト（設定が機能しているか確認）

3. **体系的な解析アプローチ**
* WinDbgの基本コマンドの習得
* シンボルパスの正しい設定
* ステップバイステップの原因追求

ダンプファイルの解析は最初は難しく感じるかもしれませんが、基本的な手順を押さえれば、システム障害が発生した際に「何が起きたのか分からない」という状況を減らし、迅速な復旧と再発防止につながります。ぜひダンプ解析について理解を深めましょう。