クラッシュダンプ収集入門【WER/ProcDump/WinDbg】

まず結論

クラッシュダンプ収集は、次の順番で考えるのが分かりやすいです。

1. まず WER LocalDumps をアプリ単位で設定する（追加ツール不要）
2. 必要なら ProcDump を足す（再現率の低い現場調査、hang、first chance exception 向け）
3. さらに制御したいなら MiniDumpWriteDump で自前収集

クラッシュダンプで分かること

• どの例外コードで落ちたか
• どのスレッドが落ちたか
• その時点のコールスタック
• 読み込まれていたモジュール
• ヒープ上の状態やオブジェクトの中身（含めた場合）

ダンプだけで完結しようとせず、ログや heartbeat と組み合わせるのが基本。

収集方法の全体像

WER LocalDumps の設定

レジストリ設定

アプリ単位のサブキーで設定するのが扱いやすい。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe

設定例

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\MyApp" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 2 /f

確認ポイント

1. 想定のフォルダに .dmp が出るか
2. サイズが運用想定に合うか
3. WinDbg で開けるか
4. Event Viewer の Application ログで crash が見えるか

ProcDump の使い方

よく使うオプション

代表的なコマンド例

# 既に起動中のプロセスを未処理例外でフルダンプ
procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

# 次回起動を待って監視
procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

# first chance exception も取りたい
procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

# ハングを取りたい
procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

ミニダンプ vs フルダンプ

おすすめ: 開発機/検証機ではフルダンプ、顧客環境ではミニかフルを運用条件で選ぶ。

ダンプ取得後の解析手順

WinDbg のインストール

winget install Microsoft.WinDbg

ダンプを開く

windbg -z C:\CrashDumps\MyApp\MyApp_YYMMDD_HHMMSS.dmp

シンボル設定

.symfix C:\Symbols\Microsoft
.sympath+ C:\Symbols\MyApp
.reload

自動解析

!analyze -v

その後、例外コード、faulting module、自分のコードがスタックに見えるか、例外スレッド以外に怪しい待ちがないかを確認する。

運用で先に決めておくこと

1. PDB とバイナリをどう残すか: 配布した EXE/DLL の正確な版と対応する PDB を保管。これがないとダンプは読めない
2. 出力先と保持数: システムドライブ直下に置かない。専用フォルダに分離し、上限を切る
3. 誰が見てよいか: フルダンプには機密情報（接続文字列、トークン、業務データ）が混ざる可能性がある

よくあるはまりどころ

• ダンプは取れたが PDB がない → 収集設定と同時に PDB 保管設計も入れる
• DumpFolder の ACL を確認していない → プロセスが本当に書けるか先に確認
• フルダンプを本番機のシステムドライブに出し続ける → 容量事故の定番
• WER だけで hang も見ようとする → hang や first chance は ProcDump のほうが向いている
• -e 1 を常時入れて例外の嵐になる → 件数制限や短時間だけの使用が現実的

まとめ

クラッシュダンプは、再現率の低い障害に対して強力な観測点。おすすめの順番は WER → ProcDump → MiniDumpWriteDump。ダンプと同じくらい PDB の保管が重要。

参考資料

• Microsoft Learn: ユーザーモード ダンプの収集 - Win32 apps
• Microsoft Learn: ProcDump v11.1 - Sysinternals
• Microsoft Learn: MiniDumpWriteDump function (minidumpapiset.h) - Win32
• Microsoft Learn: User-mode dump files - Windows drivers
• Microsoft Learn: ユーザー モード ダンプ ファイルの分析 - Windows drivers
• Microsoft Learn: Windows デバッガーをインストールする - Windows drivers
• Microsoft Learn: Symbol path for Windows debuggers - Windows drivers
• Microsoft Learn: !analyze (WinDbg) - Windows drivers
• Microsoft Learn: Troubleshoot processes by using Task Manager - Windows Server
• Microsoft Learn: Enabling Postmortem Debugging - Windows drivers