「動画やゲーム中は平気なのに、席を外して戻るとだけフリーズ／ブルースクリーン（DPC_WATCHDOG_VIOLATION 0x133）になる…」という現象は、Windows 11 と省電力制御、ドライバー／BIOS の相性が重なったときによく起こります。本記事では、アイドル時だけ発生する 0x133 を狙い撃ちで改善するための、現場レベルのチェックポイントと具体的な設定例を詳しく解説します。
Windows 11 で「アイドル時だけ」DPC_WATCHDOG_VIOLATION が出る症状
今回のケースの特徴を整理すると、次のようになります。
- OS：主に Windows 11
- バグチェック：0x00000133: DPC_WATCHDOG_VIOLATION
- 状況：
- 動画視聴、ゲーム、ベンチマーク中など高負荷では落ちない
- 席を外している間など、放置（アイドル）時にだけフリーズ／BSOD
- ミニダンプ解析では KiDpcWatchdog、msedgewebview2 関連スレッドが見えることがある
この「負荷時は安定・アイドル時だけ不安定」というパターンは、CPU やデバイスが深い省電力状態へ移行するときに、ドライバーやファームウェアの応答が間に合わなくなっているサインであることが多いです。
DPC_WATCHDOG_VIOLATION（0x133）の仕組みと典型原因
DPC_WATCHDOG_VIOLATION は、Windows の「ウォッチドッグタイマー」が、割り込み処理（ISR）や遅延プロシージャコール（DPC）が規定時間内に終わらなかったことを検出したときに発生するバグチェックです。
ざっくり言うと「あるドライバー（またはその裏にいるデバイス）がいつまで経っても処理を返してこないので、OS が強制停止した」という状態です。
| 項目 | 内容 |
|---|---|
| DPC / ISR | デバイスからの割り込み処理の一種。ネットワーク、ストレージ、GPU などが利用。 |
| ウォッチドッグタイマー | 「割り込み処理が長く止まっていないか」を監視するタイマー。異常な遅延があると 0x133 を発生させる。 |
| 典型的な原因 | バグったドライバー、古い BIOS/UEFI、SSD/NVMe のファーム不整合、電源管理設定の相性など。 |
| アイドル時だけ出る理由 | 深い C-State や PCIe リンク省電力、ストレージ電源オフなど「アイドル専用の省電力動作」がトリガーになりやすい。 |
ミニダンプに msedgewebview2 が含まれているからといって、必ずしも WebView2 が「加害者」とは限りません。多くの常駐アプリ（Teams、ゲームランチャー、各社ユーティリティなど）が WebView2 を使っているため、「たまたまその瞬間動いていた被害者」としてログに残るケースが多々あります。
原因のパターンを整理：何が悪さをしているのか
アイドル時の DPC_WATCHDOG_VIOLATION は、大きく次のパターンに分類できます。
| カテゴリ | 具体例 | 起こりやすいシーン |
|---|---|---|
| 電源管理 / C-State | CPU が深い C-State へ移行→復帰に失敗、AMD の Power Supply Idle Control の相性など | 放置中のみ、スリープ前後、画面オフ直後 |
| ストレージ周り | NVMe / SATA ドライバー（Intel RST / AMD NVMe / storahci）、SSD ファームの不具合 | ディスクの電源オフ、アイドル時のガベージコレクション |
| ネットワーク / NIC | LAN / Wi‑Fi ドライバー、電源の節約のためのスリープ機能 | 放置中にだけ Wi‑Fi が切れる、リモート接続中のフリーズ |
| GPU / ドライバー | アイドルクロックからの復帰、マルチモニター＋高リフレッシュレート時の相性 | 画面オフ → 復帰時、スクリーンセーバー解除時 |
| BIOS/UEFI 不整合 | 古い BIOS、メモリの OC/XMP、ベータ版 BIOS など | 新しい CPU / GPU に交換した直後、Windows 11 へのアップグレード後 |
まず何をするべきか：優先度の高い対処の全体像
手当たり次第に設定をいじる前に、以下の順番で攻めるのがおすすめです。
- BIOS/UEFI と主要ドライバーを最新化する
- Windows 11 の電源管理（高速スタートアップ／電源プラン）を調整する
- BIOS の省電力機能（C-State や Power Supply Idle Control）を一時的に緩めて様子を見る
- LatencyMon とイベントビューアーで「どのドライバーが遅延しているか」を可視化する
- システム整合性のチェックと、周辺機器・オーバークロックの切り分け
- WebView2（msedgewebview2）が関与して見える場合は、Runtime の修復・再インストール
以下で、実際の手順を詳しく見ていきます。
BIOS/UEFI と主要ドライバーを最新化する
まずは「土台」を整えることが最優先です。Windows Update だけでは更新されないドライバーや BIOS/UEFI を、マザーボード／PCメーカーのサイトから直接入手して更新します。
更新を優先したいコンポーネント一覧
| 種類 | 具体例 | 入手先 |
|---|---|---|
| BIOS / UEFI | マザーボードの BIOS、プリインストール PC の UEFI | マザーボードメーカー／PCメーカー公式サイト |
| チップセット / MEI / AMD チップセット | Intel Chipset Software、Intel ME、AMD Chipset Driver | CPUメーカー公式、またはマザーボードメーカー |
| ストレージドライバー | Intel RST / VMD、AMD NVMe、SATA AHCI（storahci からの置き換え） | マザーボードメーカー、ストレージベンダーツール |
| GPU ドライバー | NVIDIA / AMD / Intel グラフィックスドライバー | GPU メーカー公式サイト |
| LAN / Wi‑Fi / BT | Realtek / Intel / Killer 等の NIC ドライバー | マザーボードメーカー、または各ベンダー公式 |
| SSD ファームウェア | NVMe SSD のファーム更新 | Samsung Magician、Crucial Storage Executive などベンダーツール |
特に、Windows 11 対応版 BIOS や、新しい CPU/GPU を正式サポートした BIOS が出ている場合は、古いバージョンのままだと電源管理周りで不具合が出ることがあります。リリースノートに「system stability」「improve compatibility」などと書かれているものも対象です。
Windows 11 の電源管理を見直す
高速スタートアップを無効にする
高速スタートアップは起動を速くする一方で、「シャットダウンしても完全には電源が切れない」挙動を取ります。そのため、ドライバーやファームウェアの初期化が不完全になり、アイドル時の不安定さにつながることがあります。
- [スタート] → 「コントロール パネル」 を開く
- 「ハードウェアとサウンド」 → 「電源オプション」を開く
- 左メニューから「電源ボタンの動作を選択する」をクリック
- 「現在利用可能ではない設定を変更します」をクリック
- 「高速スタートアップを有効にする（推奨）」のチェックを外す
- [変更の保存] をクリック
電源プランの詳細設定を調整する
電源プランの「最小のプロセッサの状態」が 5% など極端に低いと、アイドル時に CPU クロックが落ちすぎて復帰時に不安定になるケースがあります。
- 「電源オプション」で、使用中のプラン（例：バランス）横の「プラン設定の変更」をクリック
- 「詳細な電源設定の変更」をクリック
- 「プロセッサの電源管理」→「最小のプロセッサの状態」を開く
- バッテリ駆動／電源接続の両方を 20～30% 程度に設定
- 「PCI Express → リンク状態の電源管理」を「オフ」に設定（切り分け目的）
- 必要に応じて「ハードディスク → 次の時間が経過後ハードディスクの電源を切る」を 「0（なし）」 に設定し、ストレージの省電力が影響していないか確認
これらはあくまで「切り分け用」です。安定したことを確認したら、必要に応じて少しずつ元に戻して、省電力と安定性のバランスを取ると良いでしょう。
BIOS/UEFI の省電力設定を緩めて様子を見る
アイドル時にだけ落ちる場合、CPU の C-State や電源のアイドル制御が絡んでいる可能性が高くなります。以下は主な設定項目です。
| 設定項目 | 例・表記 | 推奨テスト設定 |
|---|---|---|
| CPU C‑States | CPU C State Control / C1E / C6 / Package C State | 一旦無効化、または C1 のみに制限 |
| Power Supply Idle Control（AMD） | Typical Current Idle / Low Current Idle | Typical Current Idle に変更 |
| メモリ OC / XMP / EXPO | XMP Profile1 / D.O.C.P / EXPO など | 一度Auto（定格）に戻す |
| CPU / GPU OC / アンダーボルト | PBO、電圧オフセット、GPU OC プロファイル | すべてオフ（定格状態）で検証 |
実際に「CPU C‑State を無効化」と「Power Supply Idle Control を Typical Current Idle に変更」することで、アイドル時の 0x133 が発生しなくなった例が複数報告されています。
ただし、これらの設定変更はあくまで「切り分け」です。安定を確認できたら、BIOS やドライバーを最新化した上で、C-State や省電力機能を段階的に元に戻していくのが理想です。
LatencyMon で DPC/ISR の遅延を可視化する
闇雲に設定をいじるのではなく、「どのドライバーが遅延を引き起こしているか」を可視化するのが LatencyMon です。
LatencyMon の使い方（ざっくり手順）
- LatencyMon をダウンロードしてインストール
- アプリを起動し、「Start」ボタンを押す
- PC を通常通り使用しつつ、アイドル状態も数十分程度放置してみる
- 問題が出ていそうなタイミングで「Stop」をクリック
- 「Drivers」タブで、DPC routine execution time や ISR count が極端に高いドライバーを確認
| ドライバー名の例 | 意味 | 対処の方向性 |
|---|---|---|
| ndis.sys | ネットワーク（LAN / Wi‑Fi）関連 | NIC ドライバー更新、電源の節約オプションをオフにする |
| storport.sys / storahci.sys | ストレージ（SATA / AHCI）関連 | ストレージドライバー更新、AHCI → メーカー製ドライバーへの変更 |
| nvlddmkm.sys | NVIDIA GPU ドライバー | ドライバーのクリーンインストール、バージョン変更 |
| HDAudBus.sys など | オーディオ周り | オーディオドライバー更新、不要なオーディオデバイスを無効化 |
LatencyMon で「犯人候補」が見えてきたら、そのデバイスのドライバーや電源設定に的を絞って対策を行うと効率的です。
イベントビューアーとシステム整合性チェック
イベントビューアーで関連ログを調べる
Windows のイベントビューアーでも、ハードウェアエラーやドライバーのエラーが出ていないか確認します。
- [スタート] を右クリックし「イベント ビューアー」を開く
- 左ペインから「Windows ログ → システム」を開く
- 右側の「現在のログをフィルター」で「警告」「エラー」「重大」に絞り込む
- WHEA-Logger、Disk、storahci、nvlddmkm などのイベントが頻発していないか確認
特定のイベントが 0x133 発生の少し前から連続して出ている場合、そのデバイスやドライバーが怪しくなります。
sfc /scannow と DISM でシステムファイルを修復
システムファイルの破損があると、ドライバー以外の部分で不安定さを招くことがあります。管理者権限の PowerShell またはコマンドプロンプトから次のコマンドを実行します。
sfc /scannow
完了後、必要であれば続けて DISM コマンドも実行します。
DISM /Online /Cleanup-Image /RestoreHealth
いずれも再起動を要求されることがあるため、作業中のファイルは事前に保存しておきましょう。
周辺機器と電源周りの切り分け
意外と見落とされがちなのが、USB 機器や電源の影響です。
- USB ハブに大量の機器を接続している → 一度すべて外す／最小構成で運用して様子を見る
- Bluetooth ドングルや古い USB デバイス → 外した状態でアイドル放置テスト
- 電源ユニット（PSU）が古い／定格ギリギリ → 別の PSU で試す、または負荷テスト＋アイドルテスト
- PC ケース内の温度が高すぎる → 温度監視ツールで CPU / GPU / SSD 温度を確認
アイドル時でも、バックグラウンドでの更新やスキャンにより一時的に負荷がかかることがあります。高温や電源不足で不安定になっていないかもチェックしておきましょう。
WebView2（msedgewebview2）がクラッシュログに出る場合
ミニダンプやブルースクリーンの解析結果に msedgewebview2 関連のスレッド名が表示されることがありますが、これは多くの場合、
- WebView2 を利用していたアプリが、別のドライバー起因のクラッシュに巻き添えになった
という形で「被害者として」記録されているだけです。ただし、念のため以下の対策を行ってもよいでしょう。
- [設定] → 「アプリ」 → 「インストールされているアプリ」を開く
- 一覧から「Microsoft Edge WebView2 Runtime」を探す
- 「…」ボタンメニューから「修復」を選択
- 改善がない場合、「アンインストール」→ 再度最新の WebView2 Runtime を Microsoft 公式からインストール
あくまでも「切り分け用」であり、根本的な原因は別のドライバーや電源管理にあることがほとんどです。
実際に効果があった解決例
実際の報告例から、特に効果の高かった設定変更をまとめると次の通りです。
| 環境 | 変更した設定 | 結果 |
|---|---|---|
| AMD Ryzen + Windows 11 | BIOS で CPU C‑State をすべて無効 BIOS の Power Supply Idle Control を「Typical Current Idle」 に変更 | アイドル放置で頻発していた 0x133 が発生しなくなった |
| Intel 第 12 世代 + NVMe SSD | マザボメーカー提供の Intel RST / VMD ドライバーに更新 SSD ベンダーツールで ファームウェアを最新化 | 放置中のフリーズが解消、イベントログの Disk エラーも消失 |
| ノート PC（Windows 11） | 「高速スタートアップ」を無効 電源プランの「最小のプロセッサの状態」を 5%→25% に引き上げ PCI Express リンク状態の電源管理を「オフ」に設定 | スリープ前後や蓋を閉じていた間にだけ起こっていた BSOD が発生しなくなった |
共通しているのは、
- BIOS/ドライバー更新で基盤の安定性を上げる
- アイドル時の省電力を少し緩める
という二本立てでアプローチしている点です。
再発防止のポイント
一度直ったように見えても、OS やドライバーの大型アップデートの後に再発することがあります。長期的な安定のために、次の点を意識しておくと良いでしょう。
- BIOS/UEFI・チップセット・ストレージ・GPU ドライバーは、半年～1年に一度はまとめて更新を検討する
- CPU/GPU/メモリの オーバークロックやアンダーボルトは最小限に留め、問題が出たらすぐ定格に戻して検証
- SSD / HDD の SMART 情報を、ベンダーツールや CrystalDiskInfo などで 定期的にチェックする
- 電源ユニットは、定格出力に十分な余裕があるものを選び、5年以上使っている場合は交換も検討
どうしても原因が切り分けられない場合は、
- 別 OS（Linux Live USB や Windows PE）でブートしてアイドル放置し、同様のフリーズが起こるか確認
といった方法で、ハード寄りの問題かソフト寄りかを見極めることも有効です。
トラブルシューティング手順の例（まとめ）
ここまでの内容を「実践手順」としてまとめると、次のような流れになります。
- 現象を整理する
- アイドル時だけか、スリープ前後か、特定アプリ使用後かをメモ
- BIOS/UEFI と主要ドライバー（チップセット、ストレージ、GPU、LAN/Wi‑Fi）を最新化
- Windows 11 の「高速スタートアップ」を無効化し、電源プランで
- 最小プロセッサの状態 → 20～30%
- PCI Express リンク状態の電源管理 → オフ
- BIOS で
- CPU C‑State を無効 or 浅い状態に限定
- （AMD）Power Supply Idle Control を「Typical Current Idle」に変更
- XMP / EXPO / OC を一旦オフにして定格運用
- LatencyMon を実行し、DPC/ISR の遅延が大きいドライバーを特定
- イベントビューアーの「システム」ログで WHEA-Logger や Disk、storahci、nvlddmkm などの警告・エラーを確認
- 管理者コマンドプロンプトで
sfc /scannow→DISM /Online /Cleanup-Image /RestoreHealthを実行 - 不要な USB/BT 周辺機器を外し、最小構成でアイドル放置テスト
- ミニダンプに msedgewebview2 が出る場合は、WebView2 Runtime の修復・再インストール
- 別 OS でのアイドルテストや PSU 交換など、必要に応じてハード側の検証
まとめ：アイドル時の 0x133 は「省電力 × ドライバー」のサイン
- 症状は、アイドル時に限って DPC_WATCHDOG_VIOLATION（0x133）が発生し、負荷時は安定しているというもの
- 原因の核は、省電力遷移（C-State や PCIe 省電力など）と、ドライバー / ファームウェアの遅延が組み合わさった問題であることが多い
- まずは BIOS/UEFI・チップセット・ストレージ・GPU・LAN/Wi‑Fi ドライバーの更新と、Windows の高速スタートアップ無効化・最小プロセッサ 20～30% の設定を試す
- 改善しない場合は、BIOS で CPU C‑State を無効／Power Supply Idle Control を Typical Current Idle に変更してみる
- LatencyMon とイベントビューアーを使って、どのドライバーが DPC/ISR に負荷をかけているかを可視化することで、効率よく原因に迫れる
- 実例として、C‑State 無効化 + Typical Current Idle、およびストレージや GPU ドライバーの更新で、アイドル時のフリーズや 0x133 が解消したケースが確認されている
「放置したときだけ落ちる」問題は非常にストレスですが、ポイントは「アイドル時にだけ動作する省電力機能」と「古い／相性の悪いドライバー」を順番に潰していくことです。本記事の手順を上から順に試していけば、原因の切り分けと解決に大きく近づけるはずです。
コメント