Event ID 153(nvlddmkm)でゲームが落ちるとき|Diskとの違いと切り分け方

ゲームがクラッシュし、イベントビューアーに「ソース:nvlddmkm」「イベントID:153」が記録されるときは、番号だけで原因を決めず、ソースとメッセージを確認することが出発点です。ディスク側にも153というイベントがありますが、別のイベントです。本記事では、ログを保存し、直前の変更と症状を照合して、不要なレジストリ変更や部品交換を避ける手順をまとめます。

目次

nvlddmkmの153とDiskの153は同じではない

MicrosoftのイベントID仕様では、イベントIDはソースごとに定義されます。Event ID 153という数字だけを見て「ストレージI/Oの遅延」と解釈することはできません。

ディスクエラーの公式資料にある153は、I/O処理の再試行などストレージ側の文脈です。これをNVIDIAドライバー関連のnvlddmkmに転用し、「SSDの遅延→GPUのTDRが典型原因」と断定しないでください。

TDRはWindowsがGPUの応答停止から回復を試みる仕組みですが、153という番号だけでTDRやGPU故障を確定できません。TDRが確認された場合でも、Microsoftの0x117解説はドライバー、冷却、電源、設定、部品など複数の要因を挙げています。

最初に保存する情報:ソース・時刻・メッセージ

スタートで「イベントビューアー」を検索し、[Windowsログ]→[システム]でクラッシュ時刻付近のイベントを開きます。ソース名、イベントID、発生日時、[全般]の全文を記録してください。[詳細]に表示される情報も、メーカーへの相談時に役立ちます。

同時に、ゲームが終了しただけか、画面が一時的に黒くなって戻ったか、PC全体が再起動したかを分けて記録します。「イベントが近い時刻に出た」ことと「そのイベントが原因である」ことは別です。ログは削除せず、相談先に必要な範囲で保存してください。

WHEA-Logger 17やKernel-Event Tracingが並ぶ場合

別ソースのイベントとして、一件ずつメッセージと対象デバイスを確認します。WHEA-Loggerの記録があれば、GPUなのか別のPCIe機器なのかを名前だけで決めつけないでください。Kernel-Event Tracingの警告も、並んでいるだけでクラッシュ原因とは限りません。BIOSのASPMやResizable BARを一律に切り替える根拠にはしないようにします。

安全な切り分けの順序

1. 発生直前に変えたものを確認する

Windows・GPUドライバー・ゲームの更新日、追加したオーバーレイや常駐ソフト、GPUやメモリの調整などを整理します。ひとつのゲームだけか、通常のデスクトップ操作でも起きるかを確認します。最初から長時間の高負荷テストを行う必要はありません。

2. 通常設定に戻し、一度に一つだけ比較する

自分で追加したオーバークロックや電圧変更がある場合は、変更前の状態を記録し、提供元の通常設定に戻して比較します。オーバーレイが関係しそうなら対象アプリだけ一時停止して再現性を確認します。複数の設定を同時に変えると、どれが影響したか分からなくなります。

再現試験は普段の操作で短く行い、異臭、異常な発熱、異音、電源断がある場合は繰り返さず使用を止め、メーカーへ相談してください。温度の許容値や必要な電源容量は製品ごとに異なり、全GPUに同じ温度・ワット数を当てはめられません。

3. 対応する公式ドライバーを確認する

PCメーカーやNVIDIAが対象機種・GPU・Windows向けに提供するドライバーと既知の問題を確認します。更新直後から症状が始まったなら、直前に正常動作していた対応版へ戻す選択肢を検討します。すべての環境に特定の古いバージョンを指定したり、Studio版の方が必ず安定すると考えたりしないでください。

DDUによる完全削除は最初の必須手順ではありません。通常の更新・ロールバックで状況を確認し、メーカーから専用手順を指示された場合にその条件を確認します。ノートPCではメーカー独自の構成も考慮してください。

4. ログと症状が続くならメーカーへ相談する

複数のゲームや通常操作でも再発する場合は、保存したログと構成情報をPC・GPUメーカーへ伝えます。ケーブルや電源の点検は製品説明書に従い、通電中の抜き差しや電源ユニットの分解はしないでください。部品交換は、エラー番号だけで決めず点検結果に基づいて判断します。

一律に変更しない設定

ページファイルをRAMの1.5〜3倍へ固定しない

Microsoftのページファイル資料では、必要量はコミット使用量とクラッシュダンプの要件で異なり、一般化できないとしています。まずシステム管理の設定と空き容量を確認し、「RAM32GBなら48〜96GB」と機械的に固定しないでください。固定サイズを増やすことはGPUエラーの一般的な解決策ではありません。

TdrDelayなどを一般向けの修正として変更しない

TDRレジストリの公式資料は、これらをドライバー開発時のテスト・デバッグ用とし、エンドユーザーが変更すべきではないとしています。待ち時間を延ばして症状を隠す手順は案内しません。

MPO無効化を「153なら必須」にしない

NVIDIAのMPO資料には機能の説明と無効化・復元の案内がありますが、nvlddmkmの153を一律に解消するとする説明ではありません。メーカーが該当症状に対して案内した場合に適用条件と復元方法を確認し、エラー番号だけでレジストリを追加しないでください。

電源プランの最大化、PCIe省電力の無効化、BIOS・ファームウェア更新も同様です。発熱や消費電力、機器の動作へ影響するため、原因の証拠なしにまとめて変更しないようにします。

ログを読み取るPowerShellコマンド

以下はログとGPU情報を読むための例で、ドライバー削除や設定変更は行いません。通常起動したWindowsのPowerShellで一つずつ確認します。対象のログがない場合はエラーや空の結果になることがあります。イベントビューアーのソース表記と照合してください。

# nvlddmkm ソースの直近の記録
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='nvlddmkm'} -MaxEvents 50 | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List

# ID 153 を抽出しても、ProviderName を必ず確認する
Get-WinEvent -FilterHashtable @{LogName='System'; Id=153} -MaxEvents 50 | Select-Object TimeCreated, ProviderName, Id, Message | Format-List

# GPU名とドライバーバージョン
Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion

Displayとnvlddmkmは同じソース名ではありません。Displayだけを抽出して、nvlddmkmの全記録を確認できたとは判断しないでください。ログに端末名やパスが含まれる場合は、不特定多数へ全文を公開する前に内容を確認します。

相談時にまとめるテンプレート

PCのメーカー・型番:
Windowsのバージョン:
GPU名・ドライバーバージョン:
発生したゲームと操作:
発生日時、画面や音の状態:
直前の更新・設定変更:
イベントのソース、ID、全般のメッセージ:
一つずつ試した変更と結果:

既存の設定を変えた場合は、効果がなければ記録した変更前の値に戻します。元の値が分からないレジストリやBIOS設定を、推測で変更して戻そうとしないでください。

まとめ:番号で断定せず、ソースから切り分ける

nvlddmkmの153をDiskの153として扱わないことが重要です。ソース・時刻・メッセージと実際の症状を保存し、直前の変更、対応ドライバー、通常設定の順に確認します。特定のレジストリ変更や旧ドライバーを一括適用して「高確率で直る」と保証できる問題ではありません。

公式確認日:2026年10月19日。本記事は実機で特定の対策の効果を検証した報告ではありません。対象機種と発生状況に合うメーカーの案内を優先してください。

コマンド仕様:Get-WinEvent、Win32_VideoController。ログの読み取り権限がない場合は管理者へ確認を依頼してください。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次