We need to be clear which "problem" is being discussed - we have two separate but interconnected problems:
1. SVCHOST - containing the Automatic Updates - runs at high CPU load - I will call this the SVCHOST problem.
2. BITS is disabled and its Display Name and Description changed to the Win7 version thus:
"Description"="@%SystemRoot%\\system32\\qmgr.dll,-1001" - I will call this the BITS problem.
There are other causes of Windows Update problems - but these two are the issues I have been discussing.
If you have other symptoms then it is entirely possible that you have additional issues - see my next post.
The faulty Fix-It - for Windows Update (WU) problems - DOES NOT cause the SVCHOST problem.
That - as we now know - is caused by the WU Agent choking on the large number of possible Internet Explorer updates.
And was fully explained in the post by Doug Neal on the PatchManagement Mailing List - which I believe I was the first to post on this forum - after it appeared in the second InfoWorld news article back in November.
Microsoft say they hope to have a fix before the January (Patch Tuesday) Updates are released - as the problem will activate again once the the next IE Cumulative Update is released.
The quote from Doug Neal (Windows Update team) - on 13th December :
We're working diligently to release changes ............. 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 (quick) 'fix' or 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 throughthe holiday to provide the right fix as soon as possible.
BITS must be functional for Windows Update to work. So anything that disables BITS will stop WU working.
So the two problems are connected but separate - You can have both problems at the same time or just one.
Each stops Windows Update working at a different point in the process - with different symptoms.
In XP the normal setting for the BITS is a Manual Start - it only starts when WUA initiates a download
If you set BITS to Start Type: Disabled then Windows Update refuses to run at all - it displays an error.
The faulty Fix-It's however disabled BITS by adding a Win7 DWord item: "ServiceSidType"=dword:00000001
But they left BITS set to Start Type: Automatic - this fools Windows Update into launching and doing its search for updates. This completes and you can select the updates you want to download - however it then fails when it tries to start BITS - which handles the actual downloading of the selected updates.
I tested the effects of the two faulty MS-Fix-It's very carefully - the only fault I could find was the "corruption" of the BITS registry due to the use of Vista, Win7 values, and settings. Once these were removed I could find no remaining problems - BITS starts and stop at the command of the Windows Update Agent - and is able to download updates again. Unlike some other causes of BITS problems there were no missing or unregistered DLL's and as far as I can tell no other registry keys were damaged. It was a rookie coding error where Win7 registry values were used instead of the correct XP versions - it was not properly tested - and was then released for use.
I reported my findings to Microsoft Tech Support on the 16th December - and as of Monday 23rd December the two Windows Update Fix-It's for XP are now working correctly. Having checked the new Fix-It version it was clear that Microsoft had corrected mistakes in two Powershell scripts that were causing the code not to detect the Windows OS version correctly - the Fix-It's were re-coded to fix this problem and stop the incorrect use of Vista, Win7 registry values when "repairing" the XP BITS registry key.
Edited by DougCuk, 27 December 2013 - 06:32 AM.