Previously (here and here), I've written about isolating shared services so that they run in their own process, with a specific focus on the Windows Update Automatic Updates Service (wuauserv) that typically runs in the NETSVCS SVCHOST.EXE instance. One thing that can be done once this is accomplished is to lower the priority of the process so that when the service winds up consuming 100% of the CPU, the system doesn't become unresponsive.
Since we're dealing with a service, setting the priority of such a SVCHOST.EXE process can become problematic - the service may already be running, or, because it is a service, it is not started as non-service processes are, so one is not able to use START / [LOW NORMAL HIGH REALTIME ABOVENORMAL BELOWNORMAL] to impose a priority when the process starts. One can use a utility like Task Manager or Process Explorer to set the priority of a process on an ad hoc basis, but when the service restarts or the system reboots one has to remember to set the priority again.
Though not an ideal solution the following scripts (VBS using WMI, and PowerShell) can be used to set the priority of the SVCHOST.EXE instance hosting the isolated Windows Update Automatic Updates Service service to "below normal". Note that no check is done to ensure that the SVCHOST.EXE instance is only hosting one service - if wuauserv is found to be a service inside of the process, the priority is adjusted. Note also that no error handling is implemented.
I'll try to format the code so it looks nice, but I fear I will be limited...
Here's the code for the VBS / WMI script:
Const BELOW_NORMAL = 16384
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colServices = objWMIService.ExecQuery( _
"SELECT * FROM Win32_Service where name='wuauserv'")
For Each oService in colServices
Set colProcesses = objWMIService.ExecQuery( _
"SELECT * FROM Win32_Process where ProcessId=" & oService.ProcessId )
For Each oProcess in colProcesses
oProcess.SetPriority(BELOW_NORMAL)
Next
Next
Here's the code for the PowerShell script:
(gps -id (get-wmiobject win32_service where {$_.name -eq "wuauserv"}).ProcessId).PriorityClass="BelowNormal"
The different values for the priority parameter of the SetPriority method of the Win32_Process WMI class can be found in the documentation for the SetPriority method.
The different values for the PriorityClass in the PowerShell script are "Normal", "Idle", "High", "RealTime", "BelowNormal", or "AboveNormal". Or, to get a list of the available options, one can use the following PowerShell command:
[ENUM]::getNames("System.Diagnostics.ProcessPriorityClass")
Once the script is in place and working, one can cause it to be invoked at will, or via scheduled task at specific times, or after logon, or any other way that one can get something to happen when Windows boots or a user logs on.
»
Written by «/\/\Ø|ö±ò\/»®© on May 1st, 2007 with comments disabled.
Read more articles on Automatic Updates and Process Explorer and SVCHOST and Shared Services and Troubleshooting and WUAUSERV and Windows Update and cpu utilization and netsvcs and processes and 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.
»
Written by «/\/\Ø|ö±ò\/»®© on February 8th, 2007 with comments disabled.
Read more articles on Automatic Updates and SVCHOST and Shared Services and Troubleshooting and Windows Update and windows.
...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.
»
Written by «/\/\Ø|ö±ò\/»®© on January 28th, 2007 with comments disabled.
Read more articles on Automatic Updates and SVCHOST and Shared Services and Troubleshooting and Windows Update and netsvcs and windows.