Based on a suggestion which was similar to suggestions I've previously come across:
http://forums.anandtech.com/showthread.php?p=35827839#post35827839
Here is a log of my latest attempt to fix this problem (which hasn't been successful):
tested for cpu saturation bug positive, stopped and disabled AU
downloaded and installed KB2888505, rebooted, re-enabled AU and wuauclt /detectnow
tested for cpu saturation bug positive, stopped and disabled AU
stack for wuaueng.dll (thread of the svchost.exe with 100% CPU usage) running during saturation:
ntkrnlpa.exe
hal.dll
ntdll.dll
wuaueng.dll (100%)
kernel32.dll
suspending the thread results in cpu usage drop, resuming it resumes saturation
stopped and disabled AU
downloaded netfx20sp1_x86.exe, dotnetfx30sp1_x86.exe, dotnetfx35setup.exe, dotnetfx40_clientx86_x64.exe
running installers one after the other unless I'm told to restart
surprising that it didn't act as if I had any of these installed (perhaps I didn't)
restarting because 3.5 asked me to
installing 4.0, noticed ngen command with command switch is run during setup
rebooted when asked to after install
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319>ngen executequeditems
Microsoft (R) CLR Native Image Generator - Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Installing assembly executequeditems
Uninstalling assembly executequeditems because of an error during compilation: The system cannot fin
d the file specified. (Exception from HRESULT: 0x80070002).
The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>ngen executequeditems
Microsoft (R) CLR Native Image Generator - Version 2.0.50727.3053
Copyright (c) Microsoft Corporation. All rights reserved.
Installing assembly executequeditems
Failed to find dependencies of image executequeditems because of the following error: The system can
not find the file specified. (Exception from HRESULT: 0x80070002)
Compiling assembly executequeditems ...
Error compiling executequeditems: The system cannot find the file specified. (Exception from HRESULT
: 0x80070002)
Uninstalling assembly executequeditems because of an error during compilation.
The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
re-enabled AU, wuauclt /detectnow
tested for cpu saturation bug positive, stopped and disabled AU
removed all .net frameworks, based on my theory that .net has nothing to do with this problem.
re-enabled AU, wuauclt /detectnow
tested for cpu saturation bug positive, stopped and disabled AU
re-enabled AU, wuauclt /detectnow
tested for cpu saturation bug positive, stopped and disabled AU
time test, how long does svchost.exe take on a 3GHz single core VM to complete
test started at 14:51
side note: In windowsupdate.log, the last entry (while running time test) so far is:
Code:
2013-12-11 14:51:32:250 1016 540 PT +++++++++++ PT: Synchronizing extended update info +++++++++++
2013-12-11 14:51:32:250 1016 540 PT + ServiceId = {9482F4B4-E343-43B6-B170-9A65BC822C77}, Server URL = https://update.microsoft.com/v6/ClientWebService/client.asmx
I've seen this entry before during the saturation phase, while it is quite common, it's not the only message I've seen during this phase.
Other observations:
Nothing else going on in process explorer except for the saturating process
No disk activity (looking at the VM software's disk activity indicator)
No network activity (looking at both the XP network systray icon and the VM software's network activity indicator)
Observations from previous occasions:
Process Monitor doesn't show any potentially interesting activity during the saturation phase, just the normal crap that goes by like lsass looking in the SECURITY key and the other one that likes to check out TCP/IP linkage all the time.
saturation stopped at 15:19
installing 11 updates (including an IE cumulative)
reboot when requested
wuauclt /detectnow
cpu saturation bug not observed this time (but I suspect this is the behaviour seen by many where the bug appears to be fixed by a particular update... 'until next time').
-----
IMO this isn't going to be fixed by a cumulative IE update, it doesn't make any sense, IMO. My reasoning is that if the Windows Update system required something from IE, then surely all the fixes for the Windows Update Agent would include something to prod/reset IE. Same goes for the .net framework, though I think I've pretty conclusively proven that the .net frameworks don't have anything to do with this.
The only other components I can think of that could potentially be involved is MSXML and WMI. However, I think these are unlikely for the same reason as I stated for IE. The only reason I'm considering MSXML is because this bug seems like a processing issue. The processing does complete otherwise I wouldn't have been notified of any Windows Updates, so a process isn't locking. There's next-to-zero disk activity, so it seems logical to me that whatever is being processed is in memory already, and wuaueng.dll is chewing over that data (very inefficiently?). I don't know whether XML has any role to play in the storage mechanism for the Windows Update system, but as MS has had a bit of a hard-on for XML for a while, I think it's a reasonable guess.
I know it's not a Windows Update database issue because clearing out the SoftwareDistribution folder makes no difference.
The only way I can tentatively link IE to this situation is that Windows Update was originally an IE only app. Perhaps something that IE uses as well as Windows Update is needed, like say the XMLHTTPRequest API. How often does it get updated? Perhaps not often, but perhaps recently?
Facebook
Twitter