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

Windows アプリで「たまにだけ落ちる」が始まると、ログだけでは追い切れない場面がかなりあります。

特につらいのは、こういうケースです。

• 顧客環境でしか起きない
• 例外メッセージは取れているが、呼び出し元の文脈が足りない
• C# / .NET の managed 側だけでなく、COM、P/Invoke、native DLL、vendor SDK が絡む
• 長時間運転後にだけ落ちる

こういうときに効くのがクラッシュダンプです。クラッシュ時点のプロセス状態をファイルに落としておけば、例外コード、落ちたスレッドのスタック、読み込まれていたモジュール、メモリの一部または全部を後から読めます。

Windows では、まず WER の LocalDumps、必要に応じて Sysinternals ProcDump、さらに制御したくなったら MiniDumpWriteDump を使う、という順で考えるのが分かりやすいです。この記事では、Windows デスクトップアプリ、常駐アプリ、Windows サービス、装置連携ツールなどを前提に、クラッシュダンプ収集の最初の一歩を整理します。

flowchart TB
    accTitle: 収集手段を考える順番
    accDescr: Windowsのクラッシュダンプ収集は、まずWERのLocalDumps、必要に応じてSysinternalsのProcDump、さらに制御したくなったらMiniDumpWriteDumpという順で考えるのが分かりやすいことを示す図。
    w1["まずWER LocalDumps"] --> w2["必要に応じてProcDump"]
    w2 --> w3["さらに制御したければMiniDumpWriteDump"]

図1: 標準機能から始めて、足りない分だけ道具を足していく順番。

この記事で繰り返し出てくる用語

先に、短く固めておきます。ここが曖昧なままだと、あとの章がぼやけます。

1. まず結論

最初に押さえたい点だけを先に並べます。

• まずは WER LocalDumps をアプリ単位で設定する のが無難です。追加ツールなしで、クラッシュ後にローカルへダンプを残せます。
• 再現率の低い現場調査や、first chance exception / hang まで見たいなら ProcDump を使います。
• 自前収集は最後に考える くらいでちょうどよいです。必要になってから MiniDumpWriteDump を検討すれば十分です。
• ダンプと同じくらい大事なのが PDB と配布バイナリの保管です。ダンプだけあっても、シンボルがなければ読める量がかなり減ります。
• フルダンプは強いが、サイズと機密情報の混入リスクも強いです。保管場所、保持数、アクセス権、共有手順を先に決めます。

入門段階のおすすめ構成は、だいたいこのあたりに落ち着きます。

要するに、最初は WER、次に ProcDump、最後に自前です。ここを逆順で始めると、だいたい設計が重くなります。

この記事の知識マップ

Windowsアプリのクラッシュダンプ収集は、追加ツールなしでアプリ単位に設定できるWER LocalDumpsをまず入れ、hangやfirst chance exceptionまで見たい場合や既に起動中のプロセスを監視したい場合にProcDumpを足し、独自の診断機能が必要になったときだけMiniDumpWriteDumpによる自前収集を検討するという順で考えるのが安全である。ダンプの種類はミニダンプとフルダンプで採れる情報の深さとサイズがトレードオフになり、.NETのCLRプロセスはProcDumpのMiniPlus指定でもフルダンプ相当のサイズになる。保存先フォルダの書き込み権限を確認しないと収集自体が空振りになり、取得したダンプはPDBと組み合わせてWinDbgで解析して初めて読める情報になる。

flowchart LR
    accTitle: Windowsクラッシュダンプ収集(WER/ProcDump/WinDbg)の知識マップ
    accDescr: WER LocalDumpsとProcDumpとMiniDumpWriteDumpがこの順で検討すべきクラッシュダンプの収集手段であり、ダンプの種類の選択、保存先ACLの確認、PDBを伴うWinDbgでの解析までが一続きの流れであることを示す図
    wer_localdumps["WER LocalDumps"]
    procdump["ProcDump"]
    windbg["WinDbg"]
    minidumpwritedump["MiniDumpWriteDump"]
    crash_dump["クラッシュダンプ"]
    minidump["ミニダンプ"]
    fulldump["フルダンプ"]
    miniplus_dump["MiniPlusダンプ"]
    native_boundary_crash_investigation["ネイティブ境界の原因調査"]
    dump_folder_acl["ダンプ保存先フォルダのACL"]
    first_chance_exception["first chance exception"]
    second_chance_exception["second chance exception"]
    hang_detection["ハング検出"]
    postmortem_debugger["Postmortem debugger"]
    pdb["PDB(プログラムデータベース)"]
    custom_diagnostic_report["独自の診断情報保存機能"]
    notmyfault["NotMyFault"]
    wer_localdumps -->|"より先に行うべき"| procdump
    procdump -->|"より先に行うべき"| minidumpwritedump
    wer_localdumps -->|"実装を担う"| crash_dump
    procdump -->|"実装を担う"| crash_dump
    wer_localdumps -.->|"利用する"| minidump
    wer_localdumps -.->|"利用する"| fulldump
    procdump -.->|"利用する"| fulldump
    procdump -.->|"利用する"| miniplus_dump
    fulldump -->|"推奨される対応"| native_boundary_crash_investigation
    minidump -->|"用いるのは非推奨"| native_boundary_crash_investigation
    wer_localdumps -.->|"前提とする"| dump_folder_acl
    procdump -.->|"利用する"| first_chance_exception
    procdump -.->|"利用する"| second_chance_exception
    procdump -.->|"利用する"| hang_detection
    wer_localdumps -->|"用いるのは非推奨"| hang_detection
    procdump -.->|"実装を担う"| postmortem_debugger
    wer_localdumps -->|"より先に行うべき"| postmortem_debugger
    crash_dump -.->|"前提とする"| pdb
    crash_dump -->|"で確認できる"| windbg
    minidumpwritedump -->|"推奨される対応"| custom_diagnostic_report
    notmyfault -->|"用いるのは非推奨"| wer_localdumps

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全21件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. クラッシュダンプで何が分かるか

クラッシュダンプは、「その瞬間のスナップショット」です。防犯カメラというより、事故現場の静止画に近いです。

そのため、こういう情報はかなり取りやすいです。

• どの例外コードで落ちたか
• どのスレッドが落ちたか
• その時点のコールスタック
• 読み込まれていたモジュール
• どの程度のメモリを含めたかに応じて、ヒープ上の状態やオブジェクトの中身

一方で、ダンプだけでは不足しやすいものもあります。

• そこへ至るまでの時系列
• 数時間前からの増加傾向
• 通信や装置との外部状態
• 直前の入力や業務文脈

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

flowchart TB
    accTitle: ダンプとログの組み合わせ
    accDescr: クラッシュダンプは事故現場の静止画のようにその瞬間の状態に強く、そこへ至る時系列や外部状態はログやheartbeatが補うため、両方を組み合わせて使うのが基本であることを示す図。
    d1["クラッシュダンプ〔瞬間の静止画〕"] --> mix["組み合わせて調査する"]
    d2["ログやheartbeat〔時系列〕"] --> mix
    d1 -.-> s1["例外コードやスタックに強い"]
    d2 -.-> s2["至るまでの経過に強い"]

図2: 静止画のダンプと時系列のログは、得意分野がきれいに分かれる。

3. 収集方法の全体像

Windows アプリのダンプ収集で、入門段階で押さえたい方法は次の 4 つです。

初心者にとって一番大事なのは、「何で取るか」より先に、「どの条件で」「どこへ」「どのサイズで」取るかを決めることです。

flowchart TB
    accTitle: 道具より先に決めること
    accDescr: クラッシュダンプ収集では、どの条件で、どこへ、どのサイズで取るかを先に決めてから、何で取るかという道具の選択に進むのが大事であることを示す図。
    c1["どの条件で取るか"] --> firstq["先に決める3点"]
    c2["どこへ出すか"] --> firstq
    c3["どのサイズで取るか"] --> firstq
    firstq --> tool["それから道具を選ぶ"]

図3: 条件、出力先、サイズを決めてからなら、道具選びは迷わない。

4. 最初のおすすめは WER LocalDumps

4.1 まず見るレジストリ値

Windows Error Reporting (WER) には、クラッシュ後にローカルへユーザーモードダンプを保存する LocalDumps があります。追加ツールを配らなくてよいので、まずの一手としてかなり扱いやすいです。

基本のキーはここです。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

ここにグローバル設定を置くこともできますが、実務では アプリ単位のサブキーに寄せる方が扱いやすいです。

flowchart TB
    accTitle: LocalDumpsの設定の置き場所
    accDescr: LocalDumpsキーの直下にグローバル設定を置くこともできるが、実務ではMyApp.exeのようなアプリ単位のサブキーに寄せる方が扱いやすいことを示す図。
    key1["LocalDumpsキー"] --> g1["直下のグローバル設定"]
    key1 --> a1["アプリ単位のサブキー"]
    a1 -.-> a2["実務ではこちらが扱いやすい"]

図4: 同じキーでも、アプリ名のサブキーに寄せると影響範囲を絞れる。

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

最初に見る値は 3 つです。

4.2 アプリ単位で設定する例

たとえば MyApp.exe について、C:\CrashDumps\MyApp にフルダンプを最大 10 個残したいなら、まずは次のように設定できます。

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

この例のポイントは 4 つあります。

• グローバルではなく MyApp.exe に限定している
• 出力先を専用フォルダに分離している
• まずはフルダンプにしている
• 保持数を 10 に制限している

4.3 取れたか確認する

設定を入れたら、本番で自然発生を待つ前に 検証環境で必ず 1 回は取り切る方が安全です。

確認したいのはこの 4 点です。

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

flowchart TB
    accTitle: 設定後の検証の流れ
    accDescr: 設定を入れたら本番で自然発生を待つ前に検証環境で必ず1回取り切り、フォルダにダンプが出るか、サイズが想定に合うか、WinDbgで開けるか、Event Viewerでcrashが見えるかを確認する流れを示す図。
    v1["設定を入れる"] --> v2["検証環境でわざと落とす"]
    v2 --> v3["ダンプの有無とサイズを確認"]
    v3 --> v4["WinDbgで開けるか確認"]
    v4 --> v5["Event Viewerのログを確認"]

図5: 本番の自然発生を待つ前に、検証環境で1回取り切っておく。

4.4 わざと落とすための最小コード

「取り切る」と言われても、本物のクラッシュを待っていては検証になりません。検証用に、意図的に落ちるだけの小さな EXE を用意しておくと早いです。

.NET なら、未処理例外を投げるだけのコンソールアプリで十分です。.NET のマネージド未処理例外はプロセスを終了させるので、そのまま WER の対象になります。

// CrashTest.csproj: <TargetFramework>net8.0</TargetFramework>
using System;
using System.Threading;

internal static class Program
{
    private static void Main()
    {
        Console.WriteLine($"PID={Environment.ProcessId} / 3 秒後に落とします。");
        Thread.Sleep(3000);

        throw new InvalidOperationException("intentional crash for dump collection test");
    }
}

ネイティブ側の確認をしたいなら、アクセス違反 (0xC0000005) を起こす方が近いです。最適化で消えないように volatile を付けます。

// crash_test.cpp / C++17 / MSVC
int main()
{
    volatile int* p = nullptr;
    *p = 1;  // ここで STATUS_ACCESS_VIOLATION が発生します
    return 0;
}

ここで一つだけ、外しやすい点があります。 LocalDumps のサブキー名は、いま落とす EXE のファイル名と一致していないといけません。 MyApp.exe のキーだけ作って CrashTest.exe を落としても、当然ダンプは出ません。検証時は、CrashTest.exe のキーを一時的に作るか、グローバル設定側で試すかのどちらかにします。

flowchart TB
    accTitle: サブキー名の一致という罠
    accDescr: LocalDumpsのサブキー名はいま落とすEXEのファイル名と一致していないとダンプが出ないため、検証時はCrashTest.exeのキーを一時的に作るかグローバル設定側で試すことを示す図。
    t1["MyApp.exeのキーだけ作る"] --> t2["CrashTest.exeを落とす"]
    t2 --> t3["ダンプは出ない"]
    t3 -.-> t4["キー名は落とすEXE名と一致させる"]

図6: サブキー名とEXE名のずれは、検証が空振りする定番の罠。

Sysinternals の NotMyFault も「わざと落とす」ためのツールとしてよく挙がりますが、これは Windows システム自体を crash / hang させて ブルースクリーンのダンプを作るためのもので、管理者権限も必要です。ユーザーモードアプリの LocalDumps 検証には、上のような自前の小さな EXE のほうが安全で確実です。

5. ProcDump を使う場面

WER で十分なことは多いですが、ProcDump が便利な場面もあります。

• レジストリ常設を避けたい
• 既に起動中のプロセスだけ監視したい
• 次回起動からだけ監視したい
• first chance exception を見たい
• hang を取りたい
• パフォーマンスカウンタや条件付きで採りたい

5.1 よく使うオプション

入門段階でよく使うものだけに絞ると、ProcDump は次を覚えておけばかなり戦えます。

5.2 代表的なコマンド例

既に起動中のプロセスを、未処理例外でフルダンプ

procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

次回起動を待って、未処理例外でフルダンプ

procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

自分で起動して、そのまま監視

procdump -accepteula -ma -e -x C:\CrashDumps\MyApp MyApp.exe

first chance exception も取りたい

procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

ハングを取りたい

procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

5.3 -i を最初の一手にしない理由

ProcDump には -i で postmortem debugger として登録する使い方もあります。これは強力ですが、マシン全体のクラッシュ時挙動に踏み込むので、入門段階の最初の一手には少し重いです。

なので、最初は WER のアプリ単位設定か、ProcDump の -w / -x / PID 指定から入るのが扱いやすいです。

flowchart TB
    accTitle: -iを最初の一手にしない理由
    accDescr: ProcDumpの-iはpostmortem debuggerとして登録する強力な使い方だが、マシン全体のクラッシュ時挙動に踏み込むため、入門段階はWERのアプリ単位設定かProcDumpの-wや-xやPID指定から入るのが扱いやすいことを示す図。
    i1["ProcDumpの-iで登録"] --> i2["マシン全体の挙動に踏み込む"]
    i2 -.-> i3["入門の最初の一手には重い"]
    i4["最初はアプリ単位の設定"] --> i5["WERのアプリ単位設定"]
    i4 --> i6["ProcDumpの-wや-xやPID指定"]

図7: 影響範囲がアプリ単位で収まる入り口から始める。

6. 自前収集で MiniDumpWriteDump を使うときの考え方

自前収集が向いているのは、たとえばこんな場面です。

• UI から「診断情報を保存」ボタンを出したい
• ダンプと一緒にログ、設定、トレース ID を束ねたい
• 関連する子プロセスや補助プロセスもまとめたい
• アップロード前に独自のマスキングや圧縮を入れたい

ここで中心になる API が MiniDumpWriteDump です。

ただし、ここは少し癖があります。入門で特に外したくないのは次の 2 点です。

1. 可能なら dump 対象とは別プロセスから呼ぶ
2. DbgHelp 系は single-threaded 前提で扱う

flowchart TB
    accTitle: 自前収集で外したくない2点
    accDescr: MiniDumpWriteDumpによる自前収集では、可能ならdump対象とは別プロセスから呼ぶことと、DbgHelp系をsingle-threaded前提で扱うことの2点を外さないようにすることを示す図。
    md1["MiniDumpWriteDumpで自前収集"] --> md2["別プロセスから呼ぶ"]
    md1 --> md3["DbgHelpはsingle-threaded前提"]
    md2 -.-> md4["雑に実装すると逆に壊れる"]
    md3 -.-> md4

図8: 自前収集の癖は、呼ぶ場所とスレッドの2点に集約される。

7. ミニダンプ / フルダンプ / 中間サイズの選び方

ここで迷う人はかなり多いです。実務での選び方を表にしておきます。

初心者向けのおすすめはかなり単純です。

• 開発機 / 検証機ではフルダンプ
• 顧客環境ではミニかフルを運用条件で選ぶ
• メモリ破壊、ネイティブ DLL、COM、P/Invoke、長時間稼働後の状態異常が怪しいならフル寄り

flowchart TB
    accTitle: ダンプ種類のまずの選び方
    accDescr: 開発機や検証機ではフルダンプ、顧客環境では運用条件でミニかフルを選び、メモリ破壊やネイティブ境界、長時間稼働後の状態異常が怪しいならフル寄りにするという選び方を示す図。
    e1{"どの環境で取るか"}
    e1 -->|"開発機 / 検証機"| f1["フルダンプ"]
    e1 -->|"顧客環境"| f2["運用条件でミニかフル"]
    f2 -.->|"破壊臭やネイティブ境界"| f1

図9: 迷ったら環境で決め、怪しさが濃いほどフル側へ寄せる。

7.1 MiniPlus / Custom は、実際にはどう指定するのか

表の 3 行目だけ、指定方法が少し分かりにくいので補足します。

WER LocalDumps の場合は、DumpType を 0（カスタム）にしたうえで、CustomDumpFlags に MINIDUMP_TYPE のビット組み合わせを入れます。CustomDumpFlags は DumpType=0 のときだけ使われる値で、既定は 0x00000121（MiniDumpWithDataSegs MiniDumpWithUnloadedModules MiniDumpWithProcessThreadData の組み合わせ）です。

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v CustomDumpFlags /t REG_DWORD /d 0x121 /f

ProcDump の場合は、-mp が MiniPlus、-mc <Mask> がカスタムです。

procdump -accepteula -mp -e MyApp.exe C:\CrashDumps\MyApp

MiniPlus は、名前のわりに中身がかなりフル寄りです。ドキュメントによると、private メモリ全部と、read/write な image / mapped メモリ全部を含み、そのうえで 512MB を超える最大の private 領域だけを除外してサイズを抑えます。結果として「フルダンプ並みに詳しいが、サイズはフルの 10%〜75%」という位置付けになります。

ただし注意点が 2 つあります。

• CLR プロセスはデバッグ上の制約から、-mp を指定してもフル (-ma) として採取されます。 .NET アプリで MiniPlus のサイズ削減を当て込むのは、たいてい外れます
• サイズを詰めたい動機が「機密情報の混入を減らしたい」なのであれば、MiniPlus ではなくミニダンプ側で考えるほうが素直です

flowchart TB
    accTitle: MiniPlusの位置付けと制約
    accDescr: MiniPlusはprivateメモリ全部とread/writeなimageやmappedメモリを含み、512MBを超える最大のprivate領域だけを除外してフルの1割から7割強のサイズに収まるが、CLRプロセスでは-mpを指定してもフルとして採取されることを示す図。
    mp1["MiniPlusで採取"] --> mp2["privateメモリはほぼ全部含む"]
    mp2 --> mp3["巨大なprivate領域だけ除外"]
    mp3 --> mp4["フルより小さく詳しい"]
    mp1 -.->|"CLRプロセスの場合"| mp5["フルとして採取される"]

図10: MiniPlusは中身がフル寄りで、.NETアプリではサイズ削減が効かない。

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

ダンプ収集は、実装より運用で転ぶことがかなりあります。先に決めておきたいことを挙げます。

8.1 PDB とバイナリをどう残すか

これが最重要です。

• 配布した EXE / DLL の正確な版
• その版に対応する PDB
• どのコミット / どのビルドパイプラインで作ったか
• インストーラや配布物の版情報

8.2 どこへ出して、何個残すか

フルダンプはかなり大きくなります。出力先と保持の方針は最初から決めておく方が安全です。

• システムドライブ直下に置きっぱなしにしない
• 専用フォルダへ分離する
• DumpCount や -n で上限を切る
• 長期保管と一次保管を分ける

8.3 誰が見てよいか

フルダンプには、機密情報や個人情報が混ざる可能性があります。

• 平文設定
• 接続文字列
• トークンや資格情報
• 直前に扱っていた業務データ
• ファイルパスやユーザー名

なので、「取る」設計と同時に「誰が触れてよいか」も決める必要があります。

flowchart TB
    accTitle: 運用で先に決める3点
    accDescr: クラッシュダンプ収集は実装より運用で転びやすいため、PDBとバイナリの保管、出力先と保持数、誰が見てよいかというアクセス方針を先に決めておくことを示す図。
    op1["PDBとバイナリの保管"] --> op4["先に決めておく"]
    op2["出力先と保持数"] --> op4
    op3["誰が見てよいか"] --> op4
    op4 -.-> op5["実装より運用で転びやすい"]

図11: ダンプ収集の失敗は、たいてい運用の決めごとの不足から来る。

9. 取れた後の最短解析導線

ダンプを取ったあと、最初にやることは意外と素朴です。

9.1 WinDbg を入れる

今の WinDbg は Microsoft Store か winget で入れやすくなっています。

winget install Microsoft.WinDbg

9.2 ダンプを開く

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

ここのファイル名は、ProcDump が付ける既定の名前です。ProcDump の既定ファイル名は PROCESSNAME_YYMMDD_HHMMSS.dmp で、PROCESSNAME / PID / EXCEPTIONCODE / YYMMDD / HHMMSS を置換指定子として使えます。

一方、WER LocalDumps は ProcDump とは別の命名でファイルを作ります。命名規則は Microsoft Learn に明記されていないので、名前を推測して探すより、出力先フォルダを更新日時順に見るほうが確実です。

dir /o-d "C:\CrashDumps\MyApp\*.dmp"

DumpFolder を設定していない場合、既定の出力先は %LOCALAPPDATA%\CrashDumps です。ただし サービスのクラッシュは実行アカウントごとのプロファイルフォルダへ出ます。System サービスなら %WINDIR%\System32\Config\SystemProfile、Network Service / Local Service なら %WINDIR%\ServiceProfiles 配下です。「ダンプが出ていない」と思ったら、まずここを疑います。

flowchart TB
    accTitle: ダンプが見当たらないときの探し場所
    accDescr: DumpFolderを設定していない場合の既定はLOCALAPPDATA配下のCrashDumpsで、サービスのクラッシュは実行アカウントごとのプロファイルフォルダへ出るため、出ていないと思ったらそこを疑うことを示す図。
    fq1["ダンプが見当たらない"] --> fq2{"どの形で動いていたか"}
    fq2 -->|"通常アプリ"| fp1["LOCALAPPDATA配下のCrashDumps"]
    fq2 -->|"サービス"| fp2["実行アカウントのプロファイル配下"]
    fp2 -.-> fp3["SystemProfileやServiceProfiles"]

図12: 既定の出力先はアカウントごとに違うので、探す場所から疑う。

9.3 シンボルを設定する

まず Microsoft 公開シンボルを使える状態にして、その後で自分の PDB の場所を足します。

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

9.4 まずは自動解析を見る

!analyze -v

そのうえで、

• どの例外コードか
• faulting module は何か
• 自分のコードがどこまでスタックに見えているか
• 例外スレッド以外に怪しい待ちや詰まりがないか

を順に見ます。

flowchart TB
    accTitle: 取れた後の最短解析導線
    accDescr: WinDbgを入れ、ダンプを開き、Microsoft公開シンボルと自分のPDBを設定し、まずanalyze -vの自動解析を見てから、例外コードやfaulting module、自分のコードの見え方、他スレッドの詰まりを順に確認する流れを示す図。
    an1["WinDbgを入れる"] --> an2["ダンプを開く"]
    an2 --> an3["シンボルとPDBを設定"]
    an3 --> an4["まず自動解析を見る"]
    an4 --> an5["例外コードとスタックを順に読む"]

図13: 開いて、シンボルを通して、自動解析から読み始めるのが最短。

10. よくあるはまりどころ

10.1 ダンプは取れたが、PDB がない

これはかなり多いです。ダンプ収集は成功していても、読む材料が不足します。 収集設定と同じタイミングで、PDB の保管設計も入れる方がよいです。

10.2 DumpFolder の ACL を見ていない

サービスや権限分離されたプロセスでは、ここで空振りしやすいです。 「そのプロセスが本当に書けるか」を先に確認します。Microsoft Learn も、既定以外のパスを使うなら「クラッシュしたプロセスが書き込める ACL になっていること」を確認するように書いています。

今の ACL は icacls で見られます。

icacls C:\CrashDumps\MyApp

書き込み権が足りなければ、実行アカウントに M（変更）を足します。ダンプフォルダは配下のファイルにも同じ権限が要るので、(OI) と (CI) を付けて継承させます。

rem 例: Network Service で動くサービスの場合
icacls C:\CrashDumps\MyApp /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)M"

(OI) は配下のファイルへ、(CI) は配下のフォルダへ ACE を継承させる指定です。継承の範囲がそのまま「誰がダンプを読めるか」になるので、8.3 で決めた方針と食い違っていないか、付ける前に一度確認してください。

flowchart TB
    accTitle: DumpFolderのACL確認の流れ
    accDescr: サービスや権限分離されたプロセスでは書き込みで空振りしやすいため、icaclsで今のACLを確認し、足りなければ実行アカウントに継承付きの変更権を付与し、その継承範囲を閲覧方針と突き合わせる流れを示す図。
    ac1["icaclsで今のACLを見る"] --> ac2{"実行アカウントは書けるか"}
    ac2 -->|"書けない"| ac3["継承付きで変更権を付与"]
    ac2 -->|"書ける"| ac4["そのまま運用"]
    ac3 -.-> ac5["継承範囲は閲覧方針と突き合わせる"]

図14: 書けるかの確認と、誰が読めるかの確認は同じ場所で済ませる。

10.3 フルダンプを本番機のシステムドライブへ出し続ける

これは容量事故の定番です。 保持数制限と出力先分離は最初から入れます。

10.4 WER だけで hang も全部見ようとする

WER LocalDumps はまず crash に強いです。 hang や first chance exception は ProcDump の方が向いている場面があります。

10.5 -e 1 を常時入れて、例外の嵐になる

first chance exception は便利ですが、ふつうに多いです。 件数制限を付ける、短時間だけ入れる、対象を限定するのが現実的です。

11. まとめ

クラッシュダンプは、再現率の低い障害に対してかなり強い観測点です。特に Windows アプリで COM、P/Invoke、native DLL、長時間運転が絡むなら、最初から「落ちたら何が残るか」を決めておく価値があります。

おすすめの順番はシンプルです。

1. まず WER LocalDumps をアプリ単位で入れる
2. 必要なら ProcDump を足す
3. さらに制御したくなったら、別プロセス前提で MiniDumpWriteDump を使う

この順で進めると、大きく外しにくいです。

12. 参考資料

• ユーザーモード ダンプの収集 - 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 | Microsoft Learn
• MINIDUMP_TYPE enumeration (minidumpapiset.h) - Win32 | Microsoft Learn
• icacls - Windows commands | Microsoft Learn
• NotMyFault - Sysinternals | Microsoft Learn

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

クラッシュダンプとは何ですか？何が分かりますか？

クラッシュした瞬間のプロセス状態をファイルに保存したもので、事故現場の静止画のようなスナップショットです。例外コード、落ちたスレッドとそのコールスタック、読み込まれていたモジュール、含めたメモリ量に応じてヒープ上のオブジェクトの中身まで後から確認できます。一方で、そこへ至るまでの時系列や通信・装置との外部状態は不足しやすいため、実務ではログや heartbeat と組み合わせて使うのが基本です。

WER の LocalDumps はどこで設定しますか？

レジストリの HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps 配下で設定します。実務ではグローバル設定ではなく、MyApp.exe のようなアプリ単位のサブキーに寄せる方が扱いやすいです。最初に見る値は出力先の DumpFolder、保持数の DumpCount、種類の DumpType の3つで、追加ツールを配布せずにクラッシュ後のダンプをローカルへ残せます。

ミニダンプとフルダンプはどちらを選ぶべきですか？

開発機・検証機ではフルダンプ（DumpType=2）、顧客環境では容量と機密要件を見てミニダンプ（DumpType=1）かフルダンプを選ぶのが目安です。メモリ破壊、ネイティブ DLL、COM、P/Invoke、長時間稼働後の状態異常が怪しい場合はフル寄りが有利です。ただしフルダンプはサイズが大きく、接続文字列やトークンなどの機密情報が混入するリスクもあるため、保管場所・保持数・アクセス権を先に決めておく必要があります。

ProcDump はどんなときに使いますか？

WER LocalDumps は基本的にクラッシュ向けなので、hang や first chance exception まで見たい場合、レジストリへの常設を避けたい場合、既に起動中のプロセスだけを監視したい場合に ProcDump が向いています。代表的なオプションは、フルダンプの -ma、未処理例外での採取 -e、ハング検出の -h、起動待ちの -w などです。first chance exception を対象にする -e 1 は件数が多くなりやすいため、-n で上限を付けるなど短時間・限定的に使うのが現実的です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。