BITS service is missing, how can I get it back?

I will make one last post on this thread seeing as I seem to be the topic of discussion:

None of you know who I am - or what experience I have - as far as you are concerned I am a new member. Fair enough I accept that - which is why I try to be exact in what I say - and to test everything before I post any  information, suggest a fix, or give an answer.

Just for the record I have been a computer support engineer for 26 years and have configured, diagnosed and fixed problems on every Microsoft OS since MS-DOS v3.3 in 1987. I could go on - but I see no point in giving you my career details - you should accept me on the basis of my posts, not because of who I claim to be.

Xircal states "I think you're barking up the wrong tree blaming Fixit(s) as the cause of the problem."

We need to be clear which "problem" is being discussed - we have two separate but interconnected problems:

1. SVCHOST running the Automatic Updates goes to 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: 

       "DisplayName"="@%SystemRoot%\system32\qmgr.dll,-1000"

       "Description"="@%SystemRoot%\system32\qmgr.dll,-1001"  - I will call this the BITS problem.

I NEVER EVER said the faulty Fix-It's caused the SVCHOST problem.

That as we all know is caused by the WUA 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.

BITS must be functional for Windows Update to work. So anything that disables BITS will stop WUA 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 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 was thanked for taking the time to report the issue. As of today Monday 26th December the two Windows Update Fix-It's for XP are now working correctly. I assume my report was proved and the Fix-It's were re-coded to fix the incorrect use of Vista, Win7 registry values when "repairing" the XP BITS registry key.

The critical registry value that cause the BITS service not to start is:

"ServiceSidType"=dword:00000001

It is the cause of the Error 1290: 0x50a

Add this single value to a clean XP BITS registry - as I did in my tests - reboot to activate the modified registry and try to start BITS - case proved.

I did the same for all three of the extra registry values that appeared after I ran the faulty Fix-It's

None of the other values stop BITS from running - or cause any immediate errors.

But they may have other less immediate  side-effects - and should be removed.

Xircal stated that:[QUOTE] My system was hanging on the WUD site in the same way as many have described.

At that particular point in time, I started looking for answers and tried a few Fixits myself.

One of these pointed me in the right direction because it contained

the description "Service registration missing or corrupt".

From there, it was simply a case of tracking down which Service

was the culprit and addressing it accordingly.

[/QUOTE]

**My analysis of that sequence of events would be:**1. Your system was hanging on the WUD site due to the standard SVCHOST problem

2. At that time you did not have the BITS problem
3. You then admit you did run one of the Fix-It's for Windows Update problems

   Which is exactly what I did - way back when all this started 

4. The Fix-It failed to fix everything and reported "Service registration missing or corrupt"   - which is exactly the response the faulty Fix-It produces

   - and is exactly the same thing I saw - when I did the identical same thing

5. When you investigate you discover that the BITS registry is trashed

   - and once you reboot BITS will no longer start - with Error 1290: 0x50a

   - and has been re-named to "@%SystemRoot%\system32\qmgr.dll,-1000"

6. BITS was in fact fine before the Fix-It ran

   - it trashed BITS and then reported it was broken and it couldn't fix it - thanks a bunch

One final point when something alters the registry the changes are saved to disk and visible in Regedit immediately - however these are not active yet - and any tests performed before a reboot will not be valid. Services may start and stop on command - but after a reboot the new settings are active - and things may be different. This can seriously confuse any diagnostic tests if you are not careful about rebooting.

Even with the "ServiceSidType"=dword:00000001 entry visible in Regedit - BITS will start and stop on command - without error - if you have not yet rebooted. But after a reboot BITS will not longer start and an "Error 1290: 0x50a" will be declared.

OK that is it - anything else you want to check has already been posted in my various answers - I'm done discussing the rights and wrong of my findings - lets move on please.

DougCuk

P.S.

To read my analysis of the faulty Powershell scripts that caused the BITS problem

• and see what changes Microsoft made to fix the fault got to this thread:  

http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_update/bits-error-1290-0x50a-following-updates/9457b57d-1cb4-49f8-b62b-7fc8b226ecca?page=9&tm=1387883623656