AMD製GPU環境で「ゲームが急にカクつく（スタッター）」「Radeonドライバーがクラッシュして復帰する」「ついにはBSOD（ダンプ生成）」「復帰の瞬間に緑の線が走る／表示が崩れる」――この一連の症状は、原因がドライバーにもハードにもまたがりやすく、切り分けの順番が重要です。本記事では、LiveKernelEvent 117/141やTDRを軸に、ダンプ解析の見どころと、再現性を作りながら原因を絞る実践的な手順をまとめます。
まず押さえる：今回の症状は「TDR（タイムアウト→復帰）」の典型パターン
AMD GPU環境でドライバークラッシュやBSODが絡むケースの多くは、Windowsの仕組みであるTDR（Timeout Detection and Recovery）が関係します。TDRは、GPU/ドライバーが一定時間応答しないと「固まった」と判断してリセット（復帰）を試みる機構です。
重要なのは、TDRはドライバー不具合でも、ハード不安定（GPU/VRAM/電源/冷却/PCIe/メモリ）でも起きるという点です。さらに、復帰時にフレームバッファや表示パイプラインが乱れると、緑線・ちらつき・ブロックノイズなど“アーティファクト疑い”の見え方になります。
| 症状 | よくある状態 | まず見るべきポイント | 優先度 |
|---|---|---|---|
| ゲームだけカクつく（スタッター） | 負荷変動、シェーダーコンパイル、I/O、バックグラウンド、ドライバー設定 | 発生タイミング（初回だけ／常時／特定シーン）、フレームタイム | 中 |
| ドライバーが落ちて復帰する | TDRでGPUをリセット | 信頼性モニター（117/141等）、イベントビューア、発生頻度 | 高 |
| BSOD（ダンプ生成） | TDR失敗、ドライバー致命的エラー、周辺要因（メモリ/電源） | バグチェックコード、原因モジュール、同時刻のWHEA | 最優先 |
| 復帰時に緑線・表示乱れ | 表示パイプライン/VRAM/ケーブル/モニターの不安定、もしくはTDR直後の破綻 | 定格でも再現するか、別ケーブル/別表示器で変わるか | 最優先 |
117 / 141 は何者か：信頼性モニターの「LiveKernelEvent」を読み解く
Windowsの「信頼性モニター（Reliability Monitor）」に出るLiveKernelEvent 117 / 141は、ユーザーの体感と紐づけやすい重要な手掛かりです。多くの環境で、これらは「GPU処理がタイムアウトした」「GPUエンジンが応答しない」といった系統のイベントとして現れます。
確認手順は次の通りです。
- スタートメニューで「信頼性」と検索 → 「信頼性履歴の表示」
- クラッシュした日付をクリック → 「ハードウェア エラー」や「Windowsエラー」の詳細を見る
- 「問題イベント名：LiveKernelEvent」「コード：117/141」などを控える
| 表示されるもの | 意味合い（ざっくり） | 体感症状 | 次にやるべき切り分け |
|---|---|---|---|
| LiveKernelEvent 117 | GPU/ドライバーが応答しない（TDR系のタイムアウト） | 一瞬フリーズ→復帰、ゲーム落ち、画面が一瞬暗転 | ドライバー版の相性、OC/UVの有無、温度、電源、DX設定 |
| LiveKernelEvent 141 | GPUエンジン側のタイムアウト（回復を試みる） | ドライバー復帰、アプリだけ落ちる、復帰後に描画が乱れることも | 定格化、ケーブル/モニター切替、PCIe Gen変更、電源配線の見直し |
| BSOD（例：VIDEO_TDR_FAILURE系） | TDR回復に失敗、または致命的エラー | ブルースクリーン→再起動、ダンプが残る | ダンプ解析＋ハード起因の除外（PSU/メモリ/温度/別GPU） |
ここで大事なのは、117/141が出た＝即GPU故障と断定できない一方で、緑線やブロックノイズなど“表示の乱れ”が絡むとハード寄りの可能性が上がる、という現実です。だからこそ、闇雲に設定をいじるよりも、後述の「順番」と「証拠の残し方」が効きます。
ダンプファイル解析で分かること／分からないこと
BSODでダンプ（minidump / memory dump）が残っているなら、解析は「方向性」を掴むのに役立ちます。ただし、GPU系のクラッシュはスタックが複雑で、“原因がドライバーに見えても、根っこは電源やVRAM不安定”ということが普通にあります。
ダンプの場所と種類
- ミニダンプ：
C:\Windows\Minidump\に.dmpが複数残ることが多い - メモリダンプ：
C:\Windows\MEMORY.DMP（サイズが大きい）
WinDbgでの最低限の見方（迷わない版）
ダンプ解析は最終的に専門的になりますが、切り分け目的なら「ここだけ押さえる」で十分です。
- WinDbg（Preview）を用意する（Microsoft Store版でも可）
- WinDbgで
.dmpを開く - シンボル設定（一般的には以下が定番）
srv*C:\Symbols*https://msdl.microsoft.com/download/symbols続けて、まずはこれだけ実行します。
!analyze -v| 見る項目 | 意味 | 読み方（GPU/TDRのとき） |
|---|---|---|
| BugCheck（バグチェックコード） | BSODの種類 | VIDEO_TDR系やGPU/DirectX周りが出るとTDRラインが濃厚 |
| MODULE_NAME / IMAGE_NAME | 原因として挙がったモジュール | AMDのカーネルドライバー名、dxgkrnl、DirectX系が出ることが多い |
| STACK_TEXT | 落ちた瞬間の呼び出し履歴 | DirectX処理中にTDRへ移行した流れが見えることがある |
| PROCESS_NAME | 落ちたときに動いていたプロセス | 特定ゲーム名なら再現条件のヒント（ただしゲームが悪いとは限らない） |
解析結果で「AMDドライバー名」や「DirectX/graphics kernel」が目立つ場合、結論はこうなります。
- 方向性：「GPUドライバーが応答しなくなり、タイムアウトして落ちた（TDR系）」
- ただし：それがドライバーの欠陥なのか、ハードが不安定でドライバーが巻き込まれたのかは別問題
つまり、ダンプ解析は「犯人を断定」よりも、切り分けの優先順位を正す用途が向いています。
切り分けの鉄則：再現性が弱いほど「変数を減らす」
今回のように「2〜3か月続く」「頻度が波打つ」「OS再インストールも済み」だと、環境側の変数が増えがちです。そこで鉄則は以下です。
- 同時に複数のことを変えない（ドライバーとOC設定とWindows設定を一気に変えると、何が効いたか分からない）
- まず“完全に定格”を作る（工場OC・手動OC・アンダーボルト・電力制限・メモリOCもいったん停止）
- 1つの変更ごとに、同じ負荷で再現チェック（同じゲームの同じシーン、同じベンチ、同じ時間）
特に、Sapphire Nitro+ 6950 XTのような工場出荷時OCモデルは、個体差や経年、電源・温度条件で「以前は通っていたが最近ギリギリになった」状態が起こり得ます。“常時OCじゃない”としても、ドライバー復帰や緑線が出るなら、まず定格へ戻して土台を作るのが最短です。
ドライバー対処の現実解：ロールバック→クリーン→別経路の順で検証する
すでに「削除→再インストール」「OS再インストール」「チップセット再導入」をしている場合でも、ドライバー周りはまだ“検証の余地”が残ることがあります。ポイントは“クリーンの質”と“入れ替えパターン”です。
ロールバックが効くケース
症状が「ここ2〜3か月で増えた」なら、その間に以下が起きている可能性があります。
- Adrenalinドライバーの世代更新・機能追加で相性が出た
- Windowsの更新（グラフィックス周り、セキュリティ機能、表示機構）が入った
- ゲーム側が大型アップデートし、特定API（DX12など）負荷が変化した
この場合、最短は最後に安定していた版へ戻すことです。「新しい＝正しい」ではありません。
クリーンインストールの“再現性が高い”手順
| 手順 | やること | 狙い | 注意点 |
|---|---|---|---|
| 準備 | インストールしたいAMDドライバーを事前にダウンロード | ネット遮断でも入れられる | Optionalより安定版（WHQL相当）を優先 |
| 削除 | DDU等でグラフィックスドライバーを徹底除去（セーフモード推奨） | 残骸・設定の引き継ぎを断つ | Windows Updateが勝手に入れないよう一時的にネットを切ると確実 |
| 検証A | Windows Update経由で入るドライバーで一度テスト | “別ルート・別構成”で差を見る | 古い版のこともあるが、安定検証には有効 |
| 検証B | AMD公式ドライバー（フル/ミニマル）を入れてテスト | 機能差・設定差を切り分ける | まずは設定リセット＋標準状態で試す |
Radeon側の設定で“まず切るべき”候補
スタッターや復帰後の乱れが絡む場合、Radeonの機能がトリガーになることがあります。検証の基本は「余計な補正をゼロにする」です。
- Enhanced Sync / 垂直同期周り（組み合わせで破綻することがある）
- Anti-Lag / Boost / Chill など負荷やフレーム制御に触る機能
- オーバーレイ系（録画、メトリクス表示、外部のFPS表示ツール）
- モニター側の可変リフレッシュ（FreeSync）を一時的にOFFにして比較
ここでのコツは「OFFにしたら快適になった＝それが悪」ではなく、ON/OFFで再現性が動く＝原因領域が絞れる、という使い方をすることです。
緑の線・アーティファクト疑い：ドライバー不具合にもハード不安定にも見える
表示の乱れは、経験的にハード寄りの疑いが強くなるシグナルです。ただし、TDR復帰直後の一瞬だけ発生する乱れは、“原因そのもの”ではなく“復帰の副作用”であることもあります。そこで、見え方で整理します。
| 見え方 | 起きやすいタイミング | 疑う方向 | まずやる確認 |
|---|---|---|---|
| 緑の線が走る／一瞬のちらつき | ドライバー復帰直後、Alt+Tab直後 | 表示パイプラインの復帰不整合、MPO/VRR、ケーブル | 別ケーブル・別ポート、リフレッシュレート固定、VRR一時OFF |
| ブロックノイズ、カラフルな点、テクスチャが崩れる | 高負荷時、温度上昇時、長時間プレイ | VRAM不安定（OC/温度/個体）、電源瞬断寄り | 完全定格、温度ログ、電力制限（下げる）で変化するか |
| 黒画面→復帰、たまにそのまま戻らない | 負荷急変（ロード、解像度変更、動画再生） | TDR、電源、ドライバー、ディスプレイ相性 | 別モニター、別入力、PSU配線見直し、ドライバー版変更 |
| デスクトップでも乱れる | アイドル〜軽負荷でも | ハード/ケーブル/モニター寄りが濃厚 | ケーブル・モニター交換、iGPU/別GPUで比較 |
判断の分かれ目はここです。
- 定格・別ドライバー・別ケーブルでもアーティファクトが再現する → ハード不安定の可能性が上がる
- 特定の機能（VRR/オーバーレイ/特定API）を切ると激減する → ソフト/設定相性の可能性が上がる
ハード面の基本チェック：6950 XTクラスは「電源と配線」が最優先
Radeon RX 6950 XTは高負荷時の消費電力が大きく、瞬間的な電力変動（トランジェント）も起きやすいクラスです。TDRや141系が出るとき、体感より多い原因がPSU（電源）・補助電源ケーブル・温度・ケースエアフローです。
| チェック項目 | 見落としがちなポイント | おすすめの検証 | 効果が出やすい順 |
|---|---|---|---|
| 補助電源ケーブル | 分岐（だいしん）で1本を2口にしている | 8pinはできるだけ別系統のケーブルで（PSU側も別口が理想） | 最優先 |
| PSU容量・品質 | 容量は足りていても、経年や品質で負荷変動に弱い | 可能なら別PSUで比較、または電力制限を下げて再現が減るか | 最優先 |
| 温度（GPU Hotspot/VRAM） | GPU温度は低いのにHotspotだけ高いことがある | ログを取り、クラッシュ直前のHotspot/VRAM温度を見る | 高 |
| 工場OC/手動OC/UV | “以前は平気”でも、条件が変わると不安定化 | 完全定格に戻す（電力制限・カーブ・VRAMもデフォルト） | 高 |
| PCIe信号 | Gen4環境で相性が出ることが稀にある | BIOSでPCIeをGen3固定にして比較（診断目的） | 中 |
| メモリ（XMP/EXPO） | メモリ不安定がGPUクラッシュに見えることがある | XMP/EXPOを切って安定性を見る | 中 |
特に「RMAで異常なし」と返ってきた個体でも、あなたの環境の電源・温度・PCIe・メモリの組み合わせでだけ再現することがあります。だからこそ、ハードチェックは“疑う”ではなく“除外する”作業として行うと、結果が強い証拠になります。
スタッター対策は「TDRと無関係なカクつき」を先に除外すると早い
スタッターはGPU不具合の印象が強い一方で、実際には原因が分散します。TDRやクラッシュと混ざると判断が難しくなるため、スタッターだけの原因も併走して潰すと効率が上がります。
| スタッターのタイプ | 特徴 | 主な原因 | 効くことが多い対策 |
|---|---|---|---|
| 初回だけガクッとする | 同じ場所でも初回は重いが、2回目以降は軽い | シェーダーコンパイル、キャッシュ生成 | ゲーム内キャッシュ生成の待機、ドライバーキャッシュ削除の乱用を避ける |
| 周期的にカクつく | 一定間隔でフレームが落ちる | バックグラウンド常駐、録画/オーバーレイ、スケジュールタスク | クリーンブート検証、オーバーレイ無効、不要常駐の停止 |
| 戦闘や爆発など負荷でガクガク | 高負荷時に悪化 | GPU/CPUボトルネック、温度スロットリング、電源 | 温度ログ、電力制限（下げる）で安定化するか、設定で負荷を下げる |
| 描画が乱れた直後にカクつく | 復帰後にしばらく重い | TDR復帰で内部状態が崩れた | まずTDR原因の切り分け（定格、ドライバー版、電源）を優先 |
おすすめは、ゲーム中の平均FPSではなくフレームタイム（1フレームにかかる時間のばらつき）を見ることです。平均FPSが高くても、フレームタイムが跳ねると体感はカクつきます。ログが取れるツールを使う場合は、クラッシュ直前の温度・消費電力・クロックも一緒に残すと、TDRとの関連が見えやすくなります。
再現性を作る：負荷テストは「目的別」に使い分ける
「たまに落ちる」「特定ゲームだけ」といった状況では、負荷テストで再現性が取れると切り分けが一気に進みます。ただし、闇雲にストレステストを回すのではなく、何を証明したいかを決めるのがコツです。
| テストの目的 | 向いている負荷 | 見たい結果 | 判断の例 |
|---|---|---|---|
| GPU定格で安定するか | 一定負荷を長時間（同条件） | 141/117が出ない、温度が暴れない | 定格で落ちるならハード/電源/冷却の疑いが上がる |
| 電源/配線が弱いか | 負荷の上下が激しい場面、ロードの繰り返し | 瞬間的なブラックアウトやリセット | 電力制限を下げると改善 → 電源/供給の疑いが濃い |
| VRAM不安定か | 高解像度・高テクスチャ・VRAM使用量多め | アーティファクト、テクスチャ崩れ | VRAM関連の乱れが出る → メモリ/温度/個体の疑い |
| ゲーム固有か | 複数ゲーム・複数API（DX11/DX12/Vulkan）で比較 | 特定条件でのみ再現 | DX12だけ落ちる等 → ドライバー相性や設定の糸口 |
重要なのは、テスト中にログを取ることです。温度・クロック・消費電力・ホットスポットの推移が残ると、RMAやサポート相談時に「その場の印象」ではなく「再現条件」として説明できます。
それでも原因が割れないときに効く“差分テスト”
OS再インストールまで済んでいる場合、残るのは「環境差分」の検証です。全部やる必要はありませんが、1つでも差分が取れると一気に進展します。
- 別GPUを挿す（可能なら最強の切り分け。問題が消えるなら6950 XT側が濃厚）
- 別PCに6950 XTを挿す（別環境で同様に出るならGPU/ドライバーの疑いが一気に上がる）
- 別PSUで比較（同容量でも品質差が出る。瞬間負荷が弱い個体はTDRを誘発しやすい）
- 別モニター/別ケーブル（緑線・乱れが「表示系」由来のケースを除外できる）
- PCIe Gen3固定（診断目的。改善するなら信号品質・マザー側・相性の線が出る）
- XMP/EXPO OFF（メモリ不安定がGPUクラッシュに見えるケースを除外）
「RMAで異常なし」と言われた後に症状が増えた体感がある場合でも、差分テストで“再現する条件”を作れれば、次のRMAやサポート相談の説得力が段違いになります。
サポートに通る“証跡パック”の作り方（RMA再トライの成功率が上がる）
GPU系トラブルは、サポート窓口が「再現しない＝異常なし」で返してくることが珍しくありません。だからこそ、提出物を“相手が判断できる形”に揃えるのが現実的です。
| 用意するもの | 内容 | なぜ効くか | コツ |
|---|---|---|---|
| ダンプ（Minidump/MEMORY.DMP） | BSOD時の.dmp | 少なくともTDR系かどうかの方向が出る | 発生日時とセットで管理 |
| 信頼性モニターのスクショ | 117/141の詳細画面 | ユーザー体感とOS側記録が一致する | 頻度が見えるように期間表示を広めに |
| アーティファクトの動画/写真 | 緑線・乱れが分かる録画 | “主観”から“証拠”になる | 復帰の瞬間が撮れると強い |
| ログ（温度/電力/クロック） | クラッシュ直前までの推移 | 熱・電源の疑いを議論できる | 定格でのログが最も価値が高い |
| 実施済み対策の一覧 | OS再インストール、DDU、ロールバック、定格化など | “やれることはやった”が伝わる | 箇条書きで簡潔に |
提出文の例（この粒度で十分です）。
- GPU：Sapphire Nitro+ RX 6950 XT（工場OCモデル）
- 症状：ゲーム中にスタッター→ドライバークラッシュ（復帰時に緑線）→稀にBSOD（ダンプあり）
- 発生頻度：週◯回／特定ゲームで増える／直近2〜3か月で増加
- 発生条件：OC/UVなしの定格でも再現（または“定格では未検証”なら検証結果を書く）
- 試したこと：OS再インストール、チップセット再導入、DDUでクリーン、ドライバー版の変更、VRR/オーバーレイOFF 等
- 添付：ダンプ、117/141の画面、緑線の動画、温度ログ
また、Windows側への報告としてはFeedback Hub（フィードバック ハブ）にログを付けて送るのも有効です。特に、ベンダー側が「ソフト起因かもしれない」と判断する場合でも、OS側のログ提出は交渉材料になります。
“やってはいけない対処”と“一時回避”の正しい使い方
GPUトラブルでありがちな落とし穴は、根本原因が残ったまま「症状だけ隠す」方向に寄ってしまうことです。
推奨しにくい（または診断目的に限定すべき）例
- TDR遅延（TdrDelay等）のレジストリ調整：一時的に回避できることがあるが、根本解決ではない。診断目的で短期間に限定するのが安全
- OC/UVを“勘”で弄る：たまたま直ったように見えても再発しやすい。まず定格で基準を作る
- ドライバーを短期間で何度も入れ替える：検証条件が崩れて原因が分からなくなる
一時回避として現実的な例（切り分けにも使える）
- GPUを完全定格（工場OCモデルでも「とにかく標準」に寄せる）
- 電力制限を少し下げる（落ちやすさが改善するなら電源/供給面の疑いが濃くなる）
- VRR/Enhanced Sync/オーバーレイをOFF（復帰後の乱れやスタッターが動くなら相性の糸口）
- 別ケーブル・別モニター（緑線が消えるなら表示系の切り分けが一気に進む）
まとめ：最短で結論に近づくための手順
最後に、今回の症状（スタッター＋ドライバークラッシュ＋BSOD＋緑線）で、現実的に“最短ルート”になりやすい流れを整理します。
- 信頼性モニターで117/141の出方を確認し、発生日時を控える
- BSODダンプはWinDbgで !analyze -v、TDR系かどうかの方向性を掴む
- 工場OC/手動OC/UVをやめて完全定格に戻し、同条件で再現チェック
- ドライバーはロールバック→DDUクリーン→別経路（Windows Update）の順で差を見る
- 電源配線（分岐なし）とPSU品質、温度（Hotspot/VRAM）を最優先で点検する
- 緑線やアーティファクトが定格でも出るなら、証拠を揃えてRMA/サポートへ強くエスカレーション
「ドライバー不具合か、GPU故障か」を一発で断定するのは難しい一方、順番を守って“差分”を作ると、原因は驚くほど絞れます。特に、緑線などの表示乱れが絡む場合は、ソフトだけでは説明しきれないケースも多いため、定格での再現性と証拠の確保を最優先に進めてください。
コメント