When the system starts up, SVCHOST.EXE checks the registry to determine which services it should load. The specific registry key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost . 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 command set: 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 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wuauserv\Type 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:
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 ...
|Share this post :|
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.