Windows 11 自作PCでゲーム中にだけ発生する BSOD（ブルースクリーン）。停止コードが毎回違い、ときに「CLOCK_WATCHDOG_TIMEOUT」が出る――こうした“沼”を、実際の検証と再発防止の観点で抜け出すための手順をまとめました。ドライバー／BIOS／電源管理／ハード健全性の順に、確度の高い処置から具体的に解説します。
症状と検証環境の整理
本記事のケースは次の条件を満たします。あなたの環境に近い場合、再現度の高い手順としてそのまま適用できます。
- OS：Windows 11
- 症状：ゲーム実行中に不定期クラッシュ。初期は Discord 使用時のみ → 現在はあらゆるゲームで発生
- 代表的な停止コード：CLOCK_WATCHDOG_TIMEOUT を中心に、毎回異なるコードが混在
- 既に実施済み：GPU ドライバーを DDU で削除 → 再導入、
sfc /scannowと DISM による整合性チェック - 構成：RTX 3080 Ti / Core i9‑11900K / Gigabyte Z590 AORUS ELITE AX / DDR4‑3200 32GB
- 課題：ミニダンプ解析未経験で原因が特定できない
先に結論（要点のサマリー）
この種の“停止コードが毎回違う”不安定は、ドライバーの混在・破損・互換の揺らぎが第一容疑者です。まずはマザーボード公式配布のドライバーを選択的に再インストール（上書き）することで、ランダムな停止コードの乱発が収束しやすく、今回のケースでも約2週間の安定を得られました。その後に残る CLOCK_WATCHDOG_TIMEOUT は、CPU の割り込み／電源管理（C‑State、SpeedStep/SpeedShift、PL1/PL2 等）に焦点を絞って調整するのが効果的です。
再発防止までの全体フロー
| 段階 | 狙い | 具体策 | 判断基準 |
|---|---|---|---|
| ドライバー健全化 | 停止コードの多発を収束 | マザー公式の Intel RST / Intel LAN / Chipset を上書き導入。GPU は DDU → NVIDIA 公式をクリーン導入 | クラッシュの種類が減る／消える |
| BIOS/ファーム更新 | 旧版による不安定回避 | 最新 BIOS 適用 → 初期化（Load Optimized Defaults）→ XMP/電圧/PL を確認 | POST 安定、温度と電力挙動が妥当 |
| CPU 電源管理チューニング | WATCHDOG の核心に対処 | C‑State / SpeedStep/SpeedShift の一時無効化、電源プラン「高パフォーマンス」、最小/最大プロセッサ状態 100% | ゲーム中の再現がなくなる |
| ハード健全性検査 | 潜在故障の排除 | MemTest86、Intel Processor Diagnostic Tool、OCCT（GPU/PSU） | エラーゼロ／温度・電圧が規定内 |
| 物理切り分け | 最終特定 | 別 GPU / RAM の仮挿し、クリーンインストール後も再発なら M/B or CPU 交換検討 | 部位特定 |
CLOCK_WATCHDOG_TIMEOUT の正体と起きやすい条件
CLOCK_WATCHDOG_TIMEOUT は、ある CPU コアが一定時間内に割り込みへ応答しなかったことを意味します。実体としては「クロック／電源状態の遷移（C‑State）」「過度な電力制御」「BIOS/マイクロコード」「DPC/ISR（遅延処理）を引き起こすドライバー」などが絡みます。ドライバーを掃除しても残る場合、プラットフォーム側（BIOS・電源管理・電力枠）の調整が効きます。
| カテゴリ | 代表例 | 対処の方向性 |
|---|---|---|
| ソフト/ドライバー | GPU/ストレージ/ネットワーク/オーディオ | 公式版へ再インストール、不要コンポーネント排除、署名の確認 |
| 電源管理 | C‑State、SpeedStep/SpeedShift、PL1/PL2、LLC | 一時的に簡素化（無効化・定格化）→ 安定確認 → 段階的復帰 |
| BIOS/マイクロコード | 旧 BIOS、Auto の過剰最適化 | 最新 BIOS、初期化、Auto 設定の“盛りすぎ”を控える |
| 物理要因 | 電源容量・配線、温度、メモリ相性 | PSU レーン分離、発熱源の最適化、XMP/ギア比の見直し |
ミニダンプ解析：最低限ここだけ読む
ミニダンプは「ひとまずどのモジュールが落ち際に関与したか」を示します。100点の解析でなくても十分役立ちます。
- 「Probably caused by」に GPU／Intel LAN／ストレージ等が交互に現れる → ドライバー層の混在・破損の疑い大
- ハード故障の明確な痕跡（WHEA エラーの一貫性や特定コアの繰り返し）がない → まずソフト起因を潰す
- WinDbg の
!analyze -vのほか、lm（読み込みモジュール一覧）で古い日付や署名なしを洗い出す
取得と確認の要点：
- 「システムのプロパティ → 起動と回復」で「小さいメモリダンプ (256KB)」を有効化
- クラッシュ後、
C:\Windows\Minidumpから対象をコピーし、WinDbg（Preview 版を推奨）で開く - 「スタックに同じドライバーが頻出するか」「異なるドライバーが日替わりで出るか」を見極める
今回のケースでは、NVIDIA GPU・Intel LAN・Intel ストレージ（RST）の各ドライバーが交互に原因と記録され、ハード故障の痕跡は乏しい → ソフト（ドライバー）起因と判断しました。
まずは「公式ドライバーの再インストール」から
Windows Update や自動ツールは便利ですが、チップセット／LAN／ストレージはマザー公式の検証済み版が安定しやすいのが実情です。上書き導入でレイヤーを揃えましょう。
| 対象 | 取得元 | 導入の要点 |
|---|---|---|
| Intel Chipset INF | Gigabyte Z590 AORUS ELITE AX サポート | 最初に導入。デバイスの正しいクラス付けで後続ドライバーの当たり所を整える |
| Intel RST（Storage） | 同上（Storage セクション） | VMD/AHCI の構成に合わせて上書き。不要なら RAID 機能を無闇に変えない |
| Intel LAN | 同上（LAN セクション） | Game 時の DPC/ISR を安定させる狙い。省電力機能は後で調整 |
| NVIDIA GPU | NVIDIA 公式 | DDU で完全削除 → カスタム → クリーンインストール。不要コンポーネントを外し最小構成で導入 |
補足：Windows Update によるドライバー自動更新を一時停止すると整合が保ちやすくなります（デバイスのインストール設定で「いいえ」にするか、グループポリシーでドライバーを含めない設定）。
BIOS とメモリ設定の見直し
Z590 世代では、BIOS の自動最適化が“攻め”すぎて不安定を招くことがあります。次の手順で土台を整えます。
- 最新 BIOS を適用 → Load Optimized Defaults で一度初期化
- XMP を有効化（DDR4‑3200）。Rocket Lake では Gear 1 を優先（名称は BIOS により異なる）
- CPU 電力枠（PL1/PL2/Tau）はいったん 定格相当へ。マザー特有の「強化ターボ」系は一時オフ
- LLC（負荷線補償）は Auto または穏やかな設定から
CPU 電源管理：CLOCK_WATCHDOG_TIMEOUT の急所
ドライバーを整えても WATCHDOG が残るなら、電源状態遷移の簡素化で様子を見ます。恒久対処ではなく、原因の切り分け目的です。
| 項目 | 一時設定 | 狙い | 注意 |
|---|---|---|---|
| CPU C‑State | Disabled（無効） | 深い省電力遷移を止めて割り込み応答を安定 | アイドル消費増。安定確認後に段階的復帰 |
| SpeedStep/SpeedShift | Disabled（無効） | 頻繁な周波数変動を抑制 | にぶさの体感が出る場合あり |
| Windows 電源プラン | 高パフォーマンス | OS 側のスリープ傾向を抑制 | ノートでは発熱・消費に注意 |
| 最小/最大プロセッサ状態 | 100% / 100% | クロック固定で遷移を排除 | 試験用。安定後は 5–100% へ戻す |
これで安定するなら、原因は「省電力遷移 × ドライバー/負荷のタイミング」だった可能性が高いです。C‑State を Auto → C1/C3 まで → 深い C6/C7 復帰のように段階的に戻すと、性能と安定のバランスが取れます。
ストレステストで“物理”を切り分ける
ソフトで整っても不安が残る場合、テストで裏を取るのが最短です。
| ツール | 対象 | 所要 | 合格目安 |
|---|---|---|---|
| MemTest86（USB ブート） | RAM | 4 パス以上 | エラー 0、温度正常 |
| Intel Processor Diagnostic Tool | CPU | 標準/ストレス | 全テスト PASS、サーマルスロットリングなし |
| OCCT（GPU/電源） | GPU・PSU | 30–60 分 | クラッシュ/エラー 0、12V 変動が過大でない |
RTX 3080 Ti + i9‑11900K は負荷ピークが鋭く、電源ユニットの瞬間的な電流供給能力が重要です。GPU 8pin ケーブルは PSU から別系統で 2–3 本を個別に取り、デイジーチェーンを避けると安定します。
配線・熱設計の見直しポイント
- CPU クーラーの装着圧・ペースト塗布・背面プレートのたわみを点検
- ケース気流：フロント吸気 → リア/トップ排気。GPU 真下のケーブル密集を避ける
- VRM ヒートシンク周りに直接風が当たるようファン配置を再考
- アイドルとゲーム時の CPU/GPU 温度ログを保存（後述のロガー設定）
“ランダム BSOD”が収束した理由
今回、ミニダンプで GPU / LAN / ストレージ が順繰りに疑われたのは、複数のドライバーが同時期に更新され、互換の境界線上にいたことが主因です。マザー公式の検証済みドライバーで層を揃えたことで、DPC/ISR と IRQL まわりの不安定が減り、停止コードの種類が収束しました。これは「ハード故障ではないが、OS 層が瓦解している」時に典型的に見られる挙動です。
Windows 側の追加チューニング
- 信頼性モニター（
perfmon /rel）でクラッシュの発生日と更新履歴を照合 - イベント ビューアー：Windows ログ > システムで WHEA‑Logger、イベント ID 18/19/141、Kernel‑Power 41 を重点確認
- 高速スタートアップは一時無効化（起動時の電源状態復元を避ける目的）
- GPU スケジューリング（HAGS）は一時オフで相性を確認
Discord × ゲームで落ちやすいときの視点
音声・映像の同時処理は DPC/ISR を増やし、LAN／オーディオ／GPUのドライバー競合を露呈させます。以下を試してください。
- LAN ドライバーの省電力機能（省電力イーサネット等）をオフ
- オーディオデバイスを使用するものだけ有効化、仮想デバイスを整理
- NVIDIA ドライバーは最小構成（Graphics Driver + PhysX）で導入
ロギング環境を用意する（再発時の証拠取り）
原因が複合的なときは発生前後 5 分の実測が決定打になります。
- HWiNFO で CPU/GPU 温度・クロック・電圧・電力を 1s 間隔でログ保存
- イベント ビューアーのカスタムビューに WHEA と Kernel‑Power を集約
- 再発時刻とログを突き合わせ、電圧が落ちていないか／温度が急騰していないかを確認
Driver Verifier は“最後のカード”
ドライバーの不正挙動を強制検出する Driver Verifier は有効ですが、誤設定で起動不能になるリスクがあるため、以下の安全手順で。
- 復元ポイントを作成し、回復ドライブを用意
- 管理者コマンドで
verifierを起動 → 標準設定 → サードパーティドライバーのみを指定 - 数時間〜1日運用して BSOD が出るか確認（出たらダンプで該当ドライバーを更新/削除）
- 終了時は
verifier /resetで必ず無効化
ケースの時系列（実測ベース）
- Day 0：Discord 併用時のみ BSOD
- Day 3：どのゲームでも発生、停止コードが毎回違う
- Step 1：マザー公式の Intel RST / LAN / Chipset を上書き。GPU は DDU → クリーン導入
- 結果：約 2 週間は安定。ランダムな停止コードは収束
- 再発：CLOCK_WATCHDOG_TIMEOUT のみ再発
- Step 2：BIOS 更新・初期化、C‑State/SpeedStep/SpeedShift を一時無効、電源プラン固定
- 次の焦点：CPU/マザー周辺（電源管理・PL・LLC）の微調整
チェックリスト（保存版）
- Windows：
sfc /scannow→DISM /Online /Cleanup-Image /RestoreHealth→ 再起動 - マザー公式：Chipset → RST → LAN の順に上書き導入
- NVIDIA：DDU（セーフモード）→ 公式ドライバーをクリーンインストール（最小構成）
- BIOS：最新化 → 初期化 → XMP（DDR4‑3200、できれば Gear 1）→ PL/LLC は穏やかに
- 電源管理：C‑State/SpeedStep/SpeedShift を一時オフ、電源プラン「高パフォーマンス」でクロック固定
- 温度・配線：CPU/GPU 温度監視、PSU から GPU へ別レーンで 2–3 本配線
- 健全性：MemTest86、IPDT、OCCT で異常ゼロを確認
- 再発時：HWiNFO ログ＋イベント ビューアーで時系列を突き合わせ
- 最終手段：Driver Verifier（サードパーティのみ、実施後は
verifier /reset）
具体的な設定例（Gigabyte Z590 AORUS ELITE AX）
BIOS の表記は版により異なりますが、概ね以下の階層にあります。
| メニュー | 設定項目 | テスト用推奨 | 備考 |
|---|---|---|---|
| Tweaker / Advanced CPU Settings | Intel SpeedStep / Intel Speed Shift | Disabled | 切り分け後に Enabled へ段階復帰 |
| Advanced CPU Settings | CPU C States | Disabled | 安定後に Auto → C1/C3… と戻す |
| Tweaker | Load-Line Calibration | Auto または Low | 過度な LLC は突発電圧を誘発 |
| Tweaker | CPU Power Limits (PL1/PL2) | 定格相当 | 一時的に強化設定を外す |
| Settings > IO Ports | Re-Size BAR Support | Enabled/Auto | 通常は安定。相性時は一時 Off |
| Save & Exit | Load Optimized Defaults | 実施 | 更新直後は必ず初期化 |
ネットワーク・オーディオの安定化 Tips
- Intel LAN プロパティ → 詳細設定 → 省電力/省電力イーサネットを無効化
- 割り込みの大量発生を抑えるため、不要な仮想アダプタ（VPN、仮想スイッチ）を一時無効化
- オーディオは使用デバイスのみ有効にしてドライバーを最小構成へ
Windows 電源プランをコマンドで切り替える
GUI より確実に適用したい場合はコマンドが便利です。
powercfg -list
powercfg -setactive SCHEME_MIN <!-- 高パフォーマンス -->
試験が終わったら バランス等へ戻すことも忘れずに。
ストレージ周りの注意（RST と VMD）
インテル RST を使う構成では、VMD の有効/無効を途中で切り替えないのが原則です。ブート方法が変わると起動不能のリスクがあるため、現状維持で上書きを徹底します。NVMe のファーム更新は副作用になりにくいので、ツールが対応していれば適用しておくとよいでしょう。
なぜ「再インストール」が効くのか（技術的背景）
Windows のドライバーは INF によりデバイスクラスや拡張機能が定義されます。Chipset → Storage → LAN → GPU の順で層が正しく構成されると、DPC/ISR の割り込み経路が安定し、IRQL_NOT_LESS_OR_EQUAL のような別系統 BSOD まで巻き添えで減ります。逆に、異なる配布元の INF が混在すると、タイムスタンプや署名、サブコンポーネントの優先順位で思わぬ組み合わせが成立し、再現性の低いクラッシュにつながりがちです。
再発時の最短復旧手順（実運用向け）
- HWiNFO ログとイベント ビューアーで再発時刻を特定
- 直近で導入/更新したドライバーを巻き戻すか、上書き再インストール
- 電源プランを「高パフォーマンス」、最小/最大プロセッサ 100%
- LAN 省電力を無効、Discord と同時使用のオーディオデバイスを整理
- 改善がない場合は C‑State/SpeedStep/SpeedShift を一時無効 → 安定確認 → 段階復帰
よくある質問
ゲームごとに落ち方が違う。ソフト側の問題？
ゲーム固有のバグが引き金でも、OS 層が健全なら BSOD には至りません。まずはドライバーと BIOS の整合を優先して整えましょう。
オーバークロックは完全に禁止？
切り分け中は 禁止。XMP も疑わしいときは JEDEC に落として検証します。安定確認後に段階復帰がセオリーです。
電源ユニットの容量はどれくらい必要？
品質にもよりますが、RTX 3080 Ti + 8 コア級 CPUなら 850W クラスが目安。瞬間電流への追従力（レギュレーション、保護回路の閾値）が重要で、配線（別レーン）の方が効く場合も多いです。
まとめ
- 停止コードが毎回違う乱発はドライバーの再インストール（公式配布）が特効薬になりやすい
- それでも残る CLOCK_WATCHDOG_TIMEOUT は、CPU の電源管理（C‑State/SpeedStep/SpeedShift）と BIOS の定格化で収束を狙う
- テストとロギングで「物理」を裏取りし、再発時は証拠ベースで一点ずつ潰す
今回の手順（実績付き）
| 手順 | 内容 | 目的 |
|---|---|---|
| ミニダンプ解析結果 | NVIDIA GPU、Intel LAN、Intel ストレージ（RST）が交互に原因と記録。ハード故障の痕跡なし | ソフト（ドライバー）起因と判断 |
| 公式ドライバーの再インストール | Gigabyte サポートから Intel RST（Storage）、Intel LAN、Chipset を上書き導入 | Windows Update 版より安定した組み合わせを採用 |
| GPU ドライバーのクリーン導入 | DDU → NVIDIA 公式最新版をクリーンインストール | 旧設定や破損ファイルの排除 |
| BIOS・ファーム更新 | Z590 ボードを最新化し、初期化後に XMP/電圧/PL を確認 | 旧 BIOS や攻め設定の副作用を解消 |
| ハード健全性チェック | MemTest86、IPDT、OCCT（GPU/PSU） | 潜在的な物理故障の検出 |
| 電源管理の見直し | C‑State、SpeedStep/SpeedShift を一時無効化。電源プラン「高パフォーマンス」、最小/最大 100% | 割り込み応答のタイムアウトを回避 |
| 追加切り分け | 別 GPU／別 RAM で再現性を確認。クリーンインストール後も再発なら M/B または CPU を交換検討 | 部位の特定 |
現在の状況と効果（ケース報告）
- ドライバーを公式版で再インストール後、約 2 週間は安定
- その後 CLOCK_WATCHDOG_TIMEOUT が再発 → CPU 電源管理/BIOS 側の調整が焦点に
- ランダムに異なる停止コードは収束 → ドライバー依存のクラッシュは解消したと判断
以上の手順を上から順に実践すれば、無用な OS 再インストールに頼らず、根本的な安定化へ到達できます。とくに「公式ドライバーへ層を揃える」「BIOS を定格に寄せる」「電源遷移を簡素化する」の3点が、実務上もっとも効く処方箋です。
コメント