BITS Error 1290: 0x50a following updates

Doug, You know what I think should be looked at next is SP3.  I have been looking through old CD's to see if I have an old SP3 file from several years ago, and to check it to see if SP3 from several years ago is exactly the same as SP3 that is out there on the servers now.  Would it be any surprise if there is something buggered also about the SP3 that is being offered now?  There have been reports that SP3 is breaking BITS, but I don't know what else to make of that report than to think about the Fix it scenario and wonder if a similar things is occuring with SP3.  Just a thought.

Everyone was in complete agreement from the beginning that this issue with updates in all its particulars is owned by Microsoft because the issues occur with nice fresh squeaky clean installs.

So it is a no brainer where the problem has come from is Microsoft.  It doesn't take a genius to know that or to figure out that Microsoft likely created the problem on purpose because of the timing or doesn't care about the issue and views it as fortuitous timing to conveniently ignore and claim it would just take too long to fix.

I think you have a good point there about "fresh squeaky clean installs" suffering the SVCHOST Updates problem. Plus there are several cases where the next action was to run a Microsoft Fix-It in an attempt to rectify the problem - and we now know the outcome of that action. All with no other software installed - just Microsoft product .

However I think Microsoft have caused these problems by lack of care rather than deliberate action. The Windows Update client in XP is a very old bit of coding that has now collapsed under the weight of Internet Explorer updates. This is due to a stupid decision by Microsoft to retain every IE update in the Updates database - unlike all other Windows updates where the server only presents the most recent update. All the other Windows updates work fine with XP's code. This was an accident waiting to happen and should have been foreseen.

As for the faulty MS-Fix-It's I think that is just sloppy coding and bug checking by Microsoft staff who didn't bother to double check Fix-It's still worked on XP. Accidentally applying Vista, Win7 registry settings to XP was a classic rookie mistake - and should have been caught at the bug checking stage - before release to the Fix-It website.

I think Microsoft are embarrassed enough to fix both these issues - the publicity on the SVCHOST issue is massive. Doug Neal of Microsoft admitted it was their fault on Patchmanagement.org - and has now been quoted all over the internet. Whether he has been reprimanded for this admission is being debated.

Thanks Doug, et al, System seems stable for the moment and I have automatic left update off. I will see what January brings before i decide whether to turn it back on.

Richard

The weather forecast is for rain and more rain, so it would probably be a good idea IMO to leave automatic updates off and to go to the monhly security bulletin at TechNet for the most recent cumulative security update for IE and manually install it as a countermeasure for the hang at Windows Update with CPU spiking for excessive and indefinite times.  Obviously the throttling to below 10% total CPU that is supposed to be done as part of BITS functionality is not working so it would seem pretty evident that there is more going on with the BITS issue than has been disclosed.  When a service that is supposed to be a minimal background load on the CPU providing for no interference with other tasking being done by the user, malfunctions by manifestation of an ungoverned and runaway 100% CPU loading, then the BITS intended functionality and purpose has been destroyed and it has become a foreground priority service rather than a background service allocated only a limited CPU bandwidth.  What I am saying is that even when we have "fixed" BITS most apparent failures so that it can function at all, it is still not working as it was intended because the throttling of the CPU being limited to the low level of 10% is not being achieved and spiking to 100% has only been made a transient which can be overcome after some few minutes.  Clearly if the CPU is being throttled to a low level as to support what is a background service, then CPU utilization would never be as high as is being observed.  So even at its best performance, BITS is simply not working correctly in keeping with what was designed.  Windows Updates should be a background task not interfering whatever or competing for CPU with other simultaneous user activity but that simply is not the way it is now.

It would appear that somehow what was named Background Intelligent Transfer Service

has somehow been degraded in functionality so that it would now more properly be named

Foreground Unintelligent Transfer Service   

BITS has become FUTS    which is simply nucking futs

http://www.youtube.com/watch?v=3EVBhtkwszk  Rain Please Go Away