Troubleshooting issues with the SVCHOST.EXE process can be a very frustrating experience for server administrators. Whether the issue manifests as High CPU or the SVCHOST.EXE process crashing, there are some challenges that make the troubleshooting process a little more tricky. So before we dive into the troubleshooting, let's talk about what exactly the SVCHOST.EXE process does. SVCHOST.EXE is a generic host process for services. When you look at the list of running processes in Task Manager, you may see a number of different SVCHOST.EXE processes (as shown below). Each of these processes hosts a group of services.
When the system starts up, SVCHOST.EXE checks the registry to determine which services it should load. The specific registry key is
. A sample is shown below:
Although this gives us useful information regarding which account a particular SVCHOST.EXE is running under, it doesn't necessarily help us with troubleshooting an issue where one instance of SVCHOST.EXE is utilizing a lot of CPU. You may remember an issue several months ago where Windows machines would become unresponsive when scanning for Windows Updates, or an SVCHOST.EXE process would crash when scanning for updates. An issue like that typifies the problems with SVCHOST.EXE troubleshooting. So, if we were to run into another problem with SVCHOST.EXE, how would we go about troubleshooting it?
The first thing to do is understand which services are mapped to which instance of SVCHOST.EXE. Using the TASKLIST.EXE utility we can determine which services belong to which instance. The command syntax is:
tasklist /SVC /FI "IMAGENAME eq svchost.exe"
- the output from this command is below:
Now we have some useful information that we can use to isolate and troubleshoot. Using the information in this output along with the view in Task Manager, we would be able to identify which specific instance of SVCHOST.EXE was consuming the CPU by using the Process Identifier (PID). If you don't have the PID column visible in Task Manager, you can add it by selecting View ... Select Columns and then checking the box for PID. Also ensure that you select the CPU column so you can sort by that to figure out which instance is the culprit. In some cases, simply knowing which processes reside within the culprit instance may be enough - because you can identify what tasks are running on the machine at that time - such as scanning / installing updates at a specific time via WSUS. However, where the problem is not quite so easily identifiable, or the SVCHOST.EXE process itself is crashing, it helps to be able to isolate the services to allow more granular troubleshooting.
To isolate these services, there are two different approaches with very subtle differences. The first method is to create an isolated process that runs within the same SVCHOST group as it did before, just not in a shared process. The second method is to create a completely separate SVCHOST group. Since we've been using Windows Updates as our example, let's continue on with that.
Method 1: Creating an Isolated Process
What this method really does is modify one of the registry parameters for the service in question from a shared process to an isolated process. The command syntax is fairly straightforward and uses the
sc config <service name> type= own
. So for Windows Updates (wuauserv), the command would be:
sc config wuauserv type= own
. Note that there is a space between the '=' and 'own' - you must insert that space. Behind the scenes, what happens is that the
registry value is changed from 0x20 (which denotes a shared process) to 0x10 (indicating it has its own process). You can read more about these particular values on the
MSDN Article about SERVICE_STATUS_PROCESS Structure
. In order to complete the change, you need to stop and restart the service. To change this service back to being a shared service, run the following command:
sc config wuauserv type= share
. For this change to complete, the machine itself needs to be rebooted. No other parameters are being modified with respect to this service, however when you change the type to isolated, restart the service and then run the tasklist command to get the list of services, you will notice that there is an SVCHOST.EXE process that only contains the Windows Update service.
Method 2: Creating an isolated Service Group
This method is a bit more involved, and involves directly editing the registry. Please remember to back up the registry before making any changes! The process is below:
Create a new REG_MULTI_SZ value named WindowsUpdates in the
Add the name of the service (in this case
) to the value. You also need to remove the
from the list in the
value to prevent conflicts.
Now navigate to the
key and change the
%systemroot%\system32\svchost.exe -k netsvcs
%systemroot%\system32\svchost.exe -k WindowsUpdates
Restart the Automatic Updates service and you should now see a new instance of SVCHOST.EXE that only contains the Automatic Updates service.
This method can be repeated to isolate multiple services into their own groups.
To revert back to the original configurations, reverse the steps above and restart the machine. Use the backup of the registry to ensure that you get the right services back into the proper groups.
An additional refinement to this method would be to create copies of SVCHOST.EXE that are appropriately named for the isolated service - for example copy %systemroot%\system32\svchost.exe to a new file named %systemroot%\system32\svchost_wuauserv.exe. Remember that you will need to make the appropriate modifications to the ImagePath value in the registry that reflect the name of the executable file. By customizing the executable, you can use tools such as the
Debug Diagnostic Toolkit that we covered in an earlier post
to monitor specific services for crashing. You can also quickly tell which services are misbehaving in Task Manager as well as getting the name of the failing executable logged in the Event Viewer in the event of that service crashing.
And that brings us to the end of this post. As always be extremely careful when editing the registry directly. Until next time ...