イベントID 2004でゲームが落ちる・フリーズする原因｜RAM故障ではなくコミット上限不足を切り分ける手順【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
記録されているのはRAMの故障ではなく、システムコミット上限の枯渇
出典：Microsoft Learn「アプリケーションまたはサービスのメモリ リークのトラブルシューティング ガイダンス」ほか、記事末尾に挙げたMicrosoft公式資料にもとづきます（2026年9月9日確認）。
ゲーム中に数秒のフリーズが起きたり、そのまま強制終了したりしたあと、イベントビューアーを開くと「イベントID 2004」が残っていることがあります。ソース欄には Microsoft-Windows-Resource-Exhaustion-Detector と表示され、名前だけを見るとメモリモジュールが壊れたようにも読めます。
しかしイベントID 2004が検出しているのは、物理メモリのビットエラーではなく、Windowsが新しいメモリを確保するための余力、いわゆるシステムコミット上限が尽きかけた状態です。そのためタスクマネージャーのメモリ使用率が100%になっていなくても記録されますし、逆にこのイベントだけを根拠にメモリ診断ツールを走らせても、原因にはたどり着きません。
この記事では、イベントID 2004そのものの読み方に絞って切り分けます。説明欄のどこを見るか、クラッシュの時刻とどう突き合わせるか、記録されたプロセスが本当に原因かをどう判定するか、そしてユーザー側のアプリで説明がつかない場合にドライバーまで疑いを広げる手順までを扱います。コミット済みメモリの用語解説やページファイルの設定方針、増設容量の判断は既存の解説記事に譲り、必要な箇所からリンクします。
目次
正体イベントID 2004が記録している状態とログの実物
イベントID 2004は、WindowsのResource Exhaustion Detectorという診断機能が、システムリソースの枯渇を検出したときにシステムログへ残す警告です。Microsoftのトラブルシューティング資料では、このイベントが繰り返し記録される状況を「仮想メモリ領域のシステムにリソース不足がある」状態として説明しており、ログのキーワード欄にもシステムコミット上限の枯渇に関するイベントである旨が入ります。
Log Name: System
Source: Microsoft-Windows-Resource-Exhaustion-Detector
Date: <DateTime>
Event ID: 2004
Task Category: Resource Exhaustion Diagnosis Events
Level: Warning
Keywords: Events related to exhaustion of system commit limit (virtual memory).
User: SYSTEM
Computer: <ComputerName>注目したいのはキーワード欄の system commit limit という語です。ここでいうコミット上限とは、Windowsがアプリに対して「必要になったら必ずメモリを用意する」と約束できる総量のことで、物理メモリとすべてのページファイルを合算して決まります。イベントID 2004は、この約束の枠が埋まりかけたことを示す記録であり、メモリチップ上でデータが壊れたことを示す記録ではありません。
そしてイベントの説明欄には、その時点でシステムのメモリを多く消費していたプロセスの一覧が出力されます。ここが調査の出発点になります。コミット済みという指標そのものの意味や、コミット上限がどう計算されるかを詳しく確認したい場合は、Windows 11の「コミット済み」メモリの意味を解説した記事にまとめてあります。
誤解Resource Exhaustionはメモリの物理故障を指す言葉ではない
Resource Exhaustionを直訳すると「リソースの枯渇」なので、メモリモジュールに異常が起きたように読めます。実際、イベントID 2004を見つけてWindowsメモリ診断やMemTest86から着手する人は珍しくありません。
しかしこのイベントは、メモリセルのビットエラーやモジュールの接触不良を検出する仕組みではありません。検出しているのはあくまで、新しいメモリ確保に必要な余力が減った状態です。したがってイベントID 2004しか手掛かりがない段階でメモリテストを何時間も回すのは、遠回りになります。
MEMORY_MANAGEMENTなどのブルースクリーンが繰り返し出る、XMPやEXPOを有効にすると不安定になる、複数のアプリでランダムにデータが壊れるといった症状があるなら、そちらは物理メモリの安定性の問題として別に調べる価値があります。逆にイベントID 2004が単独で記録されているだけなら、まずコミットの使用状況とプロセスの挙動を確認してください。XMPやEXPOを有効にしたこと自体がコミット上限を小さくすることはないため、2004が出たという理由だけで定格へ戻す必要もありません。
読み方イベントビューアーで確認するのは3か所
スタートメニューから「イベントビューアー」を起動し、左のツリーで「Windowsログ」から「システム」を開きます。右側の「現在のログをフィルター」でイベントIDに 2004 を入力すると、該当イベントだけが並びます。開いたら次の3か所を順に確認してください。
照合記録時刻とクラッシュ時刻を突き合わせる
イベントID 2004を診断に使ううえで、もっとも費用対効果が高い作業がこの照合です。イベントビューアーには過去のイベントが蓄積されているため、探せば何かしら見つかります。それが今回の不調と結び付くかどうかは、時刻でしか判断できません。
たとえばゲームが22時15分に落ち、イベントID 2004も22時15分前後に記録されているなら、メモリ確保の失敗がクラッシュに関与した可能性は高くなります。反対に、直近1か月のイベントが3週間前の1件だけで、その後は毎晩プレイしていても記録がないのであれば、いま起きているクラッシュの原因は別にあると考えたほうが早く進みます。
なお、ゲームが落ちてもイベントビューアーに何も残らないケースもあります。その場合の追い方は信頼性モニターを使った確認手順の記事で扱っています。
切り分けイベントID 2004を見つけたあとにたどる4つの分岐
時刻が一致していることを確認できたら、次の順序で原因を絞ります。上から順にたどると、余計な作業を挟まずに結論へ近づけます。
ここで分岐2に出てくるコミット済みは、タスクマネージャーを Ctrl＋Shift＋Esc で開き、「パフォーマンス」から「メモリ」を選ぶと確認できます。左側が現在の使用量、右側が上限です。上限側に余裕がまったくないようなら、ページファイルの設定が影響している可能性があります。無効化や固定サイズにしている場合の考え方はページファイルは自動管理でいいかを検証した記事にまとめてあります。
判定説明欄の先頭にいるプロセスが原因とは限らない
説明欄の一番上に表示されたプロセスを見て、そのアプリにメモリリークがあると即断しないでください。Resource Exhaustion Detectorが並べているのは、そのときメモリを多く使っていたプロセスであり、異常なプロセスを名指ししているわけではないためです。
高負荷なゲームを起動していれば、ゲーム本体が最大の消費者になるのは自然な結果です。ゲームが16GB、ブラウザーが3GB、ボイスチャットが1GB、録画ソフトが2GBという状態でコミット上限に届いたとしても、ゲームに欠陥があるとは限りません。単に同時起動しているアプリの合計が、そのPCの上限を超えただけということがあります。
この2つを分けるには、瞬間の数値ではなく時間の経過を見る必要があります。Microsoftもメモリリークの調査では、タスクマネージャーに Commit Size、Handles、User Objects、GDI Objects の列を追加し、基準値を作ったうえで時間経過による消費の変化を監視する手順を案内しています。ゲーム起動直後の値を控え、1時間後、2時間後、問題が起きる直前で比較してください。イベントが数時間に1回しか出ず、タスクマネージャーを見続けるのが難しい場合は、Windows標準のパフォーマンスモニター（perfmon）で記録を残す方法もあります。リークは数時間かけてゆっくり増えることがあるため、点ではなく線で見るという考え方は共通です。
| 観察できる動き | 考えられる状態 | 次にやること |
|---|---|---|
| 起動直後に一気に増え、その後は横ばい | 正常なメモリ確保。使用量が多いだけ | 同時起動アプリを減らして再現するか確認する |
| プレイ時間に比例して一方向に増え続ける | そのプロセス側のリークの疑い | MODやオーバーレイを外して同条件で比較する |
| ゲーム終了で大きく下がる | ゲームのセッション内で累積している | ゲーム本体と読み込まれる追加要素を切り分ける |
| ゲームを終了しても下がらない | 常駐プロセスまたはカーネル側の可能性 | 非ページプールの推移を確認する |
マップ移動の直後に一時的に増えても、その後で下がったり一定値で止まったりするなら、キャッシュとして正常に働いている可能性が高くなります。リークの判断材料になるのは使用量の大きさではなく、解放されないまま積み上がり続ける形です。長時間プレイでの増え方を追う考え方は、GPU側の事例ですがVRAM使用量が増え続ける場合の見分け方の記事と共通しています。
カーネル非ページプールが増え続けるならドライバーを疑う
アプリをすべて閉じてもコミット済みが高いまま下がらず、Windowsを再起動したときだけ大きく減る場合は、ユーザー側のアプリだけでは説明がつきません。個々のプロセスのコミットサイズを足してもシステム全体の使用量と合わないようなら、Windowsカーネルやデバイスドライバーが使っている領域を見ます。
タスクマネージャーの「パフォーマンス」から「メモリ」を開くと、下部に「ページプール」と「非ページプール」が表示されます。非ページプールは、ディスクへ退避できない種類のカーネルメモリです。ここが時間とともにGB単位で増え続け、再起動するまで戻らないのであれば、カーネルモードで動くドライバーがメモリを解放していない可能性が出てきます。
この段階でまず試すのは、GPU、有線LAN、Wi-Fi、Bluetooth、USBオーディオ、周辺機器のライティング制御ソフトなどのドライバー更新です。直前に導入した機器やソフトウェアがあれば、いったん外して再現するかを確認します。ここまでで解決することも珍しくありません。
最終手段PoolMonでプールタグから絞り込む
ドライバー更新でも非ページプールの増加が止まらない場合に、はじめてPoolMonの出番になります。PoolMon（Poolmon.exe）は、プールタグという識別子ごとにカーネルのプールメモリ使用量を監視するツールで、Windows Driver Kit（WDK）に含まれています。ヘッダーにページプールと非ページプールの合計が表示され、その下の各行がプールタグごとの使用量で、表示は数秒ごとに自動更新されます。
使い方の考え方はシンプルで、しばらく動かしたまま放置し、割り当てが一方向に増え続けているプールタグを探します。増加しているタグが分かれば、そのタグを使っているドライバーへ範囲を絞れます。
PoolMonが有効なのは、ユーザーモードのプロセスを確認しても大きな消費者が見当たらず、ページプールまたは非ページプールだけが増え続けている場合です。説明欄にゲーム本体が大きな数値で記録され、タスクマネージャーでも同じプロセスのコミットサイズが伸び続けているなら、WDKを導入するより先にゲーム側とMODを調べたほうが早く原因に届きます。
誤爆MsMpEng.exeやブラウザーが並んだときの読み方
説明欄に見慣れないプロセス名が並ぶと、そこが原因に見えてしまいます。よく話題になる2つについて整理します。
MsMpEng.exe は Microsoft Defender ウイルス対策に関係するプロセスです。ゲーム中にスキャンが重なれば負荷は上がりますが、一覧に名前が出たというだけでセキュリティ機能を無効化するのは順序が逆です。ゲーム本体などと比べてどの程度の量を消費しているかを見て、数百MB程度で上位に入っているだけなら、そもそもコミットの余力が足りていない可能性を先に疑ってください。
chrome.exe や msedge.exe も同様です。ブラウザーはタブや拡張機能、動画再生で大きくメモリを使いますが、それ自体は異常ではありません。ゲームを起動していない状態でもブラウザーのコミットサイズが伸び続けるのか、タブを閉じれば戻るのかを比べると、リークなのか単なる使用量なのかを分けられます。ゲームとブラウザーを同時に使ったときだけ上限に届くのであれば、合計容量の問題です。増設すべきかどうかの判断基準はRAM不足の症状と必要容量を整理した記事で扱っています。
別系統2004が出ていない場合とVRAM側との切り分け
ゲームが落ちてもイベントID 2004が記録されておらず、コミット済みにも余裕があるなら、メモリ方向を掘り続けても成果は出にくくなります。GPUドライバー、DirectXの実行環境、ゲームファイルの破損、CPUやGPUのオーバークロック、ストレージなど、別の原因を順に当たったほうが確実です。イベントID 2004は、あくまでリソース不足が実際に診断されたときの手掛かりです。
もうひとつ混同しやすいのがVRAMとの関係です。グラフィックボードに搭載された8GBや16GBといった専用ビデオメモリと、イベントID 2004が扱うシステムコミットは別の領域です。VRAMが足りなければテクスチャの入れ替えによるカクつきや、ゲーム側の「Out of video memory」というエラーが出ますが、それはこのイベントとは別系統の症状です。両方が同時に起きることはあっても、2004が出たからグラフィックボードのメモリが足りない、とは判断できません。エラー表示から追いたい場合は「Out of video memory」の切り分け記事を参照してください。
FAQよくある質問
まとめ2004は容量ではなく余力の記録として読む
イベントID 2004は、ソースが示すとおりResource Exhaustion Detectorによる診断結果であり、Windowsが新しいメモリを確保するための余力が尽きかけたことを示す警告です。物理メモリの故障を示す記録ではないため、ここからメモリテストへ直行すると遠回りになります。
確認の順序は、記録時刻とクラッシュ時刻の照合、コミット済みと上限の距離、説明欄に並んだプロセスの時間変化、そして非ページプールの推移です。この順にたどれば、合計需要の超過なのか、特定プロセスのリークなのか、ドライバー側の問題なのかを分けられます。
イベントID 2004で見るべきなのは、RAMの使用率ではなく「コミット済みの現在値と上限の距離」「ページファイルの設定と空き容量」「説明欄に出たプロセスの増え方」の3点です。この3点だけで、合計需要の超過とリークはかなりの精度で分けられます。
説明欄の先頭にあるプロセスは、その時点の最大消費者であって原因の名指しではありません。時間をおいて2回以上記録し、横ばいか増え続けるかを見てから、アプリ側かドライバー側かを判断してください。
ユーザーモードのプロセスで説明がつかず、非ページプールだけが増え続ける場合に限り、PoolMonでプールタグを追う段階へ進みます。最初から使う道具ではありません。メモリ関連の症状を横断して探したい場合は、メモリ・DDR5のトラブル診断チャートから該当する記事へ進めます。
あわせて読みたい
