Many users have been affected recently by this when trying to update windows or during normal usage when Microsoft Security Essentials Anti Virus (MSE) ( is installed because that uses the Microsoft update channels to update itself . It normally only affects a user who has recently reinstalled Windows XP or has kept IE 6 or 7 on the computer instead of updating to IE8 or is very behind with windows updates.

This is a copy of a posting by one of the Microsoft update team who are trying to get to the bottom of it and fix it. Despite all the paranoia on various sites on the net, Microsoft are not doing it deliberately and are not trying to kill off XP before the already announced date of April 2014, when all support and patches for XP stops.

The current work around for most users is to:

1. Turn off automatic updates
2. Install the latest Cumulative Update for Internet Explorer and then reboot the computer
For Internet Explorer 6 go to
For Internet Explorer 7 go to
For Internet Explorer 8 go to
3. Then turn on Automatic updates again and do the rest of the windows updates. Update to Internet Explore 8 if you haven’t already.

Note: While installing the Latest Cumulative Update for Internet Explorer MS11-099 ( you will still get the high Svchost 100% CPU usage and very slow install of the update, which can take up to 1 hour on some systems. It is only after the update has installed and you reboot that the problem is “cured” and you can then do normal windows updates or update MSE with no problems

I want to share an update to those on this list and those who have also sent personal emails regarding the ongoing IE supersedence issue.

Original Issue

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.

Issue Identified

From the extended Windows Update logs, 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.

Due to security requirements, the Internet Explorer product was required to continue building a chain longer than what is normally permitted in Windows Update. Over time, this exception exacerbated the previously unknown inefficiency in the Windows Update Agent. 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.

While the underlying issue is with the WUA client, such a design change and rollout would take a lot longer and doesn’t resolve the problem in the short term for those impacted now.

Attempted Fixes

As a result, 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.

Our customers have done a great job of letting us know the problem still hasn’t been resolved. We appreciate the quick and detailed feedback. And we share your frustration that we haven’t been able to solve this for you more quickly.

We’re working diligently to release changes to the supersedence logic that will comprehensively solve this problem. It’s a top priority. And the right (and smartest) people are on it. And as this problem has become more prevalent, we’re working to provide a KB article that will publicly describe the issue so customers can discover it via searches and the recommended guidance. 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.

I appreciate your patience. And want to let you know we’re working through the holiday to provide the right fix as soon as possible. As you can imagine, we don’t have an ETA. And we want to make sure the next fix is the last and comprehensively solves this for our customers.

This message was originally posted on: