svchost.exe using 100% CPU on Windows XP when scanning for Windows updates against WSUS

I thought I had seen the last of this issue several years ago, but we still have a couple of legacy single core CPU Windows XP boxes knocking around, and last week this problem reared its ugly head once more on a couple of machines. The symptom of this problem is that shortly after login, the automatic updates service runs to check for new updates against WSUS. While this scan occurs if you look in Task Manager the process svchost.exe is consuming 100 % of CPU resources making the machine pretty much unusable. You can verify whether wuauclt (the Windows update client) is the culprit in your case by running Process Explorer, and seeing if wuauclt is running under the svchost process. This issue always used to affect single core machines with relatively small amounts of RAM by todays standards. At the time this issue was fixed in the majority of cases by installing an updated version of the Windows Update agent which can be found here.

Anyway, back to the present, and after releasing a handful of windows updates for XP in the WSUS console a few days ago I found that a couple of legacy XP machines had become unusable after login as svchost.exe was consuming 100% CPU. The client machines would stay like this indefinitely and never seemingly finished their scan for updates against WSUS. Straight away I looked in the C:\Windows\windowsupdate.log to check the client version and to see if anything else unusual was occurring. The update agent was up to date (version 7.4.7600.226) so this didn’t appear to be the old problem.

As the first part of the fix, I ran the WSUS ‘Server Cleanup Wizard’ on the server that the client was checking for updates against. I selected all the options as shown below to make sure the client wasn’t checking for any unecessary or superceded updates.

WSUS Server Cleanup Wizard Options


Secondly, I followed method 1 of this technet tutorial:

1.Click Start, click Run, type cmd in the Open box, and then click OK.

2.At the command prompt, type net stop wuauserv, and then press ENTER.

3.Click Start, click Run, type regedit in the Open box, and then click OK.

4.Locate and then click the following registry subkey:


5.In the details pane of Registry Editor, delete the following registry entries:

  • PingID
  • AccountDomainSid
  • SusClientId
  • SusClientIDValidation

Note Windows Update Agent 3.0 adds the SusClientIDValidation value. This value was released in May 2007. The other registry entries exist in both Windows Update Agent 2.0 and in Windows Update Agent 3.0.

6.Exit Registry Editor.

7.At the command prompt, type net start wuauserv, and then press ENTER.

8.At the command prompt, type wuauclt.exe /resetauthorization /detectnow, and then press ENTER.

9.Wait 10 minutes for a detection cycle to finish. 10.Start the WSUS console to make sure that the clients appear in the WSUS console.

After carrying out the above steps, the XP client machine completed the update scan within a few minutes and the CPU usage returned to normal.


Could not load the file or assembly Microsoft.Web.Administration Version= when running the Exchange Management Console

Earlier today I received the following error message while using the Exchange 2007 32bit Admin tools on a Windows 7 client computer, when trying to access information under ‘Server Configuration’ in the Exchange Management Console:


“Could not load file or assembly ‘Microsoft.Web.Administration, Version, Culture=neutral,PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.”

Error message Could not load file or assembly Microsoft.Web.Administration


To correct this error I opened the ‘Turn Windows features on or off’ screen and enabled the Internet Information Services (IIS) Web Management Tools, as shown below:


Enabling the IIS Web Management Tools in Windows 7


I then restarted the Exchange Management Console and the desired functionality was restored.

Set deadline for windows update installation in WSUS

In certain circumstances, when using WSUS (Windows Server Update Services) in your environment, you may wish to deploy a critical Windows update sooner than your scheduled installation window. Personally, I would excercise extreme caution using this setting due to the gotchas outlined at the end of this post.  However, this can easily be achieved by setting a deadline for installation when you approve the update or updates. In the WSUS console simply select the update or updates, and then right click them and choose ‘Approve …’ as shown.

Approving an update in the WSUS console

Once the ‘Approve Updates’ screen opens, choose which group of computers you want to approve the update for. In this case I have chosen ‘All Computers’, and then  ‘Approved for Install’. Next right click the ‘All Computers’ group again and choose ‘Deadline’ and then ‘Custom’ as shown:

Set a custom deadline for installation of an update in the WSUS console

The ‘Choose Deadline’ screen opens. Choose the date and time that you want the update or updates to be installed at, as shown:

Choose the date and time for your deadline

Thats it, your update will now be installed at the time that you have set. There are a couple gotchas using this setting that it is worth being aware of. Firstly if the update with the deadline requires a restart, the computer will reboot after installation regardless of what the user is doing at the time. It is therefore probably best to avoid deadline times in the middle of the working day when users may suddenly find their computers reboot with little or no warning causing them to lose work. Secondly, a deadline will override the ‘No auto-restart with logged on users for scheduled automatic updates installations’ Group Policy setting, so again be careful if you have this GPO setting enabled, as you may not expect your computers to reboot, but they will in this case.