BITS Error 1290: 0x50a following updates

I had suspected that the faulty scripts (in the Windows Update Fix-It) - most likely pre-dated the 19th November release - nice find on the quoted forum post from 6th November.

We may never know how long the faulty Fix-It's were available for download - or how many people's XP systems were affected. It appears - from the code - that the fault would also affect Server 2003 installations if they used the faulty Fix-It's.

The programming errors in these Powershell scripts were - in my opinion - just human error - compounded by complete lack of testing.

These scripts were written by some poor programmer stuck in a basement somewhere - never seeing any daylight - well maybe not. They may not even be a Microsoft employee - just a contract job to write Powershell scripts for Microsoft utilities - its a job

• someone's got to do it.

Don't let the paranoia get you down - life is too short !!

Happy Xmas

========================================================

UPDATE - PLEASE BE AWARE:

The new Fix-It version does NOT - as yet - undo the damage to the BITS registry caused by the old version!

I hope Microsoft realise how much neater it would be if the new version fixed the damage done by its predecessor.

You would still need to restore a clean XP version of the BITS registry

Scroll down this page to my 25th December post for my BITS repair instructions

==========================================================

Based on the November 6 date for the following post

http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_update/windows-xp-pro-updates-error-0x80246008/c7fff426-5e4d-4305-9257-3cbb88108ff4

it is a safe assumption that the even earlier version of the Fix it before November 19 was also defective.  I think it is also a safe assumption seeing 3 versions of the Fix it in existence in a 2 month period that Microsoft already knew there was a problem with the Fix it before they were pointed to specifically what the problem was. 

I believe the coding error likely exists in other places than just the Fix it tool now identified.  I believe other things than BITS may also be affected.

There were no tests done by me to confirm what Doug reported but I believe what he reported is true and it was reported in explicit terms by others before Doug did his own tests.  With the recent revisions of those Fix its by Microsoft there is evidence there was a need for revision, unless Microsoft is tasking people to fix what isn't broken.

I have now analysed the changes Microsoft made to the two Windows Update Fix-It's

The two faulty MS-Fix-It's were:

How do I reset Windows Update components? (KB971058)

Fix the problem with Microsoft Windows Update that is not working.

The two different Fix-It's do indeed share the same scripts - basically they are the same Fix-it

Microsoft recompiled the Windows Update Fix-It on Sunday 22nd December - and released it Monday morning sometime.

246,878 bytes  wu.diagcab - new version   22 December 2013 23:20:50 - from files digital certificate244,293 bytes  wu.diagcab - old version   19 November 2013 06:54:33 - from files digital certificate============

2585 bytes  difference in file sizes

Nice of Microsoft to digitally sign the file as it would have been difficult to identify otherwise.

Of more interest is what they changed - it appears the mistake was in a couple of the Powershell scripts the Fix-It uses to do its work. And the changes reveal a programming slip rather than a deliberate mistake.

The following code was missing from the earlier faulty Fix-It file: RC_BITSRegKeys.ps1--------------------------------------------------------------------------------------

$CurrentVersion = [Microsoft.Win32.Registry]::

GetValue("HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion", "CurrentVersion", "")

if($CurrentVersion -eq 5.1 -or $CurrentVersion -eq 5.2)

{

    $rootCauseFlag1 = $false

    $rootCauseFlag2 = $false

    $rootCauseFlag3 = $false

}

I am no expert - but even I can tell this is an attempt to identify WinXP or Server 2003

and then set three variables as flags with a value of "False" -

If these flags are not set then any later code - that relies on knowing we are dealing with

XP or Server 2003 - will fail to execute and the default Vista/Win7 code will be used instead. 

The script  uses the default that we are dealing with Vista, Win7 or Win8 - unless told otherwise.

There is another change in the file: RC_BITSAcl.ps1-------------------------------------------------------------------------------------------

if($CurrentVersion -eq 5.1 -or $CurrentVersion -eq 5.2)

{       $acl = "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)  ............  (A;;CCLCSWRPWPDTLOCRRC;;;PU)"

 if("-1" -eq $sd[1].indexof($acl))

 {   $detected = $true   }

}

else

{     if("-1" -eq $sd[1].indexof("D:(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY) .... A;WDWO;;;BA)"))

 {       $detected = $true  }

}

Now again I am no expert but I have written a few program scripts - and even I know that the construct

If Then Else - should have two different outcomes:

   - If $acl=(ABCD) do one thing

   - Else do something different

The code above sets the $detected flag to "True" regardless of the test resultThis was changed in the later version: to give a "False" response for the first $acl test  - (which may be WinXP)  and give a "True" response the second $acl condition - (which may be Server2003)

=========================================================

I was able to do this comparison because I have the before and after versions of the Fix-It

This is only possible if you have the full set of files used by the Fix-It

If you run the Fix-It in interactive mode it downloads all the resources it needs on the fly over the internet - the initial exe file you see named is just a stub installer and contains no diagnostic or repair code.

You need to download the stand-alone "Portable" version to have all the script files.

If anyone wants a copy of the files - I will be happy to make them available.

I will be keeping them - for my collection.

========================================================

PLEASE BE AWARE:

The new Fix-It version does NOT - as yet - undo the damage to the BITS registry caused by the old version!

I hope Microsoft realise how much neater it would be if the new version fixed the damage done by its predecessor.

You would still need to restore a clean XP version of the BITS registry

Scroll down this page to my 25th December post for my BITS repair instructions

==========================================================

As for Keith's finding Re: KB956572 - that was issued in April 2009 !!

That is a rather long time ago - and came from this bulletin:

MS09-012: Description of the security update for Windows Service Isolation: April 2009

As Susan said it is entirely possible for these updates to interact in strange ways that appear to be similar to other previous (or in this case future) events. I don't think this was likely to be directly related to the Fix-It screwup.

Happy Xmas All

There were no tests done by me to confirm what Doug reported but I believe what he reported is true and it was reported in explicit terms by others before Doug did his own tests.  With the recent revisions of those Fix its by Microsoft there is evidence there was a need for revision, unless Microsoft is tasking people to fix what isn't broken.