Over the past couple Patch Tuesdays, Microsoft has attempted to solve a problem where SVCHOST will tag the CPU at 100% for extended periods of time. The problem revolves around Windows XP running IE6 or IE7, with a few cases reported where Windows XP with IE8 exhibited the same strange behavior. With Windows XP so close to retirement (April 8, 2014), you would expect Microsoft to be taking a very lax stance on getting this fixed. But, that's not the case.
On Friday (December 13, 2014), Microsoft's Doug Neal took to the Patch Management Mailing List to explain the issue and assure customers that Microsoft is working diligently to ultimately fix the problem.
Doug says:
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.
We'll keep you apprised of any updates here at Windows IT Pro.
