If you’re an Independent Technology Professional like me, you are probably still working a lot with Windows XP. Let’s face it: for everything Microsoft is doing to move users to newer versions of Windows, Windows XP is simply entrenched in the marketplace and will probably continue to be for at least a few more years. The reality is there are a lot of people and business out there who run older Windows software and do not need to move to newer versions of Windows – especially now that Windows 8 is scaring the pants off people.
A lot of my clients still run Windows XP, especially those who bought PCs after 2007 and did their best to avoid Windows Vista. Yes, their machines are old, but with a little TLC they continue to run well for them and they aren’t interested in upgrading their PCs for the time being. Additionally, for several years now I’ve been heavily involved in setting up computers with Windows XP running in a virtual machine, whether it is for new Macintosh users who still need to run a particular Windows-only software, or Windows 7 or 8 users who need compatibility with older software. In the last year I kept running into a tricky issue I couldn’t quite squash because of its transient nature. But after a lot research I finally found the root cause and a possible solution.
I began to see this problem a lot as I was setting up brand new Windows XP SP3 installations under virtual machine software, whether that software was VirtualBox, Parallels, Virtual PC, Hyper-V, or others on either Macintosh or Windows host computers. It seemed to me like running the several rounds of updates after the initial Windows XP installation was taking forever – significantly longer than the usual lengthy process. Investigating the issue, I noticed that a SVCHOST.EXE process was eating up all the CPU. Further investigation showed that WUAUCLT.EXE was the core process behind the particular SVCHOST.EXE process. WUAUCLT.EXE is the Windows Update Automatic Update Client software that obviously manages automatic updates. What I observed, however, was that the problem really only manifested itself noticeably during the initial rounds of updates after the Windows XP install. The problem appeared to go away after that so I didn’t bother to troubleshoot it further. However, I later did start to observe the issue on client machines that were not brand-new Windows XP installs. I also noticed that that the problem seemed to intermittently return on the Windows XP installs that I had set up in virtual machines. After troubleshooting a few cases independently, I realized there was a common thread between all of them.
Obviously there is a problem with the Windows Update Automatic Update Client. Woody Leonhard from InfoWorld.com has done the best job of explaining the cause of the SVCHOST problem that I’ve found anywhere. Apparently, this problem has been in existence in various forms for many years. However, it seems to have gotten a lot worse lately. The simple explanation is that Microsoft believes that the amount of old updates in the automatic update chain has gotten to the point where it is overwhelming the WUAUCLT.EXE process. Microsoft is working to fix the problem but it seems that successive attempts have had mixed results. Based on my research, I believe I have found the general process for resolving the issue.
When I first started investigating this issue heavily a few months ago, the fix I found involved installing MS13-080/KB 2879017, which was released in October 2013. Ironically this patch is described as a Cumulative Security Update for Internet Explorer and does not mention fixing Windows Update Automatic Update Client. This did seem to fix the issues I was working on at the time. Later, however, it appeared that this fix no longer worked. It seemed that there were new Cumulative Security Updates for Internet Explorer. First came MS13-088/KB2888505 in November, followed by MS13-097/KB 2898785 in December. At the time of this writing, MS13-097/KB 2898785 seems to be the magic bullet for most situations. That being said, given the history of this issue, I would not be surprised if we see the problem re-emerge when the next Cumulative Security Update for Internet Explorer is released. I will update the article if/when this problem returns and/or if Microsoft finally fixes the root cause of the issue on their end.
For brand new Windows XP SP3 installs, where the SVCHOST problem rears its ugly head almost immediately, I have confirmed that manually installing MS13-097/KB 2898785 fixes the issue. Running Windows Update or Automatic Updates proceeds normally and in fact, is much quicker than it has seemed in years. Likely we have been experiencing this issue for a long time and simply chalked it up to Windows Updates being slow in general. Oh, the wasted hours!
On deployed machines, if you’re lucky the Cumulative Security Update for Internet Explorer will be installed by Automatic Updates. Likely this is what is happening for most people that have Automatic Updates turned on and they simply never notice the slowdown that SVCHOST causes. However, if you run into this issue in the field, it can be very time consuming to run Windows Updates since the SVCHOST problem makes the computer run like molasses. In this situation, you should kill the SVCHOST.EXE process in Task Manager which will then free up the computer’s CPU so that you can quickly manually download and install the update. After restarting, you may notice that SVCHOST still spikes the CPU when Windows is searching for updates, but it should be brief and the effect should be negligible.
Windows XP SVCHOST.EXE, WUAUCLT.EXE CPU 100% Fix
