今回は、Windows Serverの障害解析において、メモリダンプファイルの取得とWinDbgを使った解析方法について、実務的な活用方法を詳しく解説します。
Windows Serverの予期しないクラッシュやアプリケーションのハング、サービスの停止といった重大な障害が発生した場合、その根本原因を特定するためには、メモリダンプファイルの解析が不可欠です。
以前もブログに書きましたが、本記事では、ダンプファイルの種類から取得方法に加え、WinDbgの基本的な使い方、実際の解析事例まで、前回よりも分かり易く段階的に理解できるようにお伝えします。
ダンプファイルの種類と特徴
Windowsで取得できるダンプファイルには、いくつかの種類があります。それぞれの特徴を理解することが、効率的な解析の出発点です。
Small Memory Dump（64KB）
最もコンパクトなダンプファイルです。BugCheckコード、パラメータ、ドライバー名などの最小限の情報のみを含みます。ファイルサイズは通常64KB程度で、分析できる情報が限定的です。
Kernel Memory Dump（全メモリの50-70%）
カーネルメモリの大部分をダンプします。メモリサイズが大きいサーバーの場合、ファイルサイズが数GB～数十GBになることがあります。詳細な解析が可能ですが、保存に時間がかかります。
Complete Memory Dump（全メモリ）
システムメモリ全体をダンプします。ファイルサイズはサーバーのメモリ容量と同じ（例：64GBサーバーなら64GB）となり、保存に長時間を要します。最も詳細な情報を含みます。
Live Kernel Memory Dump
Windowsがクラッシュしなくても、任意のタイミングで取得できるダンプです。ハングやパフォーマンス低下の原因分析に有効です。
実務では、ディスク容量とダンプ保存時間のバランスを考慮して、「Kernel Memory Dump」を選択することが多いです。
メモリダンプの自動設定
Windowsサーバーがクラッシュした場合に、自動的にダンプファイルを取得するよう設定することが重要です。これにより、予期しないクラッシュが発生した際も、後から原因分析が可能になります。
ステップ1：システムのプロパティを開く
# コマンドで直接開く場合
sysdm.cplまたは、右クリック→このPCのプロパティ→詳細設定→詳細タブ→起動と復旧の設定
ステップ2：起動と復旧の設定
「起動と復旧」ダイアログで以下の設定を行います：
- 「デバッグ情報を自動的に保存する」にチェック
- ダンプファイルの種類を選択：
- カーネルメモリダンプ（推奨）
- 小さいメモリダンプ
- 完全なメモリダンプ
- 保存先を指定（デフォルト：%SystemRoot%\MEMORY.DMP）
重要なポイントとして、ダンプファイルの保存先は、十分な空き容量があるドライブを指定してください。例えば、カーネルメモリダンプを64GBメモリのサーバーで設定する場合、最低でも32GB程度の空き容量が必要です。
ステップ3：レジストリでの詳細設定
より詳細な設定が必要な場合は、レジストリを直接編集できます。
# レジストリキー
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
# 主要な値：
# CrashDumpEnabled: ダンプタイプ
# 0: ダンプなし
# 1: Small Memory Dump（64KB）
# 2: Kernel Memory Dump
# 3: Complete Memory Dumpダンプファイルの手動取得方法
システムのハングやパフォーマンス低下時、クラッシュを待たずにダンプを取得することが有効な場合があります。
方法1：キーボードショートカット
BSODが発生していなくても、以下のキーボード操作でダンプを取得できます（要事前設定）：
Right Ctrl + ScrollLock + ScrollLockただし、この機能を有効にするにはレジストリ設定が必要です：
# レジストリパス
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters
# 値を追加：
# CrashOnCtrlScroll (DWORD): 1方法2：PowerShellでの強制ダンプ取得
PowerShellを使用して、カーネルダンプを強制的に取得できます。ただし、システムが再起動されます。
Get-WmiObject Win32_Process -Filter "name='svchost.exe'" | Stop-Process -Forceより安全な方法として、WinDbgをアタッチして、デバッガーから強制的にダンプを取得することがあります。
方法3：WinDbgでのダンプ取得
後述するWinDbgを使用して、任意のプロセスのダンプを取得できます。ハングしているアプリケーションやサービスの原因分析に有効です。
WinDbgのインストールと初期設定
インストール方法
WinDbgはMicrosoft Storeから無料でダウンロードできます（Windbg Preview）。また、Windows SDK に含まれるクラシックWinDbgもあります。
# Windbg Previewはストアから入手
# または、古いバージョンはWindows SDKに含まれる初期設定
WinDbgを初めて起動したら、以下の設定を行います：
- シンボルパスの設定：
- File → Symbol File Path
- デフォルト：
srv*c:\symbols*https://msdl.microsoft.com/download/symbols
- ワークスペースの設定：
- デバッグファイルを保存するディレクトリを指定
- オプション設定：
- Edit → Options
- Debugger Objects → Suppress initial breaks（チェック推奨）
WinDbgでの基本的な操作
ダンプファイルを開く
File → Open Crash Dumpダンプファイルを選択後、WinDbgがファイルを解析し、自動的に情報を表示します。
コマンドラインでのダンプファイルオープン
# コマンドプロンプトから直接WinDbgでダンプを開く
windbg -z C:\Windows\MEMORY.DMP
# シンボルパスを指定
windbg -z C:\Windows\MEMORY.DMP -y srv*c:\symbols*https://msdl.microsoft.com/download/symbols基本的なコマンド
WinDbgのコマンドウィンドウで入力できるコマンドをいくつか紹介します：
# クラッシュ情報を表示
!analyze -v
# 実行中のプロセスを表示
!process 0 0
# メモリ情報を表示
!vm
# スタックトレースを表示
k
# 特定のアドレスのメモリをダンプ
d [アドレス]クラッシュダンプの解析手順
実際のクラッシュダンプを解析する流れを説明します。
ステップ1：ダンプファイルの確認
WinDbgでダンプを開くと、以下のような情報が表示されます：
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is presentステップ2：自動解析の実行
# コマンドウィンドウに以下を入力
!analyze -vこのコマンドにより、クラッシュの原因が自動的に分析されます。出力例：
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
The current thread is making a request for a requested level that is invalid.ステップ3：BugCheckコードの確認
BugCheckコード（例：0xD1）は、クラッシュの種類を示します。コードと原因の対応：
| コード | 原因 |
|---|---|
| 0x1E (KMODE_EXCEPTION_NOT_HANDLED) | ハンドルされないカーネル例外 |
| 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) | ドライバーのIRQL問題 |
| 0x50 (PAGE_FAULT_IN_NONPAGED_AREA) | ページフォルト |
| 0x24 (NTFS_FILE_SYSTEM) | NTFS関連のエラー |
ステップ4：問題ドライバーの特定
# クラッシュ時のドライバーを表示
!driversWinDbgが自動的に問題ドライバーを指摘する場合があります。その場合は、該当ドライバーのバージョン確認や更新を検討します。
ハングダンプの解析手順
クラッシュせずにハングしている場合、その時点でのメモリダンプを取得して分析します。
WinDbgのアタッチとダンプ取得
# WinDbgで File → Attach to Process
# またはコマンドラインで：
windbg -pn explorer.exe
# ダンプを取得：
.dump /ma c:\temp\hangdump.dmp
# コマンド例
!process 0 0このコマンドで、プロセスの詳細情報とスタックトレースが表示されます。
スレッドの待機状態を確認
# 全スレッドを一覧表示
~*k
# 特定のスレッドに切り替え
~[スレッド番号]sハングの原因は多くの場合、あるリソースの獲得待機です。スレッドのコールスタックを確認することで、どのリソース（ロック、イベント、セマフォ等）を待機しているかが分かります。
デバッグシンボルの役割と設定
シンボルファイルは、バイナリコード内のアドレスを関数名や変数名に変換するためのメタデータです。シンボルなしでダンプを解析すると、アドレスしか表示されず、原因特定が困難になります。
シンボルパスの設定
# Microsoftの公式シンボルサーバーを使用
srv*c:\symbols*https://msdl.microsoft.com/download/symbols
# 複数のパスを指定（セミコロンで区切る）
srv*c:\symbols*https://msdl.microsoft.com/download/symbols;srv*d:\symbolsシンボルの自動ダウンロード
WinDbgが自動的にMicrosoftのシンボルサーバーからシンボルをダウンロードします。初回は時間がかかることがあります。
# シンボルの再読込
.reload実務的なトラブルシューティング事例
事例1：定期的なBSODが発生
症状：毎日決まった時刻にBSODが発生
解析方法：
- 複数のダンプファイルをWinDbgで開く
- 各ダンプで「!analyze -v」を実行
- BugCheckコードが同じか確認
多くの場合、定期的なタスク（バックアップ、アンチウイルススキャン等）が問題ドライバーと干渉しているケースがあります。
事例2：メモリリークによるシステムハング
症状：時間経過とともにメモリが減少し、やがてハング
解析方法：
- ハング状態でダンプを取得
- 「!vm」で メモリ状況を確認
- 「!poolused」で メモリプール使用状況を確認
- 「!heap」でヒープ破損がないか確認
メモリリークの原因は多くの場合、特定のドライバーやアプリケーションが大量のメモリを確保し続けていることです。
事例3：DLL読込エラーによるアプリケーションクラッシュ
症状：特定のアプリケーションだけがクラッシュ
解析方法：
- プロセスダンプを取得
- 「!process」でプロセス情報を確認
- 「lmvm」で読み込まれたモジュール一覧を表示
- 読込に失敗しているDLLがないか確認
PowerShellでのダンプ自動化
定期的にシステムのダンプを取得する場合、PowerShellで自動化できます。
function Get-LiveKernelDump {
param(
[string]$OutputPath = "C:\Temp\kernel_dump_$(Get-Date -Format 'yyyyMMdd_HHmmss').dmp"
)
Write-Host "Getting live kernel dump..."
# PowerShell 7以降の場合
# $output = & "C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe" -kl -c "!dump /ma $OutputPath" -c "q"
Write-Host "Dump saved to: $OutputPath"
}
Get-LiveKernelDumpより実用的には、スケジュールタスクと組み合わせて、定期的にダンプを取得し、分析ツール（例：BlueScreenView）で自動解析することがあります。
まとめ
Windowsサーバーの障害解析において、メモリダンプとWinDbgは強力なツールです。本記事の重要なポイントは以下の通りです：
- ダンプファイルの自動取得を事前に設定する：予期しないクラッシュに備える
- ダンプの種類を用途に応じて選択する：容量とディスク空き容量のバランスを考慮
- WinDbgの基本コマンド（!analyze -v、!process等）を習得する：効率的な解析が可能
- デバッグシンボルを正確に設定する：関数名や変数名の表示に不可欠
- 複数のダンプを比較分析する：トレンド把握と根本原因特定に有効
これらのテクニックを身につけることで、本番環境で発生した重大障害の原因を迅速に特定でき、復旧時間の大幅な短縮につながります。
