Microsoft promises to fix Windows XP SVCHOST redlining ‘as soon as possible’

We’ve seen the same problem reported over and over for Windows XP users trying to update their computers: Windows Update redlines (more accurately, the XP Windows Update agent WUAUCLT.EXE running in a SVCHOST wrapper redlines), taking 100 percent of the CPU for five, 10, 15 minutes — up to an hour or two.

If you have Automatic Update enabled on your computer, that means every time you reboot Windows XP your machine can lock up for hours on end; pull the plug, and the same thing happens over again. On Friday night we (finally) received an official explanation that describes why the problem happens, along with a description of what Microsoft is doing to resolve it and a promise that it’ll get fixed “as soon as possible.”

When I last reported on the WinXP SVCHOST redlining, Microsoft thought it had solved the problem in the November Black Tuesday set of patches. Wrong. The problem popped up in November and it’s gotten worse in December, with lengthy discussions on dozens of forums.

It’s hard to tell how many people are affected, but with something like half a billion Windows XP machines still connected to the Internet, it’s a horrendous problem. At least in my experiences, the vast majority of people who experience the lockup have no idea why their machines go out to la-la land.

The facile solution — and it works! — is to never turn off your Windows XP machine, don’t update it, don’t patch it, just leave it alone and it’ll work fine.

More sophisticated WinXP customers turn off Automatic Update and refrain from installing any new patches. That works, too, but with WinXP the target of all sorts of attacks — and WinXP end-of-support on the horizon in April — it’s hardly a viable solution.

The first time I reported on SVCHOST redlining, I thought I had a solution. Wrong. The fixes that you read about on the Internet work for some people, some of the time — but nothing so far works for everybody. There’s a reason why: Microsoft’s implementation of patch detection in Windows XP is fundamentally flawed. It keeps running longer and longer and longer, with the amount of processing time going up exponentially in relation to the number of Internet Explorer patches that have been rendered obsolete. You may be able to find a way to relieve the pain temporarily, but until the detection routine is fixed, the problems remain.

Doug Neal, senior program manager for Windows and Microsoft Update, sent a message to the PatchManagement listserv on Friday night. He started out by saying:

In September we witnessed a large number of reports of SVCHOST taking high CPU for extended periods of time. This was primarily on Windows XP machines running IE6 or IE7. There were a few reports of this happening on Windows XP with IE8, but only a few.

That may be the first time the Microsoft Update team saw a lot of flaming reports, but I started seeing the reports on Microsoft’s TechNet forums in late May. I just did a quick Google search and discovered complaints about this precise behavior (quite possibly with a different cause) going back more than seven years, with dozens of additional, corroborated reports in the interim. SVCHOST redlining with Windows Update isn’t a new problem. I just hope Microsoft has nailed down the cause of the latest manifestation.

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.