THE OFFICIAL BLOG OF THE SBS "DIVA"

"BK" posts in what we've been suspecting all along..that 927891 isn't working/doesn't always work.

Oh in my network where I don't have Celery.... I mean Celerons .... so the applications of 927891 does help a lot, but if you have underpowered machines, celerons you are STILL getting nailed....

KB927891 helps resolve the svchost.exe crash; the one where it drags down the other services hosted in the same PID and reports the msi.dll as the offender in the event log. It does not however resolve the 100% CPU issue.

How to get a single core workstation running Windows XP SP2 to use 100% CPU (50% on dual core)

Step 1: Use WSUS 2

Step 2: Approve updates before your target install date (e.g. approve updates on Wednesday for Friday morning installation).

Step 3: Run wuauclt /detectnow on a machine that does not have the newly approved updates installed and wait for BITS to finish downloading updates. I’ve not seen this issue occur on the initial scan that starts the download thus the processor utilization should stay within reasonable boundaries. After WUAU finishes downloading updates run a scan again by using wuauclt /detectnow; note the level and duration of processor utilization. On every box I tried this on I get 100% on single core or 50% on dual core machine between 7 to 20 minutes based upon the speed of the machine. You get the same effect regardless of the event triggering the scan (wuauclt /detectnow, reboot, or 22 hour default scan).

Conclusions:

Machines using the WSUS 2 client with downloaded pending updates will experience this issue.

This is a WSUS 2 (AU) client issue. The reason for the “thunderous silence” from Redmond is that this issue is supposedly resolved in the WSUS 3 client, thus a decision was made to push for the completion of WSUS 3 (why waste development time on a product you’re in the process of replacing).

I called PSS on Thursday to verify my suspicions; I discovered about 10% (50) of my workstations had been turned off by their users and thus I had numerous complaints on Thursday morning regarding Celeron machines taking about 15 minutes before they were usable. The dual core machines were running slow but stayed functional.

<sigh>

But I would disagree slightly with the WSUS 2.0 client being the culpret...it's Microsoft update client in general causing this issue and not specific to WSUS 2.0.

So gang.. apply 927891 knowing that it's not the final fix..and in the meantime I'll see I can find out if we can group policy flip back to windows update...