...or,
How to Isolate A Shared Service Hosted by SVCHOST.EXEThere are a number of articles in the Microsoft Knowledge Base about performance issues with Windows Update / Microsoft Update, as well as
other problems related to the scanning mechanisms used by automatic-type update services. There are some
fixes, and
fixes for some fixes, but no "ultimate" solution. Stepping back a bit, how can you even determine if Automatic Updates is causing performance issues on your system?
The Automatic Updates service is not a stand-alone process, so it is not sufficient to simply look for which process is consuming the most CPU time or the most memory. Rather, Automatic Updates is integrated into the "
netsvcs" SVCHOST service hosting instance. On the systems that I have examined, this instance hosts over 20 services - 25 services on the system I am using to write this. How can you see what services are running inside of a process? One way is to use "
tasklist /svc", and examine the "Services" column. Another way is to use
Process Explorer - simply hover the mouse pointer over a process and any services that are contained in the process are listed in a tooltip. Or, view the Process' "Properties" page and examine the "Services" tab for more details.
This sharing of services in one process isn't a bad thing - Windows has been doing this for some time. There are times when it makes sense, and times when it doesn't. Basically, processes are expensive and the more you have the more resources they consume. If you are able to share services in the address space of a process, you are conserving resources. But if the services have different security needs, for example, then you should probably split them into two separate processes to "isolate" the functionality that requires greater privileges.
Back to the task at hand... The fact that services can share a process is nice, but this really gets in the way of troubleshooting a service you suspect may be causing problems. So it can be useful to extract a shared service and make it run in its own process. With services hosted by SVCHOST, the configuration is controlled in the registry. Microsoft doesn't publicly document the interfaces for SVCHOST.EXE as it doesn't want people writing services and making them run in the same address space of processes that host Windows built-in services - if the service is poorly written it can cause SVCHOST.EXE to crash, and subsequently kill all of the other services running in that instance of SVCHOST.EXE. That doesn't mean you can't manipulate the built-in Windows services to use a configuration you desire, though...
The SVCHOST services are controlled by registry settings in
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost]. (Standard warnings about editing the registry apply.) Each REG_MULTI_SZ in this key represents a SVCHOST group containing a list of one or more services to run in an instance of SVCHOST.EXE. So if one wishes to isolate the Automatic Updates service, one needs to find which group it is in. The "name" of the Automatic Updates service is "
wuauserv" - Windows Update Automatic Updates service. This service resides in the "
netsvcs" group. So, since the desire is to create a new SVCHOST instance to run the service in, remove
wuauserv from the list in the
netsvcs value. Then, create a new REG_MULTI_SZ value and give it an appropriate name, such as AutomaticUpdates. Add
wuauserv to this value.
Next, navigate to
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\wuauserv] and change the
ImagePath (which specifies the program and arguments the Service Control Manager is to use to invoke the service) from:
%systemroot%\system32\svchost.exe -k netsvcsto:
%systemroot%\system32\svchost.exe -k AutomaticUpdatesThat's it. Stop and restart the Automatic Updates service (
net stop wuauserv /
net start wuauserv) and you should see a new instance of SVCHOST.EXE that contains only the Automatic Updates service. Now you can monitor the performance of this process, drop its priority (Task Manager or Process Explorer), etc.
The same technique can be applied to isolate other SVCHOST hosted services as well. However, some caution and investigation should be applied on a case-by-case basis- it should be noted that some services may have some dependence on residing in the same address space as another service. This may or may not be intentional; if intentional I suspect that it probably has to have some relation to performance. If not intentional, it is likely a bug.
»
