ゲームが落ちるのにイベントビューアーに何も出ない原因｜信頼性モニターとperfmon /relでの確認方法【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
ゲームが突然デスクトップへ戻ったのに、イベント ビューアーの「Windows ログ」だけを見ても該当時刻のエラーが見つからないことがあります。まず開くべきなのは、時系列で失敗を並べて確認できる信頼性モニターです。
この記事では、perfmon /relで信頼性モニターを開き、APPCRASH・LiveKernelEvent・例外コード・障害モジュールから次の確認先を決める手順を解説します。イベントが何も残らない場合のゲーム側ログとWindows Error Reporting（WER）ダンプも扱います。
出典：Microsoft「perfmon」、Microsoft「アプリケーションまたはサービスのクラッシュのトラブルシューティング」、Microsoft「Collecting User-Mode Dumps」。2026年8月22日時点の確認内容です。
目次
先に結論イベントがなくても、まず信頼性モニターでクラッシュの種類を分ける
同じ「ゲームが落ちた」でも、ゲームのアプリクラッシュ、GPUのタイムアウト、ゲーム側ログのエラーでは確認先が異なります。信頼性モニターの該当時刻から確認すれば、不要な再インストールを減らせます。
| 信頼性モニターの表示 | まず読む場所 | 次に行うこと |
|---|---|---|
| APPCRASH／Application Error | アプリ名、障害モジュール名、例外コード | ゲームファイル・ランタイム・MOD・オーバーレイを確認する |
| LiveKernelEvent 141／画面の暗転・停止 | GPU負荷、温度、電源、ドライバー、GPU安定性 | GPU系として扱い、ゲーム設定・補助電源・OCを確認する |
| 失敗があるが詳細が薄い | ゲームのCrash／Logs、ランチャー、同時刻のWindowsログ | ゲーム固有のログを保存し、再現条件を一つずつ固定する |
| 何も記録されない | フリーズ・強制終了・電源断の有無、WER LocalDumps | OSが終了処理を完了できたかを切り分け、必要ならダンプ採取を検討する |
起動確認信頼性モニターを開いて、落ちた時刻を特定する
Windows＋Rを押し、perfmon /relと入力して実行します。Microsoftのコマンドリファレンスでも、/relは信頼性モニターを開始するオプションとして案内されています。
- 1ゲームが落ちた日を選ぶ
赤い×、黄色い警告、青い情報のうち、ゲームが終了した時刻に近い項目を開きます。
- 2「技術的な詳細を表示」を開く
アプリ名、障害モジュール名、例外コード、問題イベント名を控えます。スクリーンショットも残しておくと比較しやすくなります。
- 3同じ時刻のイベント ビューアーを確認する
信頼性モニターの時刻を基準にすると、Application ErrorやDisplay関連のログを探しやすくなります。
アプリ側APPCRASHなら、障害モジュールと例外コードを原因名と決めつけない
Microsoftは、イベント ID 1000の障害モジュールにntdll.dll、kernel32.dll、kernelbase.dllなどが表示される場合、アプリが異常を検出したタイミングや別の要因で壊れた状態を表していることがあると説明しています。表示されたDLLだけを削除・置換するのは避けてください。
| 表示された値 | 実用上の見方 | 優先する確認 |
|---|---|---|
| APPCRASH／Event ID 1000 | ゲームのプロセスが例外で終了した記録。障害モジュールは手掛かりであり、単独では原因の断定材料にならない | ゲームファイルの整合性、MOD・オーバーレイの停止、同じゲームだけで起きるか |
0xc0000005 | Microsoftの資料ではアクセス違反（STATUS_ACCESS_VIOLATION） | ゲーム更新後の不整合、MOD、メモリ安定性、該当ゲームの既知不具合 |
0xc0000374 | ヒープ破損（STATUS_HEAP_CORRUPTION）として記録される例外コード | ゲーム側パッチ、競合するフック系ソフト、複数ゲーム・他アプリでも起きるか |
ntdll.dll／KERNELBASE.dll | Windowsの共通DLLで例外が表面化した位置。DLL自体の故障と断定しない | 例外コードと発生するアプリの範囲を組み合わせて判断する |
「メモリを参照しました」や0xc0000005が表示される場合の確認手順、KERNELBASE.dllが表示された場合の見方は別記事で詳しく解説しています。
描画系LiveKernelEvent 141なら、ゲームのクラッシュとGPUの停止を分けて考える
Microsoftは、0x141をVIDEO_ENGINE_TIMEOUT_DETECTEDのライブダンプと説明しており、ディスプレイエンジンの一つが適時に応答しなかったことを示します。WDDMのTDR（Timeout Detection and Recovery）は、GPU処理が応答しない状況を検出し、復旧を試みる仕組みです。
GPUドライバー、過度なGPU・VRAMオーバークロック、電源配線、温度、ゲーム固有のGPU負荷など、確認対象は複数あります。まずOCを標準へ戻し、同じ場面で再現するかを確認してください。
LiveKernelEvent 141・117の違いとGPUクラッシュの確認順、「ディスプレイドライバーの応答停止」イベント ID 4101の見方もあわせて確認してください。
個別記録信頼性モニターが薄いときは、ゲーム側のCrash・Logsを先に探す
ランチャーやゲームエンジンが独自にクラッシュを記録し、Windows側には要約しか残らないことがあります。「ゲームだけ終了してデスクトップへ戻る」「画面全体は固まらない」場合は、ゲームのインストール先、Documents、AppData内のCrash、Crashes、Logsなどを確認します。
- クラッシュ直後に作成・更新された
.log、.dmp、.zipを探す - ゲーム名、日時、例外コード、使用中のMOD・オーバーレイを控える
- サポートへ送る前に、ファイルを移動せずコピーして保管する
範囲判定そのゲームだけか、複数ゲームかで確認の優先順位を変える
| 起き方 | まず疑う範囲 | 最初の切り分け |
|---|---|---|
| 特定のゲームだけ落ちる | ゲームファイル、パッチ、MOD、アンチチート、オーバーレイ、ゲーム設定 | ゲームファイルの整合性確認、MOD停止、描画設定を一段下げて同じ場面を再現する |
| 複数ゲーム・ベンチマークでも落ちる | GPU、ドライバー、メモリ、電源、温度、XMP／EXPO・OC | OCを標準へ戻し、温度・補助電源・再現する負荷を記録する |
| ゲーム以外のアプリも落ちる | Windows、メモリ、ストレージ、常駐ソフト、システム全体の安定性 | アプリの範囲と開始時期を確認し、Windows更新・常駐ソフト変更との前後関係を見る |
最後の手段繰り返すアプリクラッシュでは、WER LocalDumpsでダンプ採取を検討する
毎回同じゲームのプロセスが落ち、ゲーム側ログや信頼性モニターだけでは判断できない場合は、Windows Error Reporting（WER）のLocalDumpsを使ってユーザーモードダンプを採取する方法があります。Microsoftの資料では、LocalDumpsは既定で無効であり、レジストリのHKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps配下で設定します。
ダンプを読める開発元サポートや解析環境がある場合に有効な記録です。ゲーム独自のクラッシュレポーターがある場合、MicrosoftはそのプロセスにはLocalDumpsが適用されないことがあると案内しています。まずゲーム公式のログ収集手順を確認してください。
既定の保存先は%LOCALAPPDATA%\CrashDumpsです。大きいダンプが連続して作成される可能性があるため、空き容量を確認し、調査が終わったら不要なダンプを整理してください。
FAQイベントビューアーに何も出ないときのよくある質問
まとめエラーがないではなく、信頼性モニターから次の確認先を決める
ゲームが落ちた時にイベント ビューアーだけで原因を探すと、該当ログを見つけられずに時間を使いがちです。まずperfmon /relで信頼性モニターを開き、落ちた時刻、問題イベント名、例外コード、障害モジュールを確認してください。
APPCRASHならゲームファイル・MOD・ランタイム、LiveKernelEvent 141ならGPUの安定性とTDR関連、記録が薄いならゲーム側Crash／Logsを優先します。どのゲームでも起きるか、特定タイトルだけかで確認範囲を分けると、不要なドライバー再インストールや部品交換を避けやすくなります。
あわせて読みたい
※価格は2026年8月時点の目安・変動あり
※価格は2026年7月時点の目安・変動あり
