Unreal Engine/Unity 製ゲームがランダムに落ち、イベントログに nvlddmkm（Event ID 153/TDR）や Kernel-Power 41 が残る——そんな症状は GPU のハングと復旧（TDR）が起点になっていることが多いです。Ryzen 5 5600X + RTX 3060 Ti などの構成を例に、原因の切り分けと実践的な直し方をまとめます。
まず押さえるべき全体像：TDR（Timeout Detection and Recovery）とは何か
イベントビューアーで nvlddmkm（NVIDIA のディスプレイドライバー）に関するエラーが出て、本文に TDR や Resetting/Reset/Restarting といった表現が含まれている場合、典型的には次の流れで障害が起きています。
- ゲームの負荷変動や瞬間的な電力スパイク、ドライバーの不整合などをきっかけに GPU が一時的に応答不能（ハング）になる
- Windows が「一定時間 GPU から応答が返らない」と判断し、ドライバーをリセットして復旧しようとする（これが TDR）
- 復旧に成功しても、描画デバイスが失効するためゲーム側はクラッシュしやすい（Unreal/Unity のクラッシュログや LowLevelFatalError などにつながる）
- 復旧に失敗すると、画面フリーズやブラックアウトのまま戻らず、強制再起動になりやすい
その結果として、クラッシュ時刻付近に nvlddmkm（Event ID 153） が出たり、強制再起動後に Kernel-Power（Event ID 41） が残ったりします。Discord や iCUE などのバックグラウンドアプリが同時に固まるのも、GPU リセットで 画面描画（DWM）やハードウェアアクセラレーション周りが巻き込まれるため、説明がつきます。
イベントログの読み方：nvlddmkm 153 と Kernel-Power 41 の意味
ログは「原因そのもの」ではなく「起きた現象」を示すことが多いです。特に Kernel-Power 41 は“結果ログ”になりやすいので、まずは役割を分けて読みます。
| ログ/症状 | 何が起きているか | よくある原因カテゴリ | 次に見るべきポイント |
|---|---|---|---|
nvlddmkm / Event ID 153\Device\Video3 や Resetting TDR occurred など | GPU/ドライバーが応答不能になり、Windows が TDR で復旧を試みた | GPU の電圧・クロック不安定（OC/UV）、ドライバー不整合、過熱、給電不足/瞬断、VRAM/コア不安定 | 直前に負荷が跳ねた場面、温度（ホットスポット/VRAM）、電源配線、最近変更した設定（アンダーボルト等） |
| Kernel-Power / Event ID 41 | 正常なシャットダウン手順を踏まずに再起動した（フリーズ→電源長押し等） | 上記の TDR 復旧失敗、電源瞬断、システム全体ハング、メモリ不安定 | 再起動直前に画面がどうなったか（ブラックアウト/フリーズ）、WHEA エラーの有無、PSU/コンセント/タップ |
| ゲームが落ちるだけで OS は戻る | TDR 復旧は成功したが、ゲーム側が耐えられず終了 | GPU 不安定（軽度）、ドライバー/オーバーレイ干渉、ゲーム側の例外 | 同一ゲームだけか、複数ゲームで起きるか、他アプリ（Discord 等）の同時フリーズ有無 |
| まれに OS までフリーズして強制再起動 | TDR から戻れない/電源が落ちる等でシステムが継続不能 | GPU/PSU/マザボ側の給電・安定性、過熱、ドライバー致命的不整合 | 電源ケーブルの系統、PSU 容量と品質、GPU ホットスポット、BIOS/チップセット |
「起動後1分〜1時間」とランダムに見える理由
このタイプのクラッシュが厄介なのは、同じゲームでも毎回同じ場所で落ちるとは限らず、“運が悪いと落ちる”ように見える点です。実際には、次のような負荷の揺れがトリガーになっていることが多いです。
- シェーダーコンパイルやアセットストリーミングで、短時間だけ GPU に重い処理が集中する
- D3D12/Vulkan などで フレーム生成やポストエフェクトの負荷が一瞬跳ねる
- メニュー画面やローディングでも、裏でリソース準備が走り、GPU の負荷が波打つ
- オーバーレイ（Discord/Steam/GeForce Experience）や RGB ツール（iCUE 等）が同時に描画に関わり、競合やタイミング問題が起きる
つまり「重いシーン＝必ず落ちる」ではなく、負荷の立ち上がり・瞬間的なピークが不安定域に刺さったときに落ちるため、発生時間がバラけます。特に アンダーボルトは、平均負荷が下がって温度は良さそうに見える一方で、ピーク時に電圧が足りず落ちる、という形で症状が出やすいです。
結論：まずは GPU の安定性（電圧・クロック）を“定格”に戻して確認する
nvlddmkm + TDR が出ている時点で、最初にやるべきは GPU を完全に定格へ戻し、「ソフトの問題か、ハードの安定性か」を切り分けることです。Windows の初期化より先に、ここをやる価値があります。
| やること | 狙い | 具体例 | 判断 |
|---|---|---|---|
| OC/UV を全部やめる | 不安定化要因をゼロにして再現性を見る | MSI Afterburner のリセット、GPU メーカーOCツールの無効化、NVIDIA アプリ側のチューニングをオフ | 定格で安定するなら「設定起因」が濃厚 |
| 電力制限を戻す | ピーク電力不足や制限によるハングを除外 | Power Limit を標準へ | 制限が強いほど TDR が増えるなら要注意 |
| 負荷テストを短時間で回す | ゲーム依存か、GPU負荷全般で落ちるか確認 | 3DMark / Unigine / OCCT の GPU テストなど | テストで落ちるならゲームよりハード寄り |
この事例の決定打：過度なアンダーボルトが原因で不安定化
Ryzen 5 5600X + RTX 3060 Ti といった構成では、ゲーム側の問題に見えて実は GPU の“過度なアンダーボルト”が引き金になっているケースがあります。省電力目的で電圧を下げると、平均温度は下がって「うまくいっている」ように見えますが、ゲームの負荷変動で瞬間的に電圧が不足すると、GPU がハングしやすくなります。
有効だった対処はシンプルで、アンダーボルトを弱める／いったん標準に戻すことです。まずは“完全に定格”で安定するかを見て、安定した後に必要なら段階的に調整するのが安全です。
アンダーボルトを疑うべきサイン
- ゲームごとに落ち方が違い、起動直後〜1時間など発生タイミングがばらつく
- ベンチや軽いゲームは平気でも、Unreal/Unity のゲームで落ちる
- 落ちる直前に GPU 使用率やクロックが“ストン”と落ち、TDR が出る
- GPU 温度は高くないのに落ちる（冷えているのに不安定）
戻し方の実務（よくあるツール別）
環境によって使っているツールが違うので、該当するものだけ実施してください。
- MSI Afterburner：設定リセット（初期値）→ プロファイル自動適用をオフ → Windows 起動時の自動起動も一旦オフ
- GPUメーカー純正ツール（例：ASUS GPU Tweak、GIGABYTE Control Center など）：OC/UV プロファイルを標準へ
- NVIDIA アプリ/コントロールパネル：グローバル設定を既定へ（無理に電力最適化・フレーム制限を強くしない）
次に、同じゲームで 30〜60分程度、普段落ちやすい状況（ローディング、街中、戦闘、重いセーブデータなど）を再現し、イベントログに nvlddmkm が出ないか確認します。ここで安定するなら、Windows 初期化ではなく GPU 設定の問題だった可能性が高いです。
切り分けを最短化するチェックリスト
あれこれ同時に触ると原因が分からなくなるので、「1回に1項目だけ」を基本に進めます。下の表は、実務で迷いにくい優先順です。
| 優先 | 切り分け/対処 | 目的 | 確認方法 | 注意点 |
|---|---|---|---|---|
| 高 | GPU を完全定格へ（OC/UV 無効化） | 不安定設定の除外 | 同一ゲームを再現条件でプレイし、nvlddmkm が消えるか | プロファイルの自動適用が残っていないか注意 |
| 高 | 温度（コア/ホットスポット/VRAM）監視 | 過熱起因のハング除外 | プレイ中の最大値をログ化（HWiNFO 等） | 「平均温度」ではなくピークを見る |
| 高 | PCIe 補助電源の配線確認 | 瞬間的な電圧降下/瞬断の除外 | 可能なら PSU から別系統ケーブルで接続、コネクタの刺さり確認 | 分岐（デイジーチェーン）より別系統が無難 |
| 中 | ドライバーのクリーンインストール | 破損・競合・残骸の排除 | DDU 等で削除 → 再インストール | 一度で直らないなら別バージョンも試す |
| 中 | オーバーレイ/録画/監視ツールを停止 | 描画フック競合の除外 | Discord/Steam/GeForce/RTSS などをオフ | 完全終了しないと残るものがある |
| 中 | BIOS・チップセット更新 | PCIe/電源管理の不具合回避 | マザボ公式の手順で更新 | 更新中の停電リスク対策は必須 |
| 低 | TDR 関連レジストリ調整 | 復旧猶予を延ばすワークアラウンド | TdrDelay 等を設定して挙動を見る | 根本原因を隠す可能性がある |
| 低 | Windows 初期化 | OS 側の破損・汚れの排除 | 定格・配線・ドライバーでも改善しない場合に検討 | 時間がかかる割にハード起因なら再発する |
温度チェックのコツ：見るべきは「GPUコア」だけではない
GPU 周りの温度は、単に「GPU 温度が80℃以下だから大丈夫」とは言い切れません。TDR を伴うクラッシュでは、ホットスポット（Hot Spot）や VRAM 温度が悪さをしていることもあります。
- GPUコア温度：全体の目安。高すぎると保護動作や不安定化のきっかけになる
- GPUホットスポット：局所的な過熱。コア温度が低めでも、ホットスポットだけ高いことがある
- VRAM（メモリ）温度：テクスチャや高解像度設定で上がりやすい。VRAM の不安定は描画エラーやハングにつながる
監視ツールで「最大値（Max）」を記録し、クラッシュ直前に温度が跳ねていないか確認してください。温度が怪しい場合は、ケース吸排気の見直し、GPU ファンカーブの調整、埃清掃、サーマル劣化（長期使用の場合）など、物理面の改善が効きます。
電源（PSU）と給電の見落としポイント
RTX 3060 Ti クラスでも、ゲーム負荷の変動で電力が瞬間的に増えることがあります。平均消費電力が足りていても、瞬間的な電圧降下で GPU がハング→TDR、という形は珍しくありません。
| チェック項目 | なぜ効くか | 具体的な確認 |
|---|---|---|
| PCIe 補助電源の取り回し | ケーブル1本の分岐で電圧が落ちやすい場合がある | 可能なら PSU から 別系統ケーブルで GPU に接続（8pin×2 の場合は特に） |
| コネクタの刺さり | 半刺しや接触不良で瞬断が起きる | 「カチッ」と固定されているか、異常な熱/変色がないか確認 |
| 延長ケーブル/変換の使用 | 品質次第で抵抗が増え、電圧降下が起きる | 一度外して直結で挙動が変わるかを見る |
| PSU の品質・経年 | 劣化で過渡応答が弱くなるとピークで落ちる | 別 PSU で再現性が消えるか、購入年数が長いなら要注意 |
| 壁コンセント/タップ | タップや共有回路で瞬断が出ることがある | 別口コンセントで検証、タップの交換 |
ドライバーとソフトウェア要因：まず「クリーン」を作る
GPU を定格に戻しても改善しない場合、次はソフト面の“汚れ”を落とします。nvlddmkm が出るからといって必ずしも物理故障とは限らず、ドライバーの残骸や オーバーレイの競合だけで TDR が起きることもあります。
優先度が高い：GPU ドライバーのクリーンインストール
- 可能なら DDU（Display Driver Uninstaller） 等で NVIDIA ドライバーを一度完全削除
- 再起動後に最新版を入れる（または、症状が出始めた時期が明確なら 一つ前/安定版も試す）
- インストール時に「クリーンインストール」を選べる場合は選ぶ
ドライバー更新は「最新＝常に正解」ではありません。特定のゲームや Windows 更新との組み合わせで不具合が出ることもあるため、再現性が消える組み合わせを見つける発想が重要です。
オーバーレイ/バックグラウンドアプリの見直し
クラッシュの瞬間に Discord や iCUE が同時に固まるなら、GPU リセットで巻き込まれている可能性が高いです。まずは“競合しやすいもの”を減らして挙動を見ます。
- Discord：ゲーム内オーバーレイ、ハードウェアアクセラレーションをオフ（検証中だけでも）
- Steam：ゲーム内オーバーレイをオフ（検証中だけでも）
- GeForce Experience / NVIDIA アプリ：録画（ShadowPlay）やオーバーレイをオフ
- RTSS/Afterburner：OSD 表示やフックを止める（設定を戻した上で完全終了）
- iCUE など：照明同期や監視機能の一部が描画と相性問題を起こすことがあるため、検証中は停止
発生時刻を追いやすくする：信頼性モニターとイベントビューアー
「ランダムに落ちる」問題ほど、時系列の整理が効きます。Windows には、クラッシュやハングを日付ごとに見やすくまとめる 信頼性モニターがあります。
- 信頼性モニター：アプリケーションエラーやハードウェアエラーの“まとまり”が見える（ゲーム名、LiveKernelEvent 系、Windows Error Reporting など）
- イベントビューアー：nvlddmkm（TDR）や Kernel-Power 41 など、より低レイヤーのログが追える
手順としては「信頼性モニターで落ちた日時を特定 → その時刻前後をイベントビューアーで掘る」が効率的です。特に TDR が絡むと、ゲーム側のクラッシュログと OS 側の nvlddmkm が 同じ数十秒の範囲に並びやすいので、原因推定がしやすくなります。
ゲーム側でできる“検証用”の設定変更
根本原因が GPU の不安定にある場合でも、ゲーム側の負荷特性を少し変えるだけで「落ちやすさ」が大きく変わることがあります。これは原因の切り分けにも使えます。
| 設定/操作 | 狙い | 期待できる変化 | 読み取れること |
|---|---|---|---|
| FPS 上限（60/90/120 など）を設定 | 瞬間負荷と電力スパイクを抑える | 落ちにくくなる | 給電・電圧・過渡負荷が関与している可能性 |
| フルスクリーン ⇄ ボーダーレス | 表示モード由来の競合を切り分け | 症状が変わることがある | DWM/オーバーレイ/表示周りの影響が疑える |
| DX12 ⇄ DX11（選べる場合） | 描画 API の相性を切り分け | 片方だけ安定する | ドライバー/ゲーム側の API 依存不具合の可能性 |
| レイトレーシング/重いポストエフェクトをオフ | VRAM・演算負荷のピークを抑える | 落ちにくくなる | VRAM 温度やメモリエラー、電力ピークが疑える |
| MOD を全部外す（Cities など） | ゲーム側例外の除外 | 落ち方が変わる/直る | ゲーム側の拡張要因が関与している可能性 |
| ファイル整合性チェック | 破損ファイル・不整合の排除 | クラッシュが減ることがある | ソフト起因の可能性が残る |
ここで重要なのは「設定で落ちなくなった＝ゲームのバグ」と決めつけないことです。例えば FPS 上限で落ちなくなるなら、単に 電力ピークを踏まなくなっただけかもしれません。原因の本丸（UV/給電/温度/ドライバー）を潰すためのヒントとして使うのが正解です。
CPU・メモリ不安定でも TDR に見えることがある
「nvlddmkm だから GPU だけが悪い」と決め打ちするとハマることがあります。例えばメモリ（XMP/DOCP）や CPU の不安定で、ゲーム実行中に内部計算が破綻し、結果として GPU へのコマンドが詰まり、TDR に見えるケースもあります。
| 疑うべき状況 | よくある原因 | 簡易チェック |
|---|---|---|
| GPU を定格に戻しても改善しない／ゲーム以外でも不安定 | メモリ DOCP/XMP、CPU 電圧、PBO、Infinity Fabric 周り | メモリを JEDEC 定格に戻す、PBO をオフにして挙動を見る |
| イベントログに WHEA（ハードウェアエラー）っぽい痕跡がある | CPU/メモリ/PCIe の訂正不能エラー | イベントビューアーで WHEA-Logger を確認 |
| クラッシュがゲームだけでなく、圧縮・動画編集などでも起きる | システム全体の安定性不足 | メモリテスト、CPU ストレス、ストレージ健全性チェック |
Ryzen 5000 系は設定次第で非常に安定しますが、DOCP/XMP の当たり外れや、過度な電圧調整、古い BIOS での相性などが積み重なると、ゲームだけが落ちるように見えることもあります。「GPU を定格へ戻しても直らない」ときは、CPU/メモリ側も“定格へ”戻して確認するのが近道です。
TDR レジストリ調整は「最後の手段」にする
TDR のタイムアウト値を伸ばす設定（例：TdrDelay など）は、症状が軽い場合に「落ちにくくなる」ことがあります。ただし、根本原因（GPU/給電/温度/ドライバー）の不安定さが残ったままだと、別の形で再発したり、フリーズ時間が伸びて逆にストレスが増えることもあります。
そのため、レジストリ調整は次の条件を満たすときだけ検討してください。
- GPU/CPU/メモリを定格へ戻し、給電・温度・ドライバーも見直した
- それでも特定のゲームでだけ TDR が出る
- 再現条件が明確で、設定変更の効果が追える
| 設定名 | 意味（ざっくり） | 期待できる効果 | リスク |
|---|---|---|---|
TdrDelay | GPU 応答待ちの猶予（秒） | 一時的な重い処理での TDR 発動を遅らせる | 根本が不安定だとフリーズ時間が伸びるだけになる |
TdrDdiDelay | ドライバー復旧側の猶予（秒） | 復旧に時間がかかる状況でのワークアラウンド | 同上。症状が悪化して見えることもある |
なお、レジストリ編集はミスると別トラブルの原因になります。実施する場合は、変更前に復元ポイントを作り、変更内容をメモして戻せる状態にしてから行ってください。
ゲーム側のクラッシュログを深掘りしたい場合：ユーザーモードダンプ
「GPU を定格に戻しても落ちる」「他のゲームは平気で、特定タイトルだけ落ちる」など、ゲーム側の原因も疑う段階では、Windows の ユーザーモードダンプ（LocalDumps）を有効にすると、原因究明の材料が増えます。Unreal/Unity のゲームでは、エンジンの例外が出ているのか、デバイスロストが主因なのかで対処が変わるためです。
- ゲームフォルダ内のクラッシュレポート（CrashReportClient）やログを確認
- 必要に応じて LocalDumps を設定し、落ちた瞬間のダンプを採取
- ダンプ解析が難しい場合でも、サポート窓口に提出できる材料になる
ただし、今回のようにイベントログに TDR が明確に出ている場合、まずは GPU 不安定を潰すほうが現実的です。ダンプは「ハード側が問題ないのに落ちる」段階で使うと効率が上がります。
GPUID:700 の意味は？
ログに GPUID:700 のような表記が出ると「700番のGPU？」「何かのエラーコード？」と不安になりますが、ここは落ち着いて解釈するのが重要です。
- Windows の一般的なエラーコードではなく、nvlddmkm（NVIDIA ドライバー）側が出している 内部識別/状態を示す表現として扱うのが安全です。
- 数字の意味（700 が何を指すか）は公開情報が限られ、環境やドライバーバージョンによっても表示が変わり得ます。
- 実務上は、GPUID が何番でも「GPU が応答不能→TDR」という現象のほうが重要で、原因は ドライバー不整合、過熱、給電、OC/UV の不安定などに集約されます。
したがって GPUID の数字を追いかけるより、この記事で紹介しているように 定格化→温度→給電→ドライバーの順で潰していくほうが、解決までの距離は短いです。
Windows の初期化は必要？判断の目安
結論から言うと、今回のように アンダーボルトの見直しで安定するケースもあるため、最初から Windows 初期化に飛ぶ必要はありません。初期化は労力が大きい割に、原因がハード側（GPU/PSU/温度/設定）なら再発します。
| 状況 | 初期化を急がなくて良い理由 | 先にやるべきこと |
|---|---|---|
| nvlddmkm/TDR が出ている | OS より先に GPU の不安定が疑わしい | OC/UV をやめて定格、温度・給電確認、ドライバークリーン |
| 特定のゲームだけ落ちる | ゲーム側の相性や設定が原因のことがある | ゲームの設定を下げる、起動オプション変更、別 API（DX11/DX12） |
| Windows 全体が怪しい（更新失敗、システム破損） | OS 破損が疑われる | 修復（SFC/DISM）、インプレースアップグレード、改善しなければ初期化 |
初期化を検討するのは、少なくとも次をやり切った後がおすすめです。
- GPU/CPU/メモリを定格へ戻しても再発
- 給電・温度・配線を見直しても再発
- ドライバーをクリーンにして、複数バージョンでも再発
- 別ユーザープロファイルでも再発、あるいは OS の破損が強く疑われる
最終的に安定させるための“現実的”な着地点
Unreal/Unity 製ゲームでランダムクラッシュが起きる場合、理想は「最高効率のアンダーボルト」を探すことではなく、まず 長時間安定して遊べる状態を作ることです。その上で、電圧やクロックを触るなら段階的に行い、次のルールを守ると失敗しにくいです。
- 1回に1項目だけ変え、最低でも 30〜60 分は同じ条件で検証する
- 温度・クロック・電圧を記録し、落ちたタイミングの前後を見返せるようにする
- 「省電力化」は、安定してから少しずつ。最初から攻めない
- 再現性が消えたら、いったんそこで止める（“もっと下げられる”は事故の元）
よくある質問（つまずきポイント）
ゲームが落ちた後、数秒で画面が戻るのに Discord だけ固まるのはなぜ？
GPU のリセット（TDR）が入ると、描画デバイスが作り直されます。ゲームはその瞬間にクラッシュすることが多く、Discord などは一見動いていても内部の GPU アクセラレーションが不整合を起こして固まることがあります。検証中は Discord のオーバーレイやハードウェアアクセラレーションを切って挙動を見てください。
ログに \Device\Video3 と出るが、GPU は1枚しかない。3って何？
\Device\VideoX の番号は「GPUが複数ある」ことと必ずしも一致しません。Windows の表示デバイスやドライバー内部の割り当てで番号が付くことがあり、単体GPUでも Video0 以外が出ることがあります。番号そのものより、TDR が起きている事実を重視してください。
Palworld や Cities: Skylines II など Unreal/Unity のゲームだけが落ちる。ゲームのバグ？
ゲーム側の不具合がゼロとは言いませんが、TDR を伴う場合は、ゲームが“原因”というより 不安定な状態を踏み抜く負荷をかけたと捉えるほうが現実的です。同じ PC で複数の Unreal/Unity タイトルが落ちるなら、まずは GPU の安定性（定格化・温度・給電・ドライバー）を疑うのが近道です。
それでも直らないとき：ハード故障（GPU/PSU）を疑う判断ライン
ここまでの対処（定格化・温度・給電・ドライバー・オーバーレイ停止・BIOS/チップセット）をやっても nvlddmkm/TDR が止まらない場合、いよいよ 個体不良や経年劣化も視野に入ります。判断の目安をまとめます。
| 状況 | 疑うべきもの | 追加でできる確認 | 次の一手 |
|---|---|---|---|
| GPU を完全定格・温度も正常なのに、GPU負荷で高確率に TDR | GPU 本体（コア/VRAM） | 別PCで同じGPUを試す／別GPUをこのPCで試す | 保証期間内なら RMA/交換を検討 |
| 高負荷時にブラックアウト→再起動（Kernel-Power 41）が増える | PSU（過渡応答/劣化） | 別PSUで再現性を見る／壁コンセント直結で検証 | 品質の良い PSU へ交換を検討 |
| ゲーム以外（動画・圧縮・軽い3D）でも不安定 | GPU 以外（メモリ/CPU/マザボ） | メモリを定格へ、CPU 設定を標準へ、ストレージ/OS 健全性 | 最小構成での再現確認、パーツ切り分け |
「ゲームだけ落ちる」段階だとソフトっぽく見えますが、TDR を伴う場合はハード寄りの要因が潜んでいることが多いです。逆に、パーツ切り分けができる環境（友人PC、予備GPU/PSU）があるなら、原因特定が一気に進みます。
まとめ：nvlddmkm（Event ID 153/TDR）でやるべきことは「GPUを安定させる」
nvlddmkm（Event ID 153）と TDR が出てゲームが落ちる症状は、Windows が「GPU が固まったので復旧した（または復旧できなかった）」と示している状態です。Kernel-Power 41 はその結果として記録されることが多く、まずは GPU の電圧・クロック・給電・温度・ドライバーを順に潰すのが最短ルートになります。
特に、今回のように 過度なアンダーボルトが引き金になっていたケースでは、設定を戻すだけで劇的に改善します。Windows 初期化は最後の手段に回し、まずは “定格で安定” をゴールに切り分けてみてください。
コメント