This is something that's always bothered me, so I'll ask the Server Fault community.

I love Process Explorer for keeping track of more than just the high-level tasks you get in the Task Manager. But I constantly want to know which of those dozen services hosted in a single process under svchost is making my processor spike.

So... is there any non-intrusive way to find this information out?


Yes, there is an (almost) non-intrusive and easy way:

Split each service to run in its own SVCHOST.EXE process and the service consuming the CPU cycles will be easily visible in Process Explorer (the space after "=" is required):

SC Config Servicename Type= own

Do this in a command line window or put it into a BAT script. Administrative privileges are required and a restart of the computer is required before it takes effect.

The original state can be restored by:

SC Config Servicename Type= share

Example: to make Windows Management Instrumentation run in a separate SVCHOST.EXE:

SC Config winmgmt Type= own

This technique has no ill effects, except perhaps increasing memory consumption slightly. And apart from observing CPU usage for each service it also makes it easy to observe page faults delta, disk I/O read rate and disk I/O write rate for each service. For Process Explorer, menu View/Select Columns: tab Process Memory/Page Fault Delta, tab Process Performance/IO Delta Write Bytes, tab Process Performance/IO Delta Read Bytes, respectively.


On most systems there is only one SVCHOST.EXE process that has a lot of services. I have used this sequence (it can be pasted directly into a command line window):

rem  1. "Automatic Updates"
SC Config wuauserv Type= own

rem  2. "COM+ Event System"
SC Config EventSystem Type= own

rem  3. "Computer Browser"
SC Config Browser Type= own

rem  4. "Cryptographic Services"
SC Config CryptSvc Type= own

rem  5. "Distributed Link Tracking"
SC Config TrkWks Type= own

rem  6. "Help and Support"
SC Config helpsvc Type= own

rem  7. "Logical Disk Manager"
SC Config dmserver Type= own

rem  8. "Network Connections"
SC Config Netman Type= own

rem  9. "Network Location Awareness"
SC Config NLA Type= own

rem 10. "Remote Access Connection Manager"
SC Config RasMan Type= own

rem 11. "Secondary Logon"
SC Config seclogon Type= own

rem 12. "Server"
SC Config lanmanserver Type= own

rem 13. "Shell Hardware Detection"
SC Config ShellHWDetection Type= own

rem 14. "System Event Notification"
SC Config SENS Type= own

rem 15. "System Restore Service"
SC Config srservice Type= own

rem 16. "Task Scheduler"
SC Config Schedule Type= own

rem 17. "Telephony"
SC Config TapiSrv Type= own

rem 18. "Terminal Services"
SC Config TermService Type= own

rem 19. "Themes"
SC Config Themes Type= own

rem 20. "Windows Audio"
SC Config AudioSrv Type= own

rem 21. "Windows Firewall/Internet Connection Sharing (ICS)"
SC Config SharedAccess Type= own

rem 22. "Windows Management Instrumentation"
SC Config winmgmt Type= own

rem 23. "Wireless Configuration"
SC Config WZCSVC Type= own

rem 24. "Workstation"
SC Config lanmanworkstation Type= own

rem End.

While I don't know of easy way to do it directly, you can often infer it from the Process Explorer properties page for the svchost process. The Services tab on the process properties will tell you which services are hosted in that process. And the Threads tab will show you the threads and thread stacks running as well as their CPU usage. Often the Start Address on the thread will give an indication of the entry point DLL, and by extension the service, that's running on that thread. Other times you can look at the thread callstack and will see the module name in the call stack that tells you which piece of code is running.


Try Service Disclosure tool. It:

  1. Stores services which share svchost.exe process.
  2. Configures services to run in separate process. After reboot you will see each service in separate process.
  3. Returns all stored at step #1 services back to one process.

Your comments and suggestions are welcome.

@Peter Mortensen: Thanks for idea.


Caution: Please take the necessary research, restore point and backup procedures before applying this, as well as check that everything is still working afterwards. It is possible to recover from this through the Recovery Environment only on non-RAID systems, as well as Safe Mode on both RAID and non-RAID systems. This has been tested on a developer machine, not on servers.

In Powershell, you can do this for all non-lsass services using the following commands:

Get-Service | ForEach-Object `
    { SC.EXE config $_.Name type= own }
ForEach ($svc in @("efs", "keyiso", "netlogon", "policyagent", "samss", "vaultsvc", `
    "was", "w3svc")) `
    { SC.EXE config $svc type= share }

The list that is excluded here all need to run in a shared lsass.exe, with the exception of policyagent, which is required for the group policy agent to communicate properly during boot.

Also recently discovered that was (Process Activation) and w3svc (IIS World Wide Web) need to share their processes, so they have been added to the exclusions.

This has been tested on Windows 10 (1607, build 14393.953), the exclusions are different in XP, ....