Windows 11 で「Service Host: Diagnostic Policy Service（DPS）」が常にCPUを食い続けていて、タスク マネージャーを開くたびに第1コアが張り付いている…。SRUDB.dat を消しても、クリーンインストールをしても、しばらくすると再発する――そんな「沼」にはまっている方向けに、WHEA-Logger の警告と絡めた根本原因の考え方と、現実的な解決手順をまとめます。
Windows 11で「Service Host: Diagnostic Policy Service」のCPU使用率が高くなる症状
今回取り上げる典型的な症状を整理すると、次のようになります。
| 症状 | 具体的な状態 |
|---|---|
| DPS（診断ポリシーサービス）のCPU使用率が高い | 「Service Host: Diagnostic Policy Service」が断続的に最大CPU約15%を使用。特に第1コアが張り付きやすい。 |
| SRUDB.dat削除やクリーンインストールで一時的に改善 | C:\Windows\System32\sru\SRUDB.dat を消すと改善するが、数日〜数週間で再発。Windows 11 をクリーンインストールしても同様。 |
| イベント ビューアーにWHEA-Loggerが大量発生 | 「A corrected hardware error has occurred. / Component: PCI Express Root Port」などの警告が多数。PCIe ルートポート（VEN_8086&DEV_7ECC）が発生元。 |
| DISM /RestoreHealthが途中で止まる | DISM /Online /Cleanup-Image /RestoreHealth を実行すると 62% 付近で進まなくなることがある。 |
ここまで揃うと、単なる「Windowsの気まぐれ」ではなく、PCI Express ルートポート周りのエラーが原因で、DPSがログ・診断処理に引きずられている可能性が高くなります。
Diagnostic Policy Service（DPS）とは？
まずは主役である「Diagnostic Policy Service」の役割を押さえておきましょう。
| 項目 | 内容 |
|---|---|
| サービス名 | Diagnostic Policy Service（診断ポリシーサービス） |
| 実体 | svchost.exe 配下のサービスとして動作 |
| 主な役割 | ネットワーク/ハードウェア/システム構成の問題を検出し、イベントログやトラブルシューティングに必要な情報を収集・解析する。 |
| 連携する仕組み | イベントログ、WHEA（Windows Hardware Error Architecture）、ネットワーク診断、SRUM（System Resource Usage Monitor）など。 |
ポイントは、DPSは「原因」ではなく、エラーやログを処理する「結果として重くなっている」ことが多いという点です。つまり、DPSだけを止めたり、SRUDB.dat を削除するだけでは「氷山の一角」を削っているにすぎず、根本原因が残っていると必ず再発します。
DPSが高負荷になる原因の全体像
今回のケースで想定される原因を、ざっくり図解イメージで言い換えると次のような流れです。
| レイヤー | 起きていること | DPSへの影響 |
|---|---|---|
| ハードウェア/ファームウェア | PCIe ルートポート or その配下デバイスで是正済みハードウェアエラーが継続発生（WHEA-Loggerの警告嵐）。 | エラーイベントが大量に記録され続ける。 |
| ドライバ/チップセット | チップセットドライバ・BIOS・MEファーム・NVMe/GPU/ネットワーク等のドライバが古い or 不整合。 | WHEAの発生頻度が高まり、DPSが常に診断処理を行う状態に。 |
| ログ/データベース | イベントログや SRUDB.dat の肥大化・断片化。DISM での修復も途中停止することがある。 | ログ走査・整合性チェックのコストが増え、DPSが単一コアを長時間占有。 |
したがって、「DPSを軽くする＝WHEAを止める＋ログ・システム整合性を正常化する」が正しい順序になります。以降は、優先度の高い順に対処手順を説明していきます。
最優先：チップセット／BIOS／Intel MEを最新化する
WHEA-Logger の内容に「Component: PCI Express Root Port」「VEN_8086&DEV_7ECC」などが記録されている場合、そのポートを提供している Intel チップセット／BIOS／ME（Management Engine） の更新が最重要です。
PC/マザーボードの公式サポートページを開く
- まず、自分のPCの「メーカー名」「型番」を確認します。
ノートPCなら本体裏面のラベル、デスクトップなら「システム情報」か UEFI 画面で確認できます。 - メーカーの公式サイトを開き、「サポート」「ダウンロード」などのページから該当モデルを検索します。
（例：ASUS / MSI / GIGABYTE / ASRock / Dell / HP / Lenovo など）
チップセット関連ドライバとファームウェアを更新
| 更新対象 | 備考 |
|---|---|
| Intel Chipset Device Software / INF ドライバ | 「チップセット ドライバー」などの名称。必ずメーカー配布版を使用する。 |
| Intel Management Engine（ME） | ME ファームウェア+ドライバセットになっていることが多い。セキュリティ修正も含まれやすい。 |
| Intel Serial IO / Intel Rapid Storage Technology（必要に応じて） | NVMe や SATA 周りの制御に関与する場合があるため、提供されていれば更新推奨。 |
| BIOS/UEFI | リリースノートに「PCIe Stability」「WHEA」「ME Update」などが含まれていれば特に更新優先度が高い。 |
BIOS更新の注意点：
- 必ずメーカーの手順に従い、ACアダプタ接続・停電リスクの低い状況で実施。
- 途中で電源断するとPCが起動不能になるリスクがあるため、慣れていない場合はサポートに相談するのも手です。
更新後は、Windows を再起動し、次の2点を確認します。
- イベント ビューアー → 「Windows ログ」→「システム」→ WHEA-Logger が新たに発生していないか。
- DPS（Diagnostic Policy Service）のCPU使用率がアイドル時に 0〜数% で落ち着いているか。
ここで WHEA が収まれば、DPSの高負荷はかなり改善されているはずです。
どのPCIeルートポート配下が原因かを特定する
チップセットやBIOSを最新化しても WHEA-Logger が出続ける場合、特定のPCIe配下デバイスがエラー源になっている可能性が高いです。
WHEAイベントから Bus/Device/Function を読む
- イベント ビューアーを開きます。
「Windows 管理ツール」→「イベント ビューアー」またはeventvwr.msc。 - 左ペインで「Windows ログ」→「システム」を選択し、ソースが WHEA-Logger のイベントを探します。
- 該当イベントをダブルクリックし、「詳細」タブを表示します。
- XML表示 or テキスト内に次のような情報があるので控えます。
Bus: 0x00, Device: 0x01, Function: 0x00など。
この Bus/Device/Function（BDF）が、どの PCI Express ルートポートに対応しているかを、デバイス マネージャー側で突き合わせます。
デバイス マネージャーで原因デバイスを突き止める
- スタートボタンを右クリック →「デバイス マネージャー」を開きます。
- メニューの「表示」→「デバイス（接続別）」を選択します。
- 「PCI Express ルートポート」と名のつくツリーを順番に展開していきます。
- 各デバイスを右クリック→「プロパティ」→「詳細」タブ→「プロパティ」欄から「場所」を選び、 「PCI バス 0, デバイス 1, 機能 0」といった表示を確認します。
- 先ほど WHEA イベントで控えた BDF（例：0:1:0）と一致するポートと、その配下にぶら下がっているデバイスを特定します。
よく見かけるパターンをまとめると、次のような組み合わせになります。
| PCIe配下デバイスの例 | 具体例 | 対策の方向性 |
|---|---|---|
| NVMe SSDコントローラー | Samsung / WD / KIOXIA / Crucial などのNVMe SSD | メーカー提供のドライバ・ファームウェアを最新化。可能なら別スロット・別M.2ソケットで検証。 |
| グラフィックボード | NVIDIA / AMD / Intel Arc などのdGPU | 最新ドライバへの更新、物理的な挿し直し、別スロットでの動作確認。 |
| Wi‑Fi / Bluetooth モジュール | Intel AX系、Killer、Realtek等 | ドライバ最新化、アンテナ・モジュールの接触不良チェック。 |
| キャプチャカード・拡張カード | ビデオキャプチャ、サウンドカード、USB増設カードなど | メーカー版ドライバへの更新、他のPCIeスロットでの検証、不要なら一時的に取り外し。 |
配下デバイスごとの具体的なメンテナンス
- NVMe SSD
メーカーのユーティリティ（Samsung Magician、WD Dashboard 等）がある場合、それを使ってファームウェア更新を行います。 - グラフィックボード
DDU(Display Driver Uninstaller) などを使ったクリーンインストールも有効ですが、まずは公式ドライバの上書きインストールから試すのが安全です。 - 拡張カード類
物理的に一度抜き差しして酸化した接点をリフレッシュしたり、別のPCIeスロットで動かして WHEA の発生有無を比較すると、故障切り分けがしやすくなります。
この段階で、WHEA-Logger の発生源をほぼ特定できれば、DPSの負荷が落ちるまであと一歩です。
ネットワーク ドライバーをクリーン再インストールする
DPSはネットワーク診断と密接に連携しているため、ネットワーク ドライバーの不整合や破損があると、それだけで高負荷になるケースもあります。
クリーン再インストール手順
- デバイス マネージャーを開き、「ネットワーク アダプター」を展開します。
- メインで使っているアダプター（有線LAN、Wi‑Fi）を右クリック → 「デバイスのアンインストール」を選択します。
- ダイアログの「このデバイスのドライバーソフトウェアを削除する」にチェックを入れ、OK を押します。
- PCを再起動します。
- メーカー公式サイトからダウンロードした最新ドライバをインストールします（Windows標準ドライバに任せない）。
その後、しばらく通常利用をしてみて、DPS の CPU 使用率と WHEA-Logger の発生状況を確認します。
DISM / SFCでシステム整合性を修復する
WHEA の原因を潰しても、すでに壊れてしまったコンポーネントストアやシステムファイルが残っていると、DPS がログ解析や診断に失敗し続け、結果的に高負荷になることがあります。
オンラインでの基本チェック
管理者権限のコマンド プロンプトまたは PowerShell を開き、次の順に実行します。
sfc /scannow
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
sfc /scannowでシステムファイルに破損がないかをチェック＆修復。DISM /CheckHealthと/ScanHealthでコンポーネントストアの状態を確認。
ここまででエラーが出なければ、そのまま次のコマンドで修復を試みます。
DISM /Online /Cleanup-Image /RestoreHealth
しかし、質問のケースのように 62% 付近で止まったまま進まない場合、オンライン上の修復ソースに問題があることが多く、オフライン修復に切り替えるのが近道です。
Windows 11 ISOを使ったオフライン修復
- Microsoft公式サイトから Windows 11 のISOファイルをダウンロードします。
- ISOファイルを右クリック → 「マウント」を選択します。
- エクスプローラーに新しいドライブ（例：
X:）としてマウントされるので、そのドライブ文字を控えます。 - 管理者のコマンド プロンプトで、WIM形式/ESD形式に応じて次のいずれかを実行します。
WIMの場合：
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:X:\sources\install.wim:1 /LimitAccess
ESDの場合：
DISM /Online /Cleanup-Image /RestoreHealth /Source:ESD:X:\sources\install.esd:1 /LimitAccess
X: は実際にマウントされたドライブ文字に置き換えてください。
完了したら Windows を再起動し、再度次のコマンドで整合性が取れているか最終確認します。
sfc /scannow
ここまで完走できれば、DISM関連の問題でDPSが重くなる可能性はかなり低くなります。
イベントログの整理・再構築でDPSの負荷を軽くする
WHEAや各種警告が大量に記録され続けた環境では、イベントログそのものが巨大化・断片化しており、DPSがログ処理に時間を取られてしまうことがあります。
GUIからのログクリア
- イベント ビューアーを開き、「Windows ログ」→「Application」「System」をそれぞれ右クリックします。
- 「ログのクリア」を選択し、不要であればそのまま削除します（必要なら事前に「名前を付けて保存」でバックアップ）。
WHEA-Logger が収まっている状態であれば、これだけでもDPSの負荷が軽くなることがあります。
WinREからイベントログデータベースを再生成する（上級者向け）
それでもなお DPS が重く、WHEA も止まらない場合は、Windows 回復環境（WinRE）からイベントログDBを作り直す方法があります。
- 設定 →「システム」→「回復」→「PCの起動をカスタマイズ」から再起動し、WinREに入ります。
- 「トラブルシューティング」→「詳細オプション」→「コマンド プロンプト」を開きます。
- Windowsがインストールされているドライブ（通常は
C:）を確認し、次のコマンドを実行します。
del /s /q %SystemRoot%\System32\winevt\Logs\*.evtx
再起動すると、イベントログDBは自動的に再生成されます。
※すべてのイベントログが消えるため、必要なログがある場合は事前にバックアップを取っておきましょう。
SRUM（SRUDB.dat）のリセットは「補助的な対処」
SRUDB.dat は System Resource Usage Monitor（SRUM） のデータベースで、ネットワークやアプリごとの使用量などを記録しています。ここが破損・肥大化すると、DPSがSRUMを参照する際に負荷が上がることがあります。
ただし、SRUDB.dat の削除はあくまで「結果の片付け」であり、WHEAなど根本原因を潰さない限り再発しやすいという点には注意が必要です。
SRUDB.datのリセット手順
- サービス（
services.msc）を開き、次のサービスを停止します。- Diagnostic Policy Service
- Diagnostic Service Host
- Diagnostic System Host
- エクスプローラーで
%windir%\System32\sruフォルダを開きます。 - フォルダ内の
SRUDB.datおよび関連ファイル（拡張子.dat等）を削除します。 - PCを再起動し、先ほど停止した診断系サービスのスタートアップの種類が「自動」になっていることを確認します。
この操作で一時的にDPSが軽くなっても、WHEAやドライバ不整合が残っていれば、またSRUDB.datが肥大化して同じ問題が再発しがちです。
必ず ①〜③ の根本対策を優先し、その補助として実施すると考えてください。
どうしても解決しない場合の最終手段：インプレースアップグレード
ここまでの対処を行っても、
- WHEA-Logger が止まらない
- DPS のCPU使用率が常に高いまま
- DISM / SFC で重大な破損が繰り返し検出される
といった状態が続く場合、Windowsのインプレースアップグレード（修復インストール）を検討します。
インプレースアップグレードの概要
- Microsoft公式から Windows 11 のISOをダウンロードし、マウントします。
- マウントされたドライブ内の
setup.exeを実行します。 - 画面の指示に従い、「個人用ファイルとアプリを引き継ぐ」オプションを選択してインストールを進めます。
これにより、アプリや設定を残したまま、Windows本体をほぼ再インストールする形になり、システムファイルやコンポーネントストアの深刻な破損をまとめて修復できます。
実施前には、念のため重要なデータのバックアップを取っておくことを強くおすすめします。
再発防止のチェックポイントと運用のコツ
一度直っても、環境や使い方によっては再発のリスクがあります。以下のポイントを押さえて運用すると、DPSの高負荷を予防しやすくなります。
対策後に必ず確認したいポイント
- タスク マネージャーで、アイドル時の「Service Host: Diagnostic Policy Service」のCPU使用率が常時 0〜数％程度に収まっているか。
- イベント ビューアーの「システム」ログで、WHEA-Logger（特にID 17など）の新規イベントが収束しているか。
- SRUDB.dat のサイズが極端に肥大化していないか（数百MB〜GB単位になっていないか）。
電源設定の見直し（PCIeリンク状態の電源管理）
環境によっては、PCIe の省電力機能が逆に不安定さを招き、WHEAを誘発しているケースもあります。
- コントロール パネル →「ハードウェアとサウンド」→「電源オプション」を開く。
- 使用中の電源プランの「プラン設定の変更」→「詳細な電源設定の変更」をクリック。
- 「PCI Express」→「リンク状態の電源管理」を「オフ」または「中」などに変更して挙動を観察。
機種依存のため絶対解とは言えませんが、WHEAが省電力遷移のタイミングで発生している場合、この設定が効くことがあります。
イベントログの運用設定
ログの肥大化を防ぐため、主要なログの最大サイズや上書き設定を見直しておきましょう。
- イベント ビューアー → 各ログ（「Application」「System」など）を右クリック →「プロパティ」。
- 「最大ログサイズ」を適切な値に設定（例：20〜100MB程度）。
- 「ログの保持方法」を「必要に応じてイベントを上書きする」に設定。
これだけでも、長期間放置した環境でログが巨大化し、DPSのログ処理が重くなることをある程度防げます。
ハードウェアの切り分けを習慣化する
WHEAがハードウェア起因かどうかを切り分けるには、次のような「物理的なテスト」も有効です。
- 拡張カード（キャプチャ、サウンド、USBカードなど）を一時的にすべて外し、最小構成でWHEAの発生が止まるかを見る。
- NVMe SSDを別スロット・別M.2ポートに挿し替えて挙動を比較する。
- 可能であれば、別の電源ユニットや別のGPUでテストしてみる。
ソフトウェアだけで解決しようとせず、「配下デバイスのどれかが物理的に怪しいのでは？」という視点を持つと、原因が見えやすくなります。
よくある質問（FAQ）
DPS（Diagnostic Policy Service）を無効化してしまっても良い？
一時的な切り分け目的で停止するのは構いませんが、常時無効化はおすすめできません。
ネットワークトラブルやハード障害の自動診断が働かなくなり、問題発生時に原因が分かりにくくなります。
DPSそのものを悪者扱いするのではなく、今回紹介したように「WHEAやドライバの不整合」といった根本原因を潰すことを優先してください。
SRUDB.dat削除だけで直っているように見えるけど、このままで大丈夫？
SRUDB.datを削除すると、DPSが参照するSRUMデータベースがリセットされるため、一時的に軽くなることはよくあります。
しかし、WHEA-Logger が出続けている状態であれば、いずれ同じ問題が再発します。
少なくとも、
- チップセット/BIOS/MEの更新
- PCIe配下デバイスのドライバ＆ファーム更新
- DISM/SFCでの整合性修復
まではセットで実施しておくことを強く推奨します。
「A corrected hardware error has occurred」は故障の前兆？ PCを買い替えるべき？
「corrected（是正済み）」とある通り、このエラーは「ハード側で自己修復できたが、その記録を残している」状態です。
ただし、
- 同じコンポーネントから短時間に大量発生している
- そのタイミングでフリーズやブルースクリーンが目立つ
といった場合は、将来的な故障リスクはゼロではありません。
別のデバイス/スロットで再現するか、他のPCで使っても同様のWHEAが出るかなどを試し、特定デバイスに依存して出るようであれば、そのデバイス交換も視野に入れるとよいでしょう。
まとめ：DPS高負荷は「ログの結果」であって「原因」ではない
Windows 11 で「Service Host: Diagnostic Policy Service（DPS）」が単一コアを占有するほど高負荷になっているとき、多くの場合、
- WHEA-Logger による PCIe ルートポート（
VEN_8086&DEV_7ECCなど）起因のエラー嵐 - それを引き起こす チップセット／BIOS／ME／配下デバイスのドライバやファームの不整合
- DISMエラーやイベントログ・SRUDB.dat の肥大化による 診断処理のコスト増
が背後に潜んでいます。
DPSそのものを疑うよりも、
- チップセット／BIOS／ME と PCIe配下デバイス（特に NVMe・GPU・ネットワーク）の更新
- DISM / SFC によるシステム整合性のオフライン修復
- イベントログと SRUDB.dat の整理・再構築
という順番で手を打つことで、根本原因から順番に潰し、再発しにくい安定した状態に持っていくことができます。
「DPSが重いから止める」のではなく、「DPSが重くなるほどのエラーを出している元凶」を特定・修正する──この視点を持って対処してみてください。
コメント