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

graph of CPU utilization

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

Base Filtering Engine, CoreMessaging, Windows Defender Firewall

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

screenshot from Process Hacker

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:

screenshot from Process Monitor

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:

screenshot from Windows Performance Analyzer

  • 1
    If you run the following 2 commands in an admin prompt and restart; if any, which svchost process is causing the high CPU then: Sc config BFE type= own then Sc config MpsSvc type= own Commented Oct 19, 2017 at 18:56
  • 1
    As you have Process Hacker already, if you find the svchost process that is hosting BFE for example. If you double click on service name in the services tab, then view the security tab, I would have thought Administrators would have modify configuration rights. The above works for me. Commented Oct 19, 2017 at 20:11
  • 1
    Maybe you can now run Process Monitor with it filtered to that PID. See what shows up. Commented Oct 19, 2017 at 20:50
  • 1
    It does on my computer as well. TBH, I think your best bet is to install the Windows Performance Toolkit tools - docs.microsoft.com/en-us/windows-hardware/test/wpt. Essentially you'll be using Windows Performance Recorder to capture a trace file and Windows Performance Analyzer to analyze it. channel9.msdn.com/Shows/Defrag-Tools has some good shows on these. Commented Oct 19, 2017 at 21:39
  • 1
    don't sort by module. remove this column. also trace the RPC events. download this file, run WPRUI.exe, click on add profile, select the downloaded WPRP, select CPU Usage Profile and Network Usage profile under Custom measurements. click on start and capture the usage for 30s. now look which PID has the high cpu usage and in generic events graph/table filter for the exe with the high usage and RPC events and look which rpc action are done Commented Oct 20, 2017 at 14:13

3 Answers 3


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 (1688) Properties

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:

MpsSvc Properties

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:

Windows Defender Firewall (MpsSvc)

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:

Windows Performance Recorder: check First level triage and CPU Usage Profile

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 ActivityGeneric Events. There, the number of RPC events looked suspiciously high:

46.918 Microsoft-Windows-RPC events

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:

Service group name: netsvcs

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

Internet Connection Sharing (ICS)

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.

  • @HelpingHand: what happens if one disable the Internet Connection Sharing (ICS) services? Will WiFi Hotspot no longer be an option?
    – llinfeng
    Commented Nov 12, 2017 at 0:46
  • This is slightly easier within Process Explorer. If you right click the "svchost.exe" which is utilizing a constant processor amount (my case was 5% constant) and click the "Services" tab you'll see what service(s) are running under this svchost. I had only one in this case, ICS. Similarly my Internet connection sharing was stuck in a starting state. Going to "Firewall & Network Protection" I was able to click "Restore firewalls to default" - this instantly fixed my problem. Commented Apr 3, 2018 at 13:49
  • @Howard: Consider yourself lucky – one mayor complication for me was three services sharing the problematic instance of svchost.exe, making it hard to identify the service causing this. I'm not sure why they didn't share a host process in your instance.
    – fefrei
    Commented Apr 3, 2018 at 17:09

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.

  • 1
    Indeed, this also worked for me, as I mentioned at the very bottom of my answer. Thanks for mirroring the steps here!
    – fefrei
    Commented Mar 11, 2018 at 13:50

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .