Error 0x8007052e from Windows Media Services

Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

I was recently working on getting Windows Media Services configured on a system. Going through the properties, I noticed that the "WMS Anonymous User Authentication" plugin was in an error state. On inspection, I was presented with the following dialog.

---------------------------
Windows Media Services
---------------------------
The plug-in cannot be enabled because the user name or password does not match the settings for the Windows user account used for anonymous guests.
---------------------------
OK
---------------------------

Also, the event viewer was showing the following:

Event Type: Error
Event Source: WMServer
Event Category: Plugin
Event ID: 323
Date: [Date]
Time: [Time]
User: N/A
Computer: [CompName]
Description:
Plug-in 'WMS Anonymous User Authentication' on the server failed with the following information: Error code = 0x8007052e, Error text = 'Logon failure: unknown user name or bad password. '.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 8007052e

Checking "Local Users and Groups", I could see that the specified user (WMUS_COMPNAME) certainly existed. I changed the password for the user and then set the password in the properties for "WMS Anonymous User Authentication". I was rewarded with the same message. The user name and password were correct, so I focused my attention elsewhere. I first tried changing the settings to provoke the message while running Sysinternals' Filemon and Regmon, but was unable to pull anything from the captured data that seemed like it was germane to the problem.

The next thing I tried was creating a new account and specifying that account in the properties for "WMS Anonymous User Authentication". This worked; the status of "WMS Anonymous User Authentication" became "Enabled". I found this odd, as I was working with a fresh installation of Windows Media Services. In comparing the accounts (WMUS_COMPNAME and the test account I created), I noticed the WMUS_COMPNAME account was just a member of the Guests group, while the test account was just a member of the Users group. So, I added the test account to Guests and removed it from Users, and then checked / OK'd the "WMS Anonymous User Authentication" properties. I got the aforementioned message. I changed the test account back to the original group memberships, and "WMS Anonymous User Authentication" did not complain.

At this point, I knew that the problem was related to some restriction placed on the Guests group. I ran secpol.msc to check the Local Security Policy Settings, and I noticed that Guests had been added to the Security Setting for the "Deny access to this computer from the network" policy. According to TechNet, the default for this policy is "None". Removing Guests from the setting allowed the WMUS_COMPNAME account to function as the anonymous account used by Windows Media Services.

Handle Leak in Apple's mDNSResponder.exe

A while ago, I noticed a handle leak in Apple's "Bonjour Service" (yeah, that sounds like something I want running on my system...) - mDNSResponder.exe. I knew right away that that was the executable for the "Bonjour Service" because the name is so helpful. (Joking. Even if it was named after the service, how the heck would I even guess what the "Bonjour Service" did. But I digress...)

The service description is:

Bonjour allows applications like iTunes and Safari to advertise and discover services on the local network. Having Bonjour running enables you to connect to hardware devices like Apple TV and software services like iTunes sharing and AirTunes. If you disable Bonjour, any network service that explicitly depends on it will fail to start.

I put up with the leak for a while, from time to time stopping the service when I thought of it after booting. Most of the time I didn't think of it and the leak did not appear to be having any kind of performance impact on my system (I never saw it get above 80,000 handles). An update (or two?) later, I thought it would be fixed. So I was surprised to find mDNSResponder.exe had more than 55,000 handles when I checked recently with Sysinternals' Process Explorer.

I tried to use Process Explorer's handle pane to see the handles in mDNSResponder.exe, but with that many handles to display, and with Process Explorer running with its default High priority and refreshing every second, the system became rather sluggish. I dropped the priority of Process Explorer with Task Manager, hid the lower-pane view, and gave Handle.exe a shot with handle.exe -a -p mdnsresponder.exe.

I found that the handles being leaked are handles to registry keys - specifically, HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters. (ControlSet001 is the current control set on my system.)

Since there's not much I can do about the handle leak, I'll disable the service, and hope the next update fixes the problem as surely the next update will set the service to Automatic start. Wonder why the installer doesn't at least set a service such as this as "Delayed Start" in Vista...

In Vista, How Does the FLAGS Switch of REG.EXE Work?

Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

A while back, there was a topic (Virtual Registry vs. "Real registry") in the Sysinternals Forums that brought up the question of how to set the virtualization-related flags of a registry key programmatically in Vista, rather than through the use of the REG.EXE tool's FLAGS switch. (For more information on the flags, see Mark Russinovich's article in TechNet Magazine, "Inside Windows Vista User Account Control"). Even before that topic in the forum, I had wondered how it was done but had not had a chance to explore. It didn't seem that many others were curious about it. That topic had resurrected the idea, but it quickly fell to the bottom of the list. I've finally gotten around to experimenting, and that leads to this write-up. I still don't see much in the way of this discussed anywhere, by searching for terms involved (data types, function param names, etc.), so hopefully this will help someone. (Keep in mind that there very well may be a reason Microsoft hasn't made this available through another, more direct API.)

In the referenced topic, I had gotten so far as determining that REG.EXE was doing its work through the use of NtSetInformationKey, an "undocumented" API in NTDLL.DLL.

NTSYSAPI 

NTSTATUS

NTAPI

NtSetInformationKey(

  IN HANDLE               KeyHandle,

  IN KEY_SET_INFORMATION_CLASS InformationClass,

  IN PVOID                KeyInformationData,

  IN ULONG                DataLength );

After a bit of plonking around in WinDbg, I've come up with the following following details. REG.EXE calls NtSetInformationKey, specifying a value of 2 for the InformationClass parameter. This parameter is of type KEY_SET_INFORMATION_CLASS, which wdm.h tells us is an enum:

typedef enum _KEY_SET_INFORMATION_CLASS {

    KeyWriteTimeInformation,

    KeyWow64FlagsInformation,

    KeyControlFlagsInformation,

    KeySetVirtualizationInformation,

    KeySetDebugInformation,

    MaxKeySetInfoClass  // MaxKeySetInfoClass should always be the last enum

} KEY_SET_INFORMATION_CLASS;

So the 2 for the InformationClass parameter would correspond to KeyControlFlagsInformation. WDM.H also suggests that this class has a type that one passes for the KeyInformationData parameter - KEY_CONTROL_FLAGS_INFORMATION:

typedef struct _KEY_CONTROL_FLAGS_INFORMATION {

    ULONG   ControlFlags;

} KEY_CONTROL_FLAGS_INFORMATION, *PKEY_CONTROL_FLAGS_INFORMATION;

We have a basic idea of how to call NtSetInformationKey now. But what are the values that the ControlFlags member of KEY_CONTROL_FLAGS_INFORMATION can be set to? It would appear that the following (self-made) enum covers the pertinent flags - at least the ones REG.EXE FLAGS can handle (there may be more):

typedef enum _CONTROL_FLAGS {

    RegKeyClearFlags = 0,

    RegKeyDontVirtualize = 2,

    RegKeyDontSilentFail = 4,

    RegKeyRecurseFlag = 8

} CONTROL_FLAGS;

The control flags are a bitmask, so you can OR them to set more than one.

Now that we have this information, what's left? We need to put it all together in a call to NtSetInformationKey. So, we need to get a pointer to the function in NTDLL.DLL. Then, we can declare a struct of type KEY_CONTROL_FLAGS_INFORMATION, set the ControlFlags member to be what we wish, and open a key to the desired location in the registry, that can be passed to NtSetInformationKey. In the end, we wind up with something like the following (error handling has been omitted):

typedef NTSYSAPI NTSTATUS (NTAPI* FuncNtSetInformationKey) (

  HANDLE KeyHandle,

  KEY_SET_INFORMATION_CLASS InformationClass,

  PVOID KeyInformationData,

  ULONG DataLength ); 

//... 

FuncNtSetInformationKey ntsik = (FuncNtSetInformationKey)GetProcAddress( 

          GetModuleHandle( _T("ntdll.dll") ), "NtSetInformationKey" ); 

KEY_CONTROL_FLAGS_INFORMATION kcfi = {0}; 

kcfi.ControlFlags = RegKeyDontVirtualize | RegKeyRecurseFlag; 

HKEY hTheKey = NULL; 

RegOpenKeyEx( HKEY_LOCAL_MACHINE, _T("SOFTWARE\\Whatever"), 0, KEY_ALL_ACCESS, &hTheKey ); 

ntsik( hTheKey, KeyControlFlagsInformation, &kcfi, sizeof( KEY_CONTROL_FLAGS_INFORMATION ) ); 

RegCloseKey( hTheKey ); 

hTheKey = NULL;

The code above is the equivalent of invoking REG.EXE FLAGS HKLM\Software\Whatever SET DONT_VIRTUALIZE RECURSE_FLAGS. To clear the flags, just set kcfi.ControlFlags to RegKeyClearFlags (same as REG.EXE FLAGS HKLM\Software\Whatever SET).

Hopefully, this will prove useful to those that have wished to set these flags programmatically. In a future post, I hope to explore querying for these flags, ala REG.EXE FLAGS HKLM\Software\Whatever QUERY.

Note that this exploration was done on Windows Vista SP1. I would expect the content here to also apply to Windows Vista (no SP) as well as Windows Server 2008, but...

My Answer to "Microsoft Advanced Windows Debugging and Troubleshooting" Puzzler 3

Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

Previously, I had written about the puzzlers on the NTDebugging / Microsoft Advanced Windows Debugging and Troubleshooting blog - specifically, the most recent puzzler which involved reverse engineering some assembler. The answer was posted today - there were a lot of responses, and a lot of correct responses.

I had posted the hashes for my answer (which was correct), that I am now able to disclose...

void myfun( char* param1 )
{
    size_t local1 = strlen( param1 );
    for( int local2 = local1; local2 > 0; local2-- )
    {
        for( int local3 = 0; local3 < local2 - 1; local3++ )
        {
            if( *(param1+local3) > *(param1+local3+1) )
            {
                char local4 = *(param1+local3);
                *(param1+local3) = *(param1+local3+1);
                *(param1+local3+1) = local4;
            }
        }
    }
}

Microsoft Advanced Windows Debugging and Troubleshooting Puzzlers

Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

Over on the Microsoft Advanced Windows Debugging and Troubleshooting blog, they've been posting a "Puzzler" every Monday and providing the answers the following Friday.

The puzzlers are fun to participate in and it is interesting to read people's responses - everyone has their own ideas and own experiences to draw off of.

With the third puzzler, the blog authors have decided to make the challenge a bit more difficult - the latest puzzler requires one to reverse engineer some assembler.

I've not got much experience with reverse engineering assembler - I can read some assembler and can usually get a very basic idea of what a targeted chunk of code is doing. So it was an interesting challenge for me to attempt to C-ify the assembler they provided. It doesn't appear that the authors are posting the responses until they reveal the answer (makes sense to me!). But I thought I'd post hashes of my response, which I'll also post once the NT Debugging blog authors post the answer and submitted comments / responses.

From Sigcheck:

Z:\NTDebuggingPuzzler3>sigcheck -h TheFunc.txt

Sigcheck v1.52
Copyright (C) 2004-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

Z:\NTDebuggingPuzzler3\TheFunc.txt:
Verified: Unsigned
File date: 12:52 PM 4/22/2008
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 755394f9711b80968f17c8ffcb8f2394
SHA1: e8443f09eef43f2575aa08ba25f68267dba7243e
SHA256: 0e044419ef78f2fa7a8e258098f4f658426a8dc3e8a5b9a121a352c2dbbbfafc

EDIT 2008-04-24: The hashes are for the code that was submitted in my second response (not the entire response - just the code). In my first response, I inadvertently left some garbage in the code (an unnecessary / unused local I had been playing with) and I neglected to remove it before submitting. Not sure how it will all pan out when the comments / responses get posted tomorrow...

An Incoming Request for Troubleshooting Advice

I recently received the following via email. I responded, but never heard back. Hopefully the information will be of use to others...

Hi, Found your name on the web when I was looking at some stuff on slashdot and I thought maybe you might have a moment to point me in the right direction.
I have a custom app which I have zero access to in terms of the developer. When the app was run on new hardware, a few users would periodically get a bizarre error, but never on their old hardware. Main difference seems to be core 2 duo on the new laptops.
Anyway, this error causes a total reset of the internal windows database system used by the app and then there's an error in msvcr80.dll. Is there a way I can tell from the data below what routine went bad in that module? I could at least then tell the guy who guards the gates to tell the developer a little bit more. At this point the "guard" is convinced it is just because the dll is not the latest version. I think it is probably not that simple.

[app].exe signature
Appname [app].exe App. Ver. 0.0.0.0
Mod Name: msvcr80.dll
Mod Ver: 8.0.50215.44
Offsett: 000161fd

Error report contents
Exception info:
Code 0x0000005
Flag 0x00000000
Record 0x000000000000000
Address: 0x000000007C3861fd

I responded with the following:

It does appear that the problem may lie in the version of MSVCR80.DLL you referenced. At least, getting this to an appropriate version seems like a very reasonable first step towards troubleshooting.

According to a dude on the VC++ compiler team (Jonathan Caves @ http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465&SiteID=1&PageID=1 ), version 8.0.50215.44 of MSVCR80.DLL "is not an officially released version"; he links to this site (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 ), which has a statement by another member of the VC++ team (Martyn Lovell):

"a) This is the beta 2 version of msvcr80.dll. Don\'t install it. b) This file should never be installed in system32 (except on Win9x and Windows 2000). c) The .NET framework already installs the copy correctly (in WinSxS). d) The correct source for an msvcr80 binary is from your application provider, not from this site. Martyn"

The MS DLLHelp Database entries for MSVCR80.DLL (http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=msvcr80.dll&S=1 ) indicate that you can get the DLL from "MS SQL 2005 Server Enterprise" or "Microsoft Visual Studio 2005 Professional". Martyn from Microsoft indicates that you should get this DLL from the application provider. He also stated that you can get it as part of the .NET Framework redistributable (version 2.0). It also appears that you can get it as a part of a package from the "Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)" at http://www.microsoft.com/downloads/details.aspx?FamilyID=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en.

FWIW, 0x0000005 is not a valid exception code, though I suspect you meant 0xc0000005, which is the code for an access violation. You're reporting a crash at address 0x7C3861fd. With no other info it is difficult to determine what is loaded at that address (especially since the "shipping" / non-beta versions of MSVCR80.DLL are based at 0x78130000 with a virtual size of 0x9b000), but it seems likely that the beta version of MSVCR80.dll has a different base address (0x7C370000) / size which could/should include the crash address (or, the DLL could have been rebased by the loader).

I suspect that a "Dr. Watson" or "Windows Error Reporting" dump file may have been created from the application crash(es) - these are files with a .dmp extension, and they contain information useful for debugging, or getting more information about, these kinds of problems.

Hope this helps you!

-molotov

Setting the Priority of a Service Process via Script

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.

»

Part 1: Introduction - What's using my CPU?

Recently, I have been involved in attempting to diagnose problems with excessive CPU utilization. Often times, this type of thing is relatively easy to identify - at least as far as pointing the finger at the thing that is consuming CPU cycles. Task Manager can be used for this - simply sort the "CPU" column in descending order and note the process that is at the top of the list. One can use a similar technique with Process Explorer.

In the past (here and here), I've given examples that demonstrate various techniques that can be used to try to determine what a process is doing when it is consuming so much CPU. Sometimes, you can do something about it - if you have the debugging symbols, perhaps there is something in the stack of the thread or threads in the process that is consuming the CPU that will lead you to some setting, feature, or configuration piece that can be manipulated so as to avoid the problem. Or perhaps just knowing the module name is enough information to identify the problem software - a recently installed add-in / plug-in, or a new utility, perhaps. Sometimes you are forced to work around the problem - you don't have any control over it and don't want to stop using the program, or have no choice but to keep using the program.

But what happens when the excessive CPU utilization is not attributable to a "standard" process? In the coming series of articles, I hope to explore some of the things that can be done to diagnose and troubleshoot this type of scenario. Stay tuned...

»

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.

»

Troubleshooting Performance Issues with Automatic Updates

...or,
How to Isolate A Shared Service Hosted by SVCHOST.EXE

There 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 netsvcs
to:
%systemroot%\system32\svchost.exe -k AutomaticUpdates

That'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.

»

Using Process Monitor to Troubleshoot Internet Explorer 7 Performance Issues

[Added 2007-01-18: Fix Available for Performance Problems with Internet Explorer 7's Phishing Filter ...]

Previously, I wrote about sluggish behavior with Internet Explorer 7. I had used Process Explorer to help pinpoint the cause of the sluggishness - in this case, it was Internet Explorer 7's (anti)phishing filter. I could also have used a relatively new tool from Microsoft's Windows Sysinternals - Process Monitor.

In Process Monitor, it is easy to get inundated with all of the data that the tool collects. Filters are very critical to enabling one to find the desired information, and the implementation of filters in Process Monitor is top notch. For this exercise, after starting Process Monitor and checking "Generate Profiling Events" on the "Options" menu, I captured events while exercising the web application with the Phishing Filter set to "Turn off automatic website checking" and "Enabled" for the Security zone the web application was in. After capturing events for a minute or so, I set the following filters:
-Process Name is iexplore.exe then Include
-Event Class is Registry then Exclude
-Event Class is File System then Exclude
-Event Class is Process then Exclude

This displayed all "profiling" events for the iexplore.exe process. I double-clicked an event to bring up the "Event Properties" dialog and clicked on the "Stack" tab, which had the following information:

ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject + 0x12
ole32.dll!GetToSTA + 0x6f
ole32.dll!CRpcChannelBuffer::SwitchAptAndDispatchCall + 0xf6
ole32.dll!CRpcChannelBuffer::SendReceive2 + 0xb9
ole32.dll!CAptRpcChnl::SendReceive + 0xab
ole32.dll!CCtxComChnl::SendReceive + 0x113
RPCRT4.dll!NdrProxySendReceive + 0x43
RPCRT4.dll!NdrClientCall2 + 0x1fa
OLEAUT32.dll!IDispatch_RemoteInvoke_Proxy + 0x1b
OLEAUT32.dll!IDispatch_Invoke_Proxy + 0xb6
ieapfltr.dll!ATL::CComPtr::GetProperty + 0x56
ieapfltr.dll!FieldContainer::VisitInput + 0x1b9
ieapfltr.dll!FieldContainer::VisitAllElements + 0x21d
ieapfltr.dll!FieldContainer::ExtractFieldCount + 0x10e
ieapfltr.dll!FieldContainer::InitFieldCount + 0x9
ieapfltr.dll!PageDetails::Init + 0x315
ieapfltr.dll!PageDetails::Factory + 0x59
ieapfltr.dll!HeuristicsFeatures::InnerExecute + 0x15b
ieapfltr.dll!HeuristicsFeatures::Execute + 0x55
ieapfltr.dll!ProcessingThread::RunPageAnalysis + 0x1b4
ieapfltr.dll!ProcessingThread::RunUrlAndPageAnalysis + 0xdb
ieapfltr.dll!ProcessingThread::Analyze + 0xd3
ieapfltr.dll!ProcessingThread::AnalyzeFrame + 0x249
ieapfltr.dll!ProcessingThread::EnumerateFrames + 0x2e5
ieapfltr.dll!ProcessingThread::EnumerateFrames + 0x249
ieapfltr.dll!ProcessingThread::Evaluate + 0x1ec
ieapfltr.dll!ProcessingThread::Execute + 0x78
ieapfltr.dll!ProcessingThread::Process + 0x24e
ieapfltr.dll!ProcessingThread::Start + 0x72
ieapfltr.dll!Evaluator::ContinueProcessing + 0x21f
ieapfltr.dll!Evaluator::ContinueProcessingWrapper + 0x21
ntdll.dll!RtlpWorkerCallout + 0x70
ntdll.dll!RtlpExecuteWorkerRequest + 0x1a
ntdll.dll!RtlpApcCallout + 0x11
ntdll.dll!RtlpWorkerThread + 0x87
kernel32.dll!BaseThreadStart + 0x37

With this information from Process Monitor, one could come to a similar conclusion - the Phishing Filter in Internet Explorer 7 seems to cause Internet Explorer 7's performance to degrade in certain environments.

»