Diagnostic Policy Service High CPU Problem: The Causes and Fixes for Windows

1. Introduction

Diagnostic Policy Service (DPS) is a built-in Windows service (service name: DPS) that enables problem detection, troubleshooting, and automatic remediation for Windows components. It runs under svchost.exe and powers scenarios like network connectivity checks, boot/shutdown performance diagnostics, and disk S.M.A.R.T. alerts. Under normal conditions it’s lightweight. When DPS pegs CPU or disk, it’s usually because its diagnostic data store or dependencies are unhealthy (e.g., a bloated or corrupt SRU database, damaged performance counters/WMI, or a device/driver fault that keeps retriggering diagnostics). Disabling DPS is a blunt workaround that breaks Windows’ built-in troubleshooting and is not recommended except for specialized images.

This tutorial walks you through quick triage and then clean, reversible fixes that address root causes without sacrificing system diagnostics.

2. Quick Triage (do these first)

2.1. Restart DPS cleanly

• Open Services (services.msc) → Diagnostic Policy Service → Restart.
• Or run (Administrator Command Prompt):

net stop DPS & net start DPS

If CPU stabilizes only briefly, continue.

2.2. Reboot once

• A reboot can clear stuck diagnostics and release handles on the SRU database.

2.3. Windows Update + driver refresh

• Install pending updates, then update network/storage drivers from the vendor (these devices most often retrigger DPS scenarios).

2.4. Temporary pressure relief (optional, last resort in a pinch)

• Set Diagnostic Policy Service → Startup type: Manual and reboot. This reduces CPU immediately but turns off built-in diagnostics (network, performance, disk alerts). Treat as temporary only.

3. Prerequisites

3.1. Admin rights

Ensure you have administrator rights on the affected PC.

3.2. A restore point or backup

• Create one especially before steps that reset databases or rebuild subsystems.

3.3. Tools (optional but recommended)

• Process Explorer (Sysinternals) to confirm the hosting svchost.exe is Microsoft-signed (Options → Verify Image Signatures).
• Sigcheck (Sysinternals) to verify signatures from the command line:

sigcheck -m C:\Windows\System32\svchost.exe

These help rule out malware masquerading as a Windows service.

4. Step-by-Step Guide

4.1. Identify the culprit clearly

• Open Task Manager → Processes. Look for Service Host: Diagnostic Policy Service consuming CPU.
• Right-click → Open services to land on Diagnostic Policy Service (DPS). This confirms you’re targeting the correct service.

4.2. Rule out tampering (fast sanity check)

• In Process Explorer, enable Options → Verify Image Signatures and select the svchost.exe instance hosting DPS. It should be verified as Microsoft Windows with path C:\Windows\System32\svchost.exe.
• CLI alternative: sigcheck -m C:\Windows\System32\svchost.exe should report a valid Microsoft signature. If signatures are invalid/missing, perform a full malware scan before proceeding.

4.3. Reset the SRU (System Resource Usage) database that DPS relies on

SRU (C:\Windows\System32\SRU\SRUDB.dat) tracks per-app resource/network usage and feeds diagnostics. When it grows large or gets corrupt, DPS can loop hard on CPU/disk. The safest fix is to stop DPS and delete/rename the SRU folder; Windows will recreate it. You’ll lose historical app/data-usage stats, but nothing critical.

• Administrator Command Prompt:

net stop DPS
net stop WdiServiceHost
net stop WdiSystemHost
ren C:\Windows\System32\SRU SRU.old
rem Reboot, or start the services again:
net start WdiSystemHost
net start WdiServiceHost
net start DPS

If you previously saw ESENT errors that mention SRUDB.dat, they should cease after this reset.

4.4. Repair Windows component health (DISM) and protected files (SFC)

Corruption in system binaries can make DPS scenarios misbehave.

• Administrator Command Prompt:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Reboot if SFC reports repairs.

4.5. Rebuild performance counters (only if counters are broken or PerfMon looks odd)

Corrupt counters can cause services hosted in svchost.exe to misbehave.

• Administrator Command Prompt:

lodctr /r

If some counters remain missing, rebuild them per Microsoft guidance. Reboot after.

4.6. Validate and repair WMI if you see WMI-related errors

DPS can query WMI extensively. A corrupt repository can create sustained load.

• Administrator Command Prompt:

winmgmt /verifyrepository
winmgmt /salvagerepository

If the repository is still inconsistent (rare), rebuild per Microsoft guidance and reboot.

4.7. Fix network stack churn (if spikes correlate with network issues)

Misconfigured adapters or stack corruption can cause DPS to run network diagnostics constantly.

• Update or roll back network adapter drivers (Device Manager).
• Administrator Command Prompt:

netsh winsock reset
ipconfig /flushdns

Reboot and retest.

4.8. Right-size DPS workload (admins/IT, optional)

In managed environments you can dial down execution or cap scenario data so diagnostics don’t build up excessively.

• Group Policy (Pro/Enterprise): Computer Configuration → Administrative Templates → System → Troubleshooting and Diagnostics → configure Scenario Execution Level for specific areas (Boot, Shutdown, Standby/Resume, Resource Exhaustion). Choose Detection and troubleshooting only to reduce remediation overhead.
• MDM/Policy CSP: ADMX_WDI → WdiDpsScenarioDataSizeLimitPolicy (default purge beyond 128 MB), or adjust scenario execution policies; ADMX_DiskDiagnostic tunes disk S.M.A.R.T. diagnostics. Changes apply immediately while DPS is running.

4.9. As a last resort: leave DPS on Manual

If none of the above stabilizes CPU and you need a usable machine immediately, set Startup type to Manual. Document this and circle back to fix the root cause, because you lose automatic diagnostics while it’s off.

5. Validation and Testing

5.1. Watch CPU over time

• Task Manager → Processes (and Details) to confirm Service Host: Diagnostic Policy Service stays near 0% at idle.
• Resource Monitor (resmon) to check disk I/O against SRUDB.dat is quiet.

5.2. Run a system health report

• perfmon /report collects a 60-second snapshot; ensure no persistent diagnostics warnings.

5.3. Event Viewer sanity checks

• Applications and Services Logs → Microsoft → Windows → Diagnostics-Performance for performance scenario entries.
• Confirm ESENT errors tied to C:\Windows\System32\SRU\SRUDB.dat no longer appear.

5.4. Trigger a gentle test

• Disconnect and reconnect to a network; DPS should diagnose once and then idle—not loop.

6. Security Hardening (prevent recurrences)

6.1. Keep Windows and drivers current

Prioritize NIC/storage drivers.

6.2. Monitor SRU size periodically

• Check C:\Windows\System32\SRU and investigate if it balloons again (often a device/driver loop).

6.3. Leave DPS enabled

• Unless you have a managed policy reason to reduce it; disabling removes built-in diagnostics on general-purpose systems.

6.4. Use Sysinternals regularly

• Process Explorer, Autoruns, and Sigcheck help spot unsigned or suspicious processes early.

7. Conclusion

High CPU from Diagnostic Policy Service is a symptom, not the disease. In most cases, resetting the SRU database and repairing Windows components (DISM/SFC) resolve it; if not, performance counters/WMI repairs and network stack/driver fixes do. Keep DPS enabled for visibility and self-healing, and enforce sane diagnostics policies in managed environments.

8. FAQ