WinDbgでゲームのクラッシュダンプを開く手順｜例外コードとスタックの読み方、原因を断定できないケースの見分け方【2026年】

最終確認日：2026年10月25日。Microsoft公式ドキュメントを基準に、Windows 11（ビルド26100）でWERのLocalDumpsにより採取したテスト用プロセスのダンプを、Debugging Tools for Windows 10.0.26100.7705のcdbで開いた出力を載せています。WinDbgと同じデバッグエンジンのコンソール版で、コマンドと出力の形は共通です。参照した資料：ユーザーモードダンプの収集（LocalDumps）、ユーザーモードダンプファイル、ユーザーモードダンプの解析、.ecxr、!analyze、Microsoft公開シンボルサーバー、WinDbgのインストール、EXCEPTION_RECORD、NTSTATUS値の一覧。

ゲームが落ちたあとに「.dmp」ファイルが残っていても、開いて何を読めばよいのかが分かりにくいものです。WinDbgに出てくる「kernel32」「ntdll」といったモジュール名が、そのまま犯人に見えてしまうこともあります。

読む順番は決まっています。シンボルを設定してダンプを開き、.ecxrで例外が起きた場所へ移り、kでスタック、!analyze -vで要約を見ます。取り出せるのは「例外コード」「落ちた場所」「そこに至る呼び出しの流れ」の3つです。

ただし、この3つが示すのはクラッシュが検出された地点で、原因そのものではありません。ゲーム本体のシンボルがなければ関数名までは分からず、ミニダンプではメモリの中身も読めません。解析結果でGPUや特定の部品を故障と決めつけず、再現条件の記録とサポートへの報告材料として使うのが現実的です。

種類開くダンプの種類と、採取済みであることの確認

ゲームなど1つのプロセスだけが異常終了したときに作られるのが、ユーザーモードダンプです。ゲームが落ちたのに信頼性履歴にLiveKernelEventが並ぶ場合や、ブルースクリーンが出た場合は、別種類のダンプが対象になります。

ユーザーモードダンプの採取は、WERのLocalDumpsが標準的な方法です。Microsoftの資料では、この機能は既定では無効で、有効にするには管理者権限が必要です。保存先の既定は%LOCALAPPDATA%\CrashDumps、保持数は10件、種類は既定でミニダンプです。設定の手順はゲームが落ちるのにイベントビューアーに何も出ないときの記事にまとめています。ダンプのファイル名は実行ファイル名.プロセスID.dmpの形になります。

以降の出力は、手元で意図的にクラッシュさせたテスト用プロセス（開始アドレス0のスレッドを作る小さなスクリプト）のダンプです。ゲームのダンプではないため、ゲーム固有のモジュールは出てきません。

準備WinDbgとシンボルを用意する

WinDbgはMicrosoft Store版のほか、Windows Package Managerでも入れられます。

winget install Microsoft.WinDbg

ダンプを開く前に、シンボルの場所を設定します。シンボルは、アドレスを関数名に置き換えるための対応表です。Microsoftの公開シンボルサーバーを使うなら、.symfixコマンドでローカルのキャッシュフォルダーを指定します。

.symfix C:\Symbols
.reload

これで取得できるのは、ntdll・kernel32・KERNELBASEなどWindows自身のシンボルです。ゲーム本体やゲーム付属のDLLのシンボルは、公開サーバーにはありません。Microsoftの手順でも、商用ソフトのシンボルは提供元に問い合わせるものとされています。シンボルがないモジュールは、関数名ではなく「モジュール名＋オフセット」で表示されます。

手順ダンプを開いて、最初の画面を読む

ダンプはコマンドラインの-zオプションで開きます。WinDbgを起動済みなら.opendumpで追加し、gを実行して読み込みます。

cdb -z C:\CrashDumps\game.exe.12345.dmp -y "srv*C:\Symbols*https://msdl.microsoft.com/download/symbols"

テスト用プロセスのミニダンプを開くと、最初に次のように表示されました（一部を省略）。

User Mini Dump File: Only registers, stack and portions of memory are available
...
Process Uptime: 0 days 0:00:03.000
...
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(c908.104b4): Access violation - code c0000005 (first/second chance not available)
...
For analysis of this file, run !analyze -v
ntdll!NtWaitForMultipleObjects+0x14:
00007fff`2e5a28a4 c3              ret
0:004>

例外が起きた場所へ移るには、次の節の.ecxrを使います。.ecxrは、現在の例外に紐づくコンテキストレコードをレジスタの状態として使うコマンドで、クラッシュダンプ専用です。

例外.ecxrとkで、落ちた場所と呼び出しの流れを見る

次の3つを順に実行します。

.exr -1
.ecxr
k

.exr -1が例外の記録、.ecxrが例外発生時の状態への切り替え、kがスタックの表示です。今回のダンプでは次のようになりました。

ExceptionAddress: 0000000000000000
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000008
   Parameter[1]: 0000000000000000
Attempt to execute non-executable address 0000000000000000
...
Child-SP          RetAddr               Call Site
00000021`79dafda8 00007fff`2d78dda7     0x0
00000021`79dafdb0 00007fff`2e4bee4c     kernel32!BaseThreadInitThunk+0x17
00000021`79dafde0 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

例外コードとパラメーターの読み方

ExceptionCodeがc0000005（アクセス違反）のとき、Parameter[0]は操作の種類で、0が読み込み、1が書き込み、8がデータ実行防止に反する実行です。Parameter[1]は触ろうとしたアドレスです。この例は「アドレス0を実行しようとした」と読めます。

名前と意味はMicrosoftのNTSTATUS値の一覧と、EXCEPTION_RECORD構造体の資料に基づきます。コードの意味が分かっても、そのコードを引き起こした側までは分かりません。

スタックは下から上へ読む

kの出力は、上が最も新しい呼び出し、下が最も古い呼び出しです。この例では、下のntdll!RtlUserThreadStartが、どのスレッドも最初に通る入口です。次のkernel32!BaseThreadInitThunkを経て、最後にアドレス0を実行して例外になっています。

解析!analyze -vの出力で見る項目

!analyze -vは、現在の例外を自動で調べて要約するコマンドです。このダンプの出力から、読む価値のある部分を抜き出します。

FAILURE_BUCKET_ID:  SOFTWARE_NX_FAULT_c0000005_kernel32.dll!BaseThreadInitThunk
SYMBOL_NAME:  kernel32!BaseThreadInitThunk+17
MODULE_NAME: kernel32
IMAGE_NAME:  kernel32.dll
STACK_COMMAND:  ~4s; .ecxr ; kb

STACK_COMMANDを見ると、!analyzeが内部で行っているのは、先ほど手で実行した.ecxrとスタック表示だと分かります。

ゲームが固まって反応しなくなった場合は、例外が記録されません。その場合は!analyze -v -hangで、スレッド同士がどう待ち合っているかを調べます。Microsoftの資料では、実行前に、止まっていると考えるスレッドへ切り替えておくよう案内されています。固まったゲームのダンプは、Windows 11のタスクマネージャーで該当プロセスを右クリックして「ライブメモリダンプ ファイルの作成」から取れます。

シンボルシンボルがないと、関数名は当てにならない

モジュール一覧はlmで確認できます。右側の表示が、そのモジュールにどこまでシンボルが読み込めたかを示します。

00007ff7`8a540000 00007ff7`8a55a000   python     (no symbols)
00007ffe`c2b10000 00007ffe`c31bb000   python312  (export symbols)  python312.dll
00007fff`2b900000 00007fff`2bd01000   KERNELBASE (pdb symbols)     ...\kernelbase.pdb

export symbolsの場合に何が起きるかは、このダンプのスレッド0のスタックで確認できます。

00000021`795eec50 00007fff`2b922641     KERNELBASE!WaitForMultipleObjectsEx+0x123
00000021`795eef80 00007ffe`c2c9f38f     python312!PyThread_GetInfo+0x42b
00000021`795eefe0 00007ffe`c2c9f23d     python312!PyThread_GetInfo+0x2d9

python312の2行は、同じ関数名にオフセットだけが違う値で並んでいます。公開名しかないと、直前にある公開関数の名前を基準に表示するためで、実際にその関数が動いていたとは限りません。ゲームのDLLで関数名のように見える表示が出ても、シンボルがなければ参考程度に扱います。

報告に使う情報として、モジュールのバージョンはlmvm モジュール名で取れます。kernel32なら、ファイルバージョンが10.0.26100.9711と表示されました。

限界解析結果から原因を断定できないケース

Windowsのイベント側の記録と照らし合わせるなら、Faulting Moduleと例外コードから原因記事を引けるイベントID 1000の診断チャートが使えます。ダンプで得た例外コードとモジュール名を、その表に当てはめます。

個人情報ダンプに入っている情報と、渡す前の処理

ダンプは、クラッシュした時点のプロセスの状態を保存したファイルです。フルダンプはプロセスのメモリ全体を含みます。ミニダンプでも、今回のテスト用プロセスでは、!pebでコマンドライン、カレントフォルダー、環境変数がすべて読めました。環境変数には、ユーザー名、コンピューター名、アプリが使うトークンなどが入っていることがあります。

開いたダンプのコピーを作り直す方法があります。.dumpに/mrRを付けると、スタックの再構築に使わない部分を消し、モジュールのフルパスも除いた新しいダンプを書き出せます。Microsoftの資料では、rオプションが他のアプリの情報の保護、Rオプションがユーザーのフォルダー構成の保護を目的とするものと説明されています。

.dump /mrR C:\CrashDumps\game_reduced.dmp

この表はテスト用プロセスの結果です。ゲームのダンプで同じ減り方になるとは限りません。処理後のダンプを開いて、サポートに見せたい情報が残っているかを確認してから使います。元のダンプは消さずに保管しておきます。

連絡サポートに渡す情報と、渡し方

ダンプ本体は、サポート窓口から求められたときに、公式の連絡経路で渡すのが基本です。掲示板やSNSに貼ると、前の節の情報がそのまま公開されます。求められていない段階では、次の情報をテキストで伝えれば足ります。

出力をそのまま貼るときは、Loading Dump Fileの行を消します。ダンプの保存先に、Windowsのユーザー名が含まれるためです。

FAQよくある質問

まとめまとめ｜ダンプで分かるのは、落ちた場所まで

ユーザーモードダンプは、シンボルを設定して開き、.ecxr、k、!analyze -vの順に見れば、例外コード・落ちた場所・呼び出しの流れを取り出せます。ただし、モジュール名はあくまで調べ始める位置です。Windowsの共通部品やドライバーが出ても、それだけでは原因を決められません。ダンプが複数残っていれば同じ場所で落ちているかを比べ、ダンプ本体は個人情報を含むため、公式の窓口に求められたときだけ渡します。

あわせて読みたい

トラブル・設定

ゲームが落ちるのにイベントビューアーに何も出ない原因

トラブル・設定

イベントID 1000でゲームが落ちる原因を探す診断チャート

トラブル・設定

LiveKernelEvent 141・117とは

トラブル・設定

Memtest86+の使い方