After Windows 10 Fall Creators Update, a svchost.exe instance is constantly using CPU time

Question

Since installing the Windows 10 Fall Creators Update, I have a svchost.exe process that is constantly using about 14​ % of CPU time:

This svchost.exe instance is responsible for hosting three services:

The CPU time is consumed by a thread inside that process that Process Hacker cannot attribute to any of these three services:

Given that these three services are considered critical system services, it's hard to do anything about them. These services cannot be stopped or disabled by services.msc, and terminating the process triggers a bugcheck (CRITICAL_PROCESS_DIED). Disabling the Windows Defender Firewall through the settings UI does not reduce CPU usage.

I'm out of ideas. What could be causing this? How can I debug this further? Is there a workaround to stop these services?

---

Update: After some debugging with @HelpingHand, we've isolated this to the Windows Defender Firewall service. Process Monitor shows that it's constantly accessing the registry:

A CSV export of a Process Monitor capture, filtered to that process, is available here.

I’m still looking for a way to stop that behavior.

---

Update 2: Analysis with the Windows Performance Analyzer shows that most CPU time is consumed by code from rpcrt4.dll:

Answer 1

As it turns out, this was related to Internet Connection Sharing (ICS).

In the following, I'd like to describe how I got to this conclusion in hope it helps other people with similar problems.

---

The first step is to identify the service causing trouble. While Windows' own Task Manager has also learned to do this recently, I used Process Hacker which can also edit a service's configuration.

Double-clicking the offending svchost.exe instance and selecting the Service tab shows which services are running inside that process:

svchost.exe can host many Windows services at the same time, making it hard to identify which service is causing trouble. While recent versions of Windows 10 typically isolate services when enough RAM is available, some services still share a process.

This is such a case, and the easiest way to identify which service is causing problems is to separate them.

Process Hacker can do this. In its main windows' Service tab, we can configure whether a service can share a process:

At least two of the three suspect services need to be configured as Own Process to make sure they are separated in the future.

Apparently, Windows Defender doesn't like users meddling with its service's configuration, so to successfully change this setting, I needed to

• grant the Administrators group Full Access on that service,
• disable the service,
• reboot so the service is stopped (it cannot be stopped separately),
• change the service type to Own Process and re-enable the service (set it to Auto Start) and
• reboot one last time to apply these changes.

After that, the offending svchost.exe only hosts a single service, so we do have a suspect:

To analyse what's going inside the firewall service, we'll use the Windows Performance Recorder and Windows Performance Analyzer tool, part of the Windows ADK.

We'll begin by recording some data. While the suspect svchost.exe is chucking along in the background, download this file, add it as a profile, set up Windows Performance Recorder like this and start a recording:

Let the recording run for 30 seconds or so, then save the recording. After saving, click Open in WPA to immediately open it for analysis.

This is where things start to become tricky. In my case, I needed a hint from @magicandre1981 to look in the right place, under System Activity → Generic Events. There, the number of RPC events looked suspiciously high:

Drilling down, the Windows Defender Firewall's svchost.exe was showing up a lot on the Server side of win:Start and win:Stop events:

The next step was finding out who sent these RPC calls. By looking in the client side, another svchost.exe instance was looking suspicious:

Indeed, Process Hacker couldn't detect a service running inside that process, which also was consistently causing CPU load:

In this case, Windows' Task Manager succeeded in identifying the service:

Indeed, the service was stuck in the Starting state. I've disabled it since I don't need it, and CPU load has returned to normal after the next reboot.

---

I'd like to express my gratitude towards @HelpingHand and @magicandre1981 whose help in the comments made this possible.

---

As was later discovered in the TenForums post, resetting Windows Defender Firewall fixes this issue.

Answer 2

It's more simple, I have had success by resetting their Windows Firewall settings (particularly if there's a related spike in CPU load) using this instructions :-

Resetting the Windows Defender Firewall to the default settings resolved the issue.

To do this open Settings -> Update and Security -> Windows Defender -> Open Windows Defender Security Center -> Firewall and Network Protection -> Restore Firewall default settings

Hope this helps and works for someone else... Seems like a fairly widespread issue.

Answer 3

In my case, after trying various unsuccessful fixes (including some of the above suggestions e.g. resetting Windows Firewall), I disabled the "Diagnostic Policy Service", and CPU hogging finally ceased. This may not be the ideal solution, but it doen't seem to be a critical service. Here's how to disable it :

1. Open "System Configuration" ('msconfig.exe') as admin
2. General tab : choose "Selective startup"
3. Services tab : uncheck "Diagnostic Policy Service"
4. Reboot Windows

Thanks to Ranga Rajesh Kumar's YouTube channel for pointing me toward this solution.