More on Isolating Shared Services in Windows

Previously (Troubleshooting Performance Issues with Automatic Updates / How to Isolate A Shared Service Hosted by SVCHOST.EXE) I had detailed some steps that one could follow to isolate a shared service hosted by SVCHOST.EXE, in the context of the Windows Update Automatic Updates service. There are a couple of other ways to isolate a shared service, with different implications.

The intention / desire of a service to be "shared" or not is typically indicated when the service is created - the fifth parameter to CreateService is dwServiceType, which for our interests can be, among other things, SERVICE_WIN32_OWN_PROCESS (0x10) or SERVICE_WIN32_SHARE_PROCESS (0x20). Once a service has been created, the dwServiceType setting can be changed by calling ChangeServiceConfig with the appropriate parameters.

Windows XP and Server 2003 ship with a utility program called "SC.exe". (I seem to recall using SC.EXE on NT 4.0, after it was included in some resource kit, but I could be mistaken. The DLL Help Database listing for SC.EXE puts the earliest version as having shipped with Visual Studio .NET 2002.) SC presumably stands for "Service Controller". At any rate, one can use SC to change the configuration of a service, including the "service type" - "shared" or "own". So, using wuauserv - the Windows Update Automatic Updates service - as a guinea pig, one could execute from a CMD prompt:

sc config wuauserv type= own
to cause the service to run in its own process. (The service will need to be restarted for this to happen.) To change it back to a shared service, use the following command:

sc config wuauserv type= share
Note that in both commands, the space after the '=' character is critical. For this change (back to "shared") to take effect, the system will likely need to be rebooted as the "original" SVCHOST group that this service was a part of is already running. This is also the case when un-doing the configuration to make the service run in its own SVCHOST group.

The SC commands above are actually just manipulating the registry - you could make the change directly to achieve the same outcome. The setting in question (again, using wuauserv as a guinea pig) is located at [HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\wuauserv] - the "Type" REG_DWORD value. The type corresponds to the aforementioned dwServiceType, which can be (for our purposes here) SERVICE_WIN32_OWN_PROCESS (0x10) or SERVICE_WIN32_SHARE_PROCESS (0x20). To isolate the service, set type to 0x10, and to undo the change, set type back to 0x20 (keeping in mind the restart considerations previously mentioned).

Another thing to keep in mind is the consideration that perhaps a service is not meant to be isolated; those concerns are discussed a wee bit more here.

One subtle difference in techniques is that if you isolate a service into its own SVCHOST group, the command line for the svchost.exe process changes to reflect the group name you speficied when setting up the configuration. However, if you use the SC.EXE / "Type" registry value change technique, the command line for the svchost.exe process remains the same - in the case of wuauserv, the "netsvcs" group is still specified on the command line even though the SVCHOST instance will only be hosting one service.



Anonymous said...

Thank you for taking the time to help others with this vexing problem. The hotfixes from Microsoft, to date, have not worked for me.

Here is how I found you and your solution(s):


Anonymous said...

It seemed to help me too. I split out the wuauserv and used Process Explorer to just bump the priority of the svchost that contained the wuaserv, and I don't seem to have the problem anymore, even though my system is still forced by the network to check for updates every hour.

Anonymous said...

(I'm the anon who posted above) Whoops, I meant to say "bump down the priority" --

«/\/\Ø|ö±ò\/»®© said...

This may also prove useful in automating the lowering of the process' priority:

Setting the Priority of a Service Process via Script

Anonymous said...

A question considering changing type= own in a svchost process.

From what I know, svchost.exe reads the corresponding entry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost to list the service names to a corresponding entry (ex: netsvc). According to the documentation svchost 'notifies the SCM that it is hosting those services when Svchost registers with the SCM'

When one changes type= own in one of the services (ex: wuauserv), there are 2 svchost running with the same services set, registering the same set of service names.

How does the service manager know which instance runs 'wuauserv'? Is there a risk the wrong svchost is asked if the service is running ???

«/\/\Ø|ö±ò\/»®© said...

Hi Anonymous,

>> there are 2 svchost running with the same services set, registering the same set of service names. <<
No. The "group" of services as configured are loaded, for the services that are of type "share". A separate instance of svchost.exe runs for each service configured as type "own".