イベントID 1002でゲームが固まるが落ちない原因｜Application Hangを待機チェーンで切り分ける【2026年版】

出典：Microsoft Learn「タスク マネージャーを使用したプロセスのトラブルシューティング」ほか、記事末尾に挙げたMicrosoft公式資料にもとづきます（2026年9月9日確認）。

ゲーム中に画面が完全に止まり、音は同じ0.1秒を繰り返し、マウスを動かしても反応しない。それでもゲームはデスクトップへ落ちず、タスクマネージャーにはプロセスが残ったままになっている。この状態を強制終了したあとイベントビューアーを開くと、ソース欄が「Application Hang」、イベントIDが1002のエラーが残っていることがあります。

ゲームのクラッシュを調べると多くの資料がイベントID 1000を扱いますが、1000と1002は違う出来事を記録しています。1000は例外が発生してプロセスが終了したこと、1002はプロセスが残ったままWindowsへの応答を止めたことを示します。前者には例外コードという入口がありますが、後者にはそれがありません。

この記事では、イベントID 1002を見つけたあとに何を確認すれば原因へ近づけるのかを扱います。1002が記録されるタイミング、ゲーム以外のアプリの1002と取り違えない方法、そして中心となるタスクマネージャーの「待機チェーンの分析」で待ち相手を特定する手順です。そのうえでGPU、ストレージ、メモリのどこへ範囲を広げるかを、症状ごとに分けて整理します。

正体イベントID 1002が記録している状態とログの実物

イベントID 1002は、アプリケーションがWindowsとの対話を停止したときに記録されるイベントです。イベントビューアーの「Windowsログ」から「Application」を開くと、ソース欄が「Application Hang」になっているエラーとして見つかります。

ログの名前:  Application
ソース:      Application Hang
イベント ID: 1002
レベル:      エラー

プログラム Game.exe バージョン x.x.x.x は
Windows との対話を停止し、終了しました。

プロセス ID:
開始時刻:
終了時刻:
アプリケーション パス:
レポート ID:
停止の種類:

ここで押さえておきたいのは、1002はゲームが異常終了したことを示すイベントではないという点です。例外が発生してプロセスが即座に消えるクラッシュとは異なり、Application Hangはプロセスが生きたまま応答を返さなくなった状態を指します。ゲーム画面が固まっているあいだ、そのプロセスはメモリ上に存在し続けています。

1002はゲーム専用のイベントでもありません。エクスプローラーや設定アプリなど、Windows上のあらゆるウィンドウを持つアプリが応答を止めれば同じ1002が記録されます。ゲームのフリーズを調べているときにこの点を忘れると、無関係なアプリのログを追いかけることになります。

なお、1002の前後にWindowsエラー報告のイベントID 1001が並ぶことがあり、その場合はバケットの種類として AppHangB1 と表示されるのが一般的です。これは「B1という種類のエラーが起きた」という意味ではなく、Windowsエラー報告がハングとして分類したという情報にすぎません。原因の特定にはつながらないため、ここを深追いする必要はありません。

違いイベントID 1000との違いは「落ちた」か「止まった」か

同じゲームのトラブルでも、1000と1002では次に見る場所がまったく変わります。

イベントID 1000では、KERNELBASE.dllやntdll.dllといった障害モジュール名と、0xc0000005などの例外コードが記録されます。どちらもクラッシュの性質を絞り込む値なので、そこから調査を始められます。障害モジュール名だけで判断せず例外コードまで見る考え方はKERNELBASE.dllでゲームが落ちる原因の記事で、0xc0000005そのものの読み方は「メモリを参照しました」の記事で扱っています。

一方の1002には、そうした値がありません。ゲームのスレッドが何かを待ち続けた結果として応答が止まっているため、ログの中に原因を名指しする文字列が入らないのです。だからこそ、ログ以外の場所で待ち相手を突き止める必要があります。

記録されていたのが1002ではなく1000だった場合は、イベントID 1000の診断チャートに、障害モジュール名と例外コードの組み合わせから該当記事へ進む分岐をまとめてあります。

前提1002は固まった瞬間ではなく終了したあとに書かれる

イベントID 1002の本文は「Windows との対話を停止し、終了しました」という形をとります。つまりこのイベントは、応答が止まったアプリが最終的に閉じられたところまでを含めた記録です。

この性質は診断の順序に直結します。ゲームが固まった直後にイベントビューアーを開いても、まだ1002が入っていないことがあります。タスクマネージャーから強制終了したあとで確認すると見つかる、という順番になりやすいのです。「イベント1002がないからハングではない」と早合点しないでください。

照合時刻とアプリケーションパスをゲームと突き合わせる

1002を見つけたら、最初に確認するのはアプリケーションパスとプロセスIDです。ゲームが21時32分に固まったのなら、その時刻付近に記録された1002の実行ファイルが、実際に固まったゲーム本体になっているかを確かめます。

ゲームランチャー、Steamクライアント、ボイスチャットアプリ、エクスプローラーなど、別のアプリが同じ時間帯に1002を出していることは珍しくありません。ゲームが固まったときに巻き添えで一時的に応答を止めただけの場合もあります。パスが実際のゲームの実行ファイルを指していなければ、そのログはいったん脇に置いてください。

同時にイベントID 1000も記録されている場合は、発生時刻の前後関係を見ます。1002のあとに1000が来ているなら、応答を停止したあと最終的に例外で終了した可能性があります。この場合は1000側の例外コードから追うほうが早く進みます。

核心待機チェーンの分析で「何を待っているか」を見る

イベントID 1002の調査で最も効くのが、タスクマネージャーに標準で入っている「待機チェーンの分析」です。Microsoftのタスクマネージャー解説では、応答しないプロセスは他のプロセスの完了やシステムリソースが利用可能になることを待っている場合があり、タスクマネージャーはその依存関係をプロセスの木構造として表示できると説明されています。

手順は次のとおりです。

1. 固まっても強制終了せず、タスクマネージャーを開きます。Ctrl＋Shift＋Escが効かない場合はCtrl＋Alt＋Delete経由で開きます。
2. 「詳細」タブでゲームの実行ファイルを選びます。状態列が「実行中」になっていることを確認してください。中断状態のプロセスは分析できません。
3. 右クリックして「待機チェーンの分析」を選びます。他を待っていなければ「正常に実行されています」と表示されます。
4. ツリーに出た相手を控えます。チェックを入れて終了させると、固まりが解ける場合があります。

ここで表示される待機チェーンとは何かは、開発者向けのWait Chain Traversal（WCT）の資料に定義があります。待機チェーンはスレッドと同期オブジェクトが交互に並ぶ連鎖で、それぞれのスレッドが直後のオブジェクトを待ち、そのオブジェクトはさらに次のスレッドが所有しているという関係です。スレッド1がスレッド2の持つロックを待っているとき、スレッド1はスレッド2を待っていることになります。この仕組み自体が、アプリケーションのハングとデッドロックを診断するために用意されたものだと明記されています。

WCTが対応しているのは、ALPC、COM、クリティカルセクション、ミューテックス、SendMessage関数、そしてプロセスとスレッドに対する待機操作です。この一覧にSendMessageが含まれている点はゲームのフリーズを追ううえで重要で、ウィンドウメッセージの送信待ちで止まっている場合も可視化の対象になります。オーバーレイやフック系のツールがゲームウィンドウへ介入している構成では、ここが手掛かりになります。

ゲームが固まるたびに同じプロセスが待機チェーンへ現れるなら、その相手が調査の中心になります。逆に「正常に実行されています」と出るなら、他プロセスを待っているのではなく、ゲームの内部で処理が終わっていない可能性が高くなります。なお、タスクマネージャーは個々のスレッドの詳細までは表示しません。そこから先はダンプの領域です。

分岐CPU使用率が0％近いか、張り付いたままか

待機チェーンを開くのと同時に、そのプロセスのCPU使用率も見ておきます。0％近くまで落ちているか、逆に高いまま維持されているかで、疑う方向が変わります。

CPU使用率が低いからCPUは無関係、とは判断できません。メインスレッドが待機状態に入ればCPUはほとんど使わなくなるためで、0％はむしろ「待っている」ことの傍証です。GPU使用率まで含めて何を待っているかを見分ける考え方はGPU使用率が突然0％になる原因の記事と共通しています。

範囲1タイトルだけか複数タイトルかで調べる場所を分ける

「何本のゲームで起きるか」は、1002の原因を絞るうえで最も強い情報です。ここを確認せずにWindowsの修復から始めると、ほとんどの場合は遠回りになります。

1タイトルだけで起きるなら、ゲームのアップデート直後から始まっていないか、特定のマップやセーブデータだけで再現しないかを探します。ゲームファイルの整合性確認はこの段階で実行して構いません。再インストールは時間がかかるため、MODとオーバーレイを外した比較を先に済ませてからで十分です。

GPU画面が一瞬暗転するならTDRの側を見る

ゲームが固まる瞬間に画面全体が一度暗転する、ディスプレイが再接続されたようになる、ほかのアプリまで一瞬止まるといった症状があるなら、GPU側の応答停止が絡んでいる可能性があります。

WindowsのWDDMには、グラフィックスカードの処理が想定より長引いたことを検出してリセットするTDRという仕組みがあります。検出を担当するのはDirectXグラフィックスカーネルサブシステム（Dxgkrnl.sys）のGPUスケジューラで、Windowsの既定のタイムアウトは2秒です。この時間内に処理を完了も中断もできない場合、WindowsはGPUが停止したと判断します。

復旧に成功すると「ディスプレイ ドライバーが応答を停止しましたが、正常に回復しました」というメッセージが表示され、同じ内容がイベントビューアーにも記録されます。目に見える痕跡は画面のちらつきだけです。ここで重要なのは、TDRが成功したあとでもゲーム側が黒画面のまま戻らないことがある点です。Microsoftの資料でも、Device Removeに対応していない古いDirectXアプリはリセット後に黒く描画されるだけになり、ユーザーが再起動する必要があると説明されています。Windowsから見ればGPUは復旧しているのに、ゲームだけが固まったまま1002になるという食い違いは、この仕組みで説明がつきます。

加えて、1分以内に5回以上のGPUハングと復旧が続くと、6回目でWindowsがバグチェックを行う設計になっています。同時刻にディスプレイ関連のイベントが並んでいるなら、グラフィックス経路の優先度を上げてください。ディスプレイドライバーの応答停止そのものはイベントID 4101の記事で、バグチェックまで至った場合はLiveKernelEvent 141・117の記事で扱っています。ドライバーの応答時間そのものを測りたい場合はLatencyMonでdxgkrnl.sysが高い原因の記事が使えます。

GPU経路を疑う場合の比較対象は、ハードウェアアクセラレーションによるGPUスケジューリング、各種オーバーレイ、録画ソフトです。ただしすべてを一度に無効化すると、何が効いたのか分からなくなります。まずオーバーレイだけを切って再現するかを見て、変化がなければ元へ戻し、次の項目へ移ってください。

ストレージロード中だけ固まるならI/O待ちを疑う

固まるタイミングがロード画面やエリア移動に偏っているなら、ストレージ側の応答を待っている可能性があります。SSDへの要求が正常に完了しなければ、ゲームはデータの到着を待ち続け、その結果としてウィンドウが応答しなくなります。

確認したいのは、タスクマネージャーのディスク使用率ではなく応答時間です。転送速度がほぼ0MB/sなのにアクティブ時間だけ100％に張り付いている場合は、単なる高負荷ではなく応答遅延を疑う価値があります。ゲームが固まった時刻とシステムログのイベントID 129、153、157が一致するなら、原因はApplication Hangより下の層にあります。この場合の読み方はstornvmeのイベントID 129・153・157の記事に分けてあります。

メモリ長時間プレイ後だけならコミット上限を確認する

起動直後は問題なく、数時間プレイしたときだけ固まるなら、メモリの余力を見ます。ゲーム本体やMODがメモリを解放しないままシステムコミットの上限へ近づくと、Windows全体が極端に重くなり、アプリがメモリを確保できなくなります。

見るのはタスクマネージャーのメモリ使用率ではなく、「パフォーマンス」から「メモリ」を開いたところにある「コミット済み」の現在値と上限の距離です。ゲームを終了して大きく下がるならゲーム側、閉じても高止まりするなら常駐プロセスやドライバー側まで対象を広げます。1002と同じ時刻付近にイベントID 2004が記録されている場合は、ハングそのものより先にメモリ不足を調べてください。判定手順はイベントID 2004の記事にまとめてあります。

環境MOD・オーバーレイ・アンチチートは1つずつ戻す

ゲームのプロセス内部へ処理を追加するものは、Application Hangの切り分けで一度外す価値があります。グラフィックMOD、スクリプト拡張、FPS表示ツール、画面効果ツールなど、DLLを読み込ませるタイプはすべて対象です。ゲームのアップデート後にMODだけが古いまま残っていると、起動はできても特定のタイミングで待機が解けなくなることがあります。

比較の仕方は単純です。バニラ状態で同じ時間プレイして再現しなければMOD環境、バニラでも同じように固まるならゲーム本体かPC側です。ここで結果が出れば、Windows全体の修復へ進む必要はなくなります。

オンラインゲームではアンチチートも候補になります。ゲーム本体と別プロセスやサービスの通信が完了しなければ、ウィンドウが応答しなくなる可能性があるためです。ただしアンチチートを削除したり無効化したりするとゲーム自体が起動できなくなるので、開発元が案内している修復や再インストールの手順を使ってください。同じアンチチートを採用したタイトル群だけで1002が出るなら、それ自体が共通点として有力です。

記録固まった瞬間のダンプを取ると解析できる情報が変わる

待機チェーンを見ても相手が分からない場合は、固まっている最中のプロセスダンプが有効です。タスクマネージャーでプロセスを右クリックし、「ダンプ ファイルの作成」を選ぶだけで取得できます。Microsoftの資料でも、プロセスの詳細な情報をダンプして解析したり、サポート提供元へ渡したりできる機能として案内されています。

ただし、突然固まってタスクマネージャーを開く余裕がないこともあります。その場合はMicrosoft SysinternalsのProcDumpを使うと、ハングを検出して自動的にダンプを作成できます。ProcDumpにはハングしたウィンドウの監視機能があり、Windowsやタスクマネージャーがウィンドウのハングをどう判定しているかと同じ定義を使う点が公式に明記されています。

rem ウィンドウが5秒以上応答しない場合にダンプを作成する
procdump -h Game.exe

rem より詳しい解析用にフルダンプとカーネルスタックを含める
procdump -ma -mk -h Game.exe

-hは、プロセス内のウィンドウが5秒以上ウィンドウメッセージへ応答しない場合にダンプを作成するオプションです。ProcDumpの動作対象はWindows 11以降のクライアントOSとされています。ダンプの解析自体はユーザーが行うものではありませんが、「固まっているスレッドがどこで待っていたか」という情報はクラッシュ後のログからは取れないため、ゲーム開発元へ不具合を報告するときの材料として価値があります。

回り道TdrDelayの延長とSFC・DISMは最初にやらない

ゲームのフリーズ対策を検索すると、レジストリでTdrDelayを延ばす方法が上位に出てきます。しかしこれは「Windowsが停止と判断するまでの時間」を延ばす設定であって、止まっている原因を直すものではありません。TDR関連のレジストリ値はMicrosoftの資料でもテストとデバッグ用として案内されている項目で、常用を前提にした設定ではないのです。GPUが本当に停止しているなら、復旧までの待ち時間が延びるだけになります。

SFCやDISMも同様です。イベントID 1002はWindowsのシステムファイル破損を示すイベントではありません。特定のゲームだけが固まり、ほかのアプリやWindows自体は正常に動いているなら、ゲーム、MOD、GPUドライバーを先に切り分けたほうが確実です。エクスプローラーや設定アプリまで同時期からハングし始めた、Windows Updateの直後から全体がおかしいといった場合に限り、Windows側の修復まで範囲を広げてください。

手順イベントID 1002を見つけたあとの切り分け順序

1. 1002の時刻とアプリケーションパスをゲームと照合します。そのログが本当にゲームのものかがここで決まります。
2. 1タイトルだけで起きるのか、複数タイトルで起きるのかを確認します。ゲーム側かPC側かの大枠が分かります。
3. 固まった状態で待機チェーンの分析を開きます。待ち相手のプロセスがいるかどうかが分かります。
4. 同時にCPU使用率を確認します。待っているのか、処理が終わらないのかを分けられます。
5. 可能ならダンプを作成してから終了します。停止していたスレッドの状態を残せます。
6. 同時刻に記録された他のイベントを突き合わせます。GPU・ストレージ・メモリのどれが本命かが見えてきます。
7. MODとオーバーレイを1つずつ戻して比較します。外部コンポーネントの関与を確定できます。

6番目の突き合わせでは、ディスプレイ関連のイベントが並んでいればGPU、イベントID 129や153が並んでいればストレージ、イベントID 2004が出ていればメモリのコミット上限を優先します。1002単体では分からなかった原因が、この組み合わせで見えてくることがあります。

FAQよくある質問

まとめ1002は原因のコードではなく診断の入口として読む

イベントID 1002は、ゲームが例外で落ちたことではなく、プロセスが残ったままWindowsへの応答を止めたことを記録しています。イベントID 1000のように例外コードや障害モジュール名という入口がないため、ログを眺めているだけでは原因にたどり着けません。

代わりの入口が「何を待っていたのか」です。タスクマネージャーの待機チェーンの分析は、まさにその依存関係を見るために用意された機能で、対象にはウィンドウメッセージの送信待ちまで含まれます。ここを見ずに強制終了してしまうと、残るのは結果だけを書いた1002のログになります。

あわせて読みたい

トラブル・設定

イベントID 4101でゲームが落ちる原因｜「ディスプレイドライバーの応答停止」を切り分ける【NVIDIA/AMD/Intel共通】

トラブル・設定

stornvmeイベントID 129・153・157の原因と直し方｜ゲーム中のフリーズ・SSD応答停止を切り分け【2026年版】

トラブル・設定

イベントID 2004でゲームが落ちる・フリーズする原因｜RAM故障ではなくコミット上限不足を切り分ける手順【2026年版】

トラブル・設定

ゲーム中にGPU使用率が突然0%になる原因｜CPU・VRAM・SSD・ドライバーの待ちとTDRを切り分ける【2026年版】