知識マップ: WinDbg + SOSでクラッシュダンプを読む ── 収集した後の実務解析入門

記事「WinDbg + SOSでクラッシュダンプを読む ── 収集した後の実務解析入門」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事はクラッシュダンプをWinDbgで解析する手順を扱い、WinDbgはSOS拡張を読み込むことで初めて.NETのマネージドヒープや例外情報を読めるようになります。未処理例外の調査は!clrstackでスタックを、!peで例外オブジェクトを確認する流れになり、メモリが増え続ける調査は!dumpheap -statでヒープの統計を取ってから!gcrootで参照元をたどります。ネイティブクラッシュには!analyze -vによる自動解析を用い、PDBが無くても多くのコマンドは機能しますがソースファイル名・行番号だけは失われます。純粋なマネージドコードの調査なら、WinDbgより軽量なdotnet-dump analyzeも選択肢になりますが、ネイティブスタックフレームは扱えません。

flowchart LR
    accTitle: WinDbg+SOSによるクラッシュダンプ解析の知識マップ
    accDescr: クラッシュダンプをWinDbgとSOS拡張で読み解く際に、対象が未処理例外かマネージドメモリリークかネイティブクラッシュかに応じてどのコマンドを使うか、シンボル(PDB)の有無で何が変わるか、dotnet-dumpとの使い分けを示した図。
    crash_dump["クラッシュダンプ"]
    windbg["WinDbg"]
    sos_extension["SOS拡張"]
    pdb["PDB(プログラムデータベース)"]
    unhandled_exception["未処理例外"]
    clrstack_command["!clrstack(CLRStackコマンド)"]
    printexception_command["!pe(PrintExceptionコマンド)"]
    managed_memory_leak["マネージドメモリリーク"]
    dumpheap_command["dumpheap -statコマンド"]
    gcroot_command["gcrootコマンド"]
    managed_heap["マネージドヒープ"]
    native_crash["ネイティブクラッシュ"]
    analyze_v_command["!analyze -v"]
    dotnet_dump["dotnet-dump"]
    dotnet_framework[".NET Framework"]
    dotnet[".NET(Core以降)"]
    handle_leak["ハンドルリーク"]
    windbg -.->|"利用する"| sos_extension
    windbg -->|"利用する"| crash_dump
    windbg -.->|"前提とする"| pdb
    unhandled_exception -.->|"で確認できる"| clrstack_command
    unhandled_exception -.->|"で確認できる"| printexception_command
    managed_memory_leak -->|"で確認できる"| dumpheap_command
    managed_memory_leak -->|"で確認できる"| gcroot_command
    dumpheap_command -->|"利用する"| managed_heap
    gcroot_command -->|"利用する"| managed_heap
    native_crash -->|"で確認できる"| analyze_v_command
    dotnet_dump -->|"前提とする"| crash_dump
    dotnet_dump -->|"利用する"| sos_extension
    dotnet_dump -->|"用いるのは非推奨"| native_crash
    windbg -->|"推奨される対応"| native_crash
    dotnet_dump -->|"推奨される対応"| managed_memory_leak
    sos_extension -.->|"前提とする"| dotnet_framework
    sos_extension -.->|"前提とする"| dotnet
    handle_leak -.->|"で確認できる"| gcroot_command
    unhandled_exception -.->|"原因になり得る"| crash_dump

概念間の関係(全19件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

WinDbgはSOS拡張を利用します。.NETアプリのダンプでマネージドヒープの中身やC#のスタックフレームを見るには、WinDbg上でSOS拡張を読み込む必要がある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
WinDbgはクラッシュダンプを利用します。WinDbgは-zオプションまたはFileメニューからクラッシュダンプファイルを指定して開き、その中身を解析する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
WinDbgはPDB(プログラムデータベース)を前提とします。ソースファイル名・行番号やネイティブフレームの関数名まで見るには、_NT_SYMBOL_PATHにPDBの場所を通す必要があるが、多くのコマンドはPDBが無くても機能する / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
未処理例外は!clrstack(CLRStackコマンド)で確認できます。マネージドコードの未処理例外で落ちたダンプは、例外を持つスレッドに切り替えて!clrstackでマネージドスタックを表示することで、どの経路で落ちる場所まで来たかを確認できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
未処理例外は!pe(PrintExceptionコマンド)で確認できます。マネージドコードの未処理例外では、!pe(PrintException)で例外オブジェクトの型・メッセージ・内部例外を確認できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
マネージドメモリリークはdumpheap -statコマンドで確認できます。!dumpheap -statでマネージドヒープの型ごとの件数・合計サイズを確認し、量で殴っている型を特定する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
マネージドメモリリークはgcrootコマンドで確認できます。!dumpheapで特定した個別インスタンスについて!gcrootを実行し、GCで回収されずに残り続ける原因の参照元を洗い出す / 確度: 確立した関係 / 確認日: 2026-08-01 出典
dumpheap -statコマンドはマネージドヒープを利用します。!dumpheapはマネージドヒープを走査して型ごとの統計または個別インスタンスの一覧を表示する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
gcrootコマンドはマネージドヒープを利用します。!gcrootはマネージドヒープとハンドルテーブルの全体を検索して参照経路を洗い出す / 確度: 確立した関係 / 確認日: 2026-08-01 出典
ネイティブクラッシュは!analyze -vで確認できます。アクセス違反などのネイティブクラッシュは、まず!analyze -vの自動解析でFAULTING_IPやFOLLOWUP_IPなどの主要フィールドを確認するところから入る / 確度: 確立した関係 / 確認日: 2026-08-01 出典
dotnet-dumpはクラッシュダンプを前提とします。dotnet-dump analyzeはクラッシュダンプファイルを指定して対話セッションを開く / 確度: 確立した関係 / 確認日: 2026-08-01 出典
dotnet-dumpはSOS拡張を利用します。dotnet-dump analyzeはSOSが事前インストールされた対話セッションを開き、clrstackやdumpheapなどSOSのコマンド体系をそのまま使える / 確度: 確立した関係 / 確認日: 2026-08-01 出典
dotnet-dumpをネイティブクラッシュに用いることは推奨されません。dotnet-dumpはネイティブなデバッガーではないためネイティブのスタックフレームを扱えず!analyze -vも使えないので、ネイティブクラッシュの調査には向かない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
WinDbgはネイティブクラッシュに対する本記事の推奨です。COMやP/Invoke、ネイティブDLLが絡む可能性がある調査には、ネイティブスタックフレームと!analyze -vが使えるWinDbgが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
dotnet-dumpはマネージドメモリリークに対する本記事の推奨です。純粋なマネージドコードのメモリリーク調査で、CIや複数プラットフォームでも動かしたい場合は、導入が軽いdotnet-dump analyzeが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
SOS拡張は.NET Frameworkを前提とします。対象アプリが.NET Frameworkの場合、ランタイム本体clr.dllの近傍から.loadby sos clrでSOSを読み込む / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
SOS拡張は.NET(Core以降)を前提とします。対象アプリが.NET Core/.NET 5+の場合、ランタイム本体coreclr.dllの近傍から.loadby sos coreclrでSOSを読み込む / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
ハンドルリークはgcrootコマンドで確認できます。SafeHandleを持つマネージドラッパーが原因のハンドルリークでは、!dumpheap -statでマネージドヒープの増加がないと分かった後、そのラッパーが残っていれば!gcrootでGCルートを追い、OSハンドルの解放漏れ箇所を特定できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
未処理例外はクラッシュダンプの原因になることがあります。未処理例外はプロセスを終了させ、WER LocalDumpsやProcDumpの設定次第でその瞬間のクラッシュダンプが書き出される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

クラッシュダンプ: プロセスのメモリ内容・スタック情報・例外情報などをファイルへ書き出した、クラッシュ調査に使うスナップショットである。
WinDbg: クラッシュダンプやハングしたプロセスの状態をカーネル/ユーザーモードで解析するためのMicrosoft製デバッガー。SOS拡張によるマネージドヒープ解析や、Application Verifierの検出結果の解析にも使われる。
未処理例外: アプリケーションのどこでもキャッチされないままランタイムまで届き、プロセスを終了させる例外である。
マネージドメモリリーク: マネージドオブジェクトへの参照が解放されずに残り続け、マネージドヒープの使用量が増え続ける状態である。
dumpheap -statコマンド: ヒープ上の型ごとの件数(Count)とサイズ(Size)の統計を表示するSOSデバッガーコマンド。
gcrootコマンド: 指定したオブジェクトがどこから参照されているか、GCルートまでの参照経路を表示するSOSデバッガーコマンド。
ネイティブクラッシュ: C++のDLL、COM、ベンダーSDKなどが絡む、マネージド例外ではなくネイティブコード側で発生するクラッシュである。
dotnet-dump: プロセスのダンプ(ヒープダンプやクラッシュダンプ)を収集・解析する.NETの診断ツール。SOSコマンド(dumpheap・gcroot・clrstackなど)でヒープの参照元やスタックトレースを調べられるが、ネイティブのスタックフレームは扱えない。
SOS拡張: マネージドヒープの情報収集、ヒープ破損の検出、ランタイム内部データ型の表示など、CLRの内部をデバッガー上から読むためのデバッガー拡張である。
ハンドルリーク: 参照カウントやハンドルカウントの数え違いなどにより、不要になったハンドル(ファイル・イベント・スレッド・GDIオブジェクト・アクセストークンなどカーネルオブジェクトへの参照)が解放されずに積み上がっていく状態。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。