If “Service Host: Diagnostic Policy Service” is consuming unusual CPU or RAM, do not disable it immediately. The visible svchost.exe row is only a host process; it may contain Diagnostic Policy Service (DPS) alongside other Windows services. First identify the process ID (PID), prove that DPS is attached to it, and collect evidence with Task Manager and Resource Monitor. Only then should you isolate DPS in its own host as a temporary, reversible test.
DPS is a normal Windows component. Microsoft describes it as the service that enables problem detection, troubleshooting, and resolution for Windows components. Stopping it stops diagnostics that depend on Diagnostic Service Host or Diagnostic System Host, so isolation is a diagnostic measure—not a universal performance cure.
As an Amazon Associate I earn from qualifying purchases.
What “Service Host: Diagnostic Policy Service” means
Windows uses svchost.exe to host services. Task Manager can therefore show a row named “Service Host: Diagnostic Policy Service” even though the executable is the shared Service Host process. Depending on Windows configuration, one svchost.exe instance can contain one service or several services. The name displayed in Task Manager is not, by itself, proof that DPS is responsible for every CPU cycle or every megabyte attributed to that process.
DPS is installed with Windows and uses Automatic startup. Its job is to detect problems, run troubleshooting, and help resolve failures in Windows components. That work can briefly increase CPU, memory, handles, or thread counts, but there is no Microsoft-published universal “normal” CPU percentage or RAM limit for DPS. Judge the symptom against your own baseline and reproduce it while recording the PID-level evidence.
#1 Best Overall
For a gaming PC, the practical concern is contention: sustained background CPU use can reduce headroom for a game, while memory pressure can increase paging and worsen stutter. Those effects depend on the rest of the system; the Service Host label alone does not establish that DPS caused a frame-rate problem.
Identify the actual process and service first
1. Record the high-usage PID in Task Manager
- Press Ctrl+Shift+Esc to open Task Manager.
- On the Processes tab, click the CPU or Memory column to sort by the resource that is elevated.
- Expand the relevant Service Host row if Task Manager offers an expansion arrow. Note every service listed under it.
- Open the Details tab, locate the matching
svchost.exe, and record its PID. If several rows look similar, match the PID shown in the expanded service view. - Check the Services tab for the service name
DPS. A high-usage host that does not contain DPS is not a DPS incident, even if its display name looks similar.
Capture the observation before ending a process or restarting Windows. A short note containing the time, CPU percentage, memory working set, PID, and services in that host gives you something to compare after each change.
2. Correlate activity in Resource Monitor
Press Win+R, enter resmon, and press Enter. Resource Monitor lets you correlate the PID with CPU, memory, handles, threads, and disk or network activity. On the CPU tab, use the process list and service list to select the recorded PID. On the Memory tab, compare the process working set and hard faults with overall memory pressure. A high handle or thread count can point to a broader service or provider problem rather than a simple one-time diagnostic task.
Resource Monitor does not by itself prove which service is faulty when several services share a host. It supplies the measurements you need before and after an attribution test.
Prove whether DPS owns the load
Use the service mapping built into Windows
Open an elevated Command Prompt or Windows Terminal and run:
tasklist /svcFind the recorded svchost.exe PID in the output and inspect the services listed on that line. If DPS is absent, investigate the services that are present instead. If DPS is present with several other services, the shared CPU or memory number still cannot be assigned to DPS alone.
Microsoft’s performance guidance recommends temporarily moving a suspect service into its own Service Host process when a shared host contains multiple services. This creates a clean before-and-after attribution test.
Recommended Free Tools
Temporarily isolate DPS
- Open Windows Terminal (Admin) or Command Prompt (Admin). Administrative elevation is required to change service configuration.
- Run the command exactly as shown, including the space after
type=:
sc config DPS type= own- Restart DPS from the Services console: press Win+R, enter
services.msc, press Enter, select Diagnostic Policy Service, and choose Restart if available. If Restart is unavailable, stop and start the service only if Windows permits it. - Recheck Task Manager and Resource Monitor. Use
tasklist /svcagain to confirm that DPS now has a separatesvchost.exePID. - Reproduce the high-load condition long enough to compare CPU, memory, handles, and threads with the original shared host.
If the load follows the new DPS-only process, DPS is implicated. If the original host remains busy elsewhere, another service was responsible. If the symptom disappears, that is evidence about the timing or trigger, not proof of a permanent fix.
Restore the shared configuration
Isolation changes the service grouping and should not be left in place unnecessarily. After collecting your evidence, run this command in an elevated terminal:
sc config DPS type= shareRestart DPS or reboot Windows, then verify with tasklist /svc that normal grouping has returned. The setting is reversible; restoring it does not erase event logs or other evidence you collected.
Check for WMI Provider Host and other look-alikes
A common misattribution occurs when WMI Provider Host (WmiPrvSE.exe) is consuming resources near the same time as a Service Host row. WMI providers can be triggered by drivers, management software, hardware utilities, or another Windows component. Microsoft’s WMI troubleshooting guidance recommends recording the WMI process PID and collecting CPU, memory, handles, threads, and user information before assigning blame.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11- In Task Manager’s Details tab, locate the high-usage
WmiPrvSE.exeinstance and record its PID. - Use Resource Monitor to observe whether that PID, rather than the DPS host, owns the sustained activity.
- Run
tasklist /svcand compare the recorded PIDs. Do not stop a WMI process or a shared Service Host merely because it is visible; first establish which process is actually consuming resources.
If WMI is the owner, continue the investigation through the responsible provider, recent driver or software changes, and relevant event records. DPS isolation will not repair an unrelated WMI provider.
Investigate triggers without assuming a cause
Once you have a DPS-only PID and a reproducible symptom, inspect context around the time of the spike:
- Windows updates: note whether the behavior began immediately after an update. Correlation narrows the timeline but does not prove the update is defective.
- Driver or utility changes: record newly installed graphics, chipset, network, peripheral, monitoring, or security software. These can create diagnostic work, but a machine-specific trace is needed before naming one as the cause.
- Scheduled diagnostics: observe whether the spike occurs at a repeatable time or after a device connects, wakes from sleep, joins a network, or launches a game.
- Event Viewer: open Event Viewer and review Windows Logs around the recorded timestamp. Use the entries as supporting context; an event appearing at the same time is not automatically the root cause.
Keep a small timeline with the timestamp, PID, CPU and memory readings, active game or application, recent system change, and any relevant event IDs. This is more useful than repeatedly killing the process because it lets you compare a symptom with a specific trigger.
Choose the least disruptive troubleshooting path
| Approach | Attribution quality | Reversibility | Functionality impact | Evidence produced |
|---|---|---|---|---|
| Task Manager and Resource Monitor | Identifies the process and measures its activity; shared-service ownership may remain ambiguous | Immediate; no configuration change | None | CPU, memory, handles, threads, PID, and activity correlations |
tasklist /svc mapping |
Shows which services are attached to a PID | Immediate; no configuration change | None | Service-to-process mapping |
sc config DPS type= own isolation |
High when the shared host contains multiple services | High; restore with sc config DPS type= share |
DPS diagnostics may stop while the service is restarted or unavailable | A DPS-only PID and before/after resource comparison |
| Stopping or disabling DPS | Low as a root-cause test if used without PID measurements | Reversible, but disruptive | Diagnostics dependent on Diagnostic Service Host or Diagnostic System Host stop functioning | Only a temporal change in the symptom |
The least disruptive sequence is therefore measurement, service mapping, temporary isolation if necessary, and restoration. Do not skip directly to disabling a Windows service simply because its resource number looks large.
Free tools Windows power users keep installed
One-click scans. No signup required.
What not to do
Do not treat the label as malware evidence
“Service Host” and svchost.exe are normal Windows components. Suspicion should be based on the executable path, signature, unexpected behavior, or other machine-specific evidence—not the name alone. Microsoft identifies DPS as a built-in Windows service, not as malware.
Best Value
Do not kill a shared svchost blindly
Ending a shared host can terminate several unrelated services at once and may interrupt networking, updates, audio, or other functions. If you must stop anything for testing, identify the service and PID first and prefer the reversible isolation procedure.
Do not promise that disabling telemetry will fix DPS
Microsoft’s diagnostic-data documentation distinguishes required and optional diagnostic data and lists excessive resource utilization as a performance category. It does not establish that telemetry itself causes a particular DPS CPU or memory spike. Changing diagnostic-data policy is therefore not a proven remedy for this incident.
Do not invent a “normal” threshold
No authoritative figure establishes a universal DPS CPU percentage, RAM amount, incident rate, or fix-success rate. A brief spike during troubleshooting can be different from sustained usage that coincides with game stutter or system-wide paging. Use your baseline, duration, and PID evidence instead of a copied percentage.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsRecovery checklist after testing
- Confirm whether DPS was actually attached to the high-usage PID.
- Record the before-and-after CPU, memory, handle, and thread readings.
- Restore
DPSto a shared host withsc config DPS type= shareunless a support professional has a specific reason to keep it isolated. - Restart DPS or reboot and verify the service mapping with
tasklist /svc. - Check whether WMI Provider Host or another service, rather than DPS, owns the continuing load.
- Preserve your timeline and event details if you need to contact Microsoft support or a system administrator.
When to escalate
Escalate when high usage remains sustained after restoration, recurs predictably, causes system-wide memory pressure, or is accompanied by service failures, repeated errors, or inability to start required Windows components. Provide the PID, service mapping, Resource Monitor measurements, timestamps, recent changes, and the result of the isolation test. That package lets support distinguish DPS from WMI or another provider without repeating blind stop-and-start experiments.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
