Here's the cause Neal reported:
We saw the issue stemmed from inefficiencies in the Windows Update Agent processing long lists of superseded updates. And the problem was exponential in that each additional superseded item took twice as long as the previous item to evaluate. With lists as long as 40+ superseded items, the processing cost on SVCHOST via the Windows Update Agent had an exceptional impact on client PCs... Upon review, MSRC agreed to do away with the (now outdated) requirement to maintain long supersedence lists and permit a shortening of the supersedence to only reasonable numbers like most Microsoft products on Windows and Microsoft Update.
That's all well and good, but it sounds a whole lot like the reason Neal gave a month ago for the same problem.
The problem is caused by the Windows Update client evaluating an exceptionally long supersedence chain -- something IE6 and IE7 have more than any other version of IE due to their time in market. Each 'link' in the chain doubles the CPU resources needed to evaluate it over the previous version. The chain is so long that the design stymies the WUA client.
At that time Neal apologized because the fix that he expected to see in November didn't work:
We're working to expire these exceptionally old, dated, unnecessary updates in the chain. The expirations for these didn't happen as planned.
It now appears the fix he expected to see in December didn't work either:
We took what we believed were the right steps to expire large chunks of superseded (outdated, unnecessary) updates in the IE6 and IE7 supersedence lists. Testing suggested this would be sufficient and we made the change on the backend in a release in October that expired these many unnecessary updates. Turns out the Windows Update Agent has smarts built into it that outsmarted us and the problem persisted for the majority of impacted customers. We made a more comprehensive change in November and an even larger set of logic and expiration changes in December. Unfortunately, the problem still wasn't solved.
You just have to wonder how much the fixes were tested. The bad guy here isn't some third-party program, a weird setting, or an infection. The problem lies with Microsoft's own "smart" software.
With the fixes in October, November, and December proving inffectual (I have to hand it to Neal for 'fessing up to the fact), we're given reassurances that a fix is coming -- although there's still no deadline offered.
It's a top priority. And the right (and smartest) people are on it... Unfortunately, there is no 'fix' or quick workaround that can be applied at this time as we concurrently work to provide a backend fix and some guidance on the real, best solution.
So for now, your only real options are to try one of the (many) fixes posted online or to turn off Automatic Update and pray you don't get sandbagged by a patched exploit. Microsoft should have a KB article up in the interim to provide guidance. It'll be interesting to see what it says.
I'm fully expecting a technical obfuscation of "bend waaaay over and kiss your keester good-bye."
Microsoft will fix it. The Microsoft Update folks are great programmers. But it remains to be seen if the problem will get fixed before Windows XP itself gets the axe.
This story, "Microsoft promises to fix Windows XP SVCHOST redlining 'as soon as possible'," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.