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
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.