Slashdot Mirror
Exponential Algorithm In Windows Update Slowing XP Machines
jones_supa writes "An interesting bug regarding update dependency calculation has been found in Windows XP. By design, machines using Windows Update retrieve patch information from Microsoft's update servers (or possibly WSUS in a company setting). That patch information contains information about each patch: what software it applies to and, critically, what historic patch or patches the current patch supersedes. Unfortunately, the Windows Update client components used an algorithm with exponential scaling when processing these lists. Each additional superseded patch would double the time taken to process the list. With the operating system now very old, those lists have grown long, sometimes to 40 or more items. On a new machine, that processing appeared to be almost instantaneous. It is now very slow. After starting the system, svchost.exe is chewing up the entire processor, sometimes for an hour or more at a time. Wait long enough after booting and the machine will eventually return to normalcy. Microsoft thought that it had this problem fixed in November's Patch Tuesday update after it culled the supersedence lists. That update didn't appear to fix the problem. The company thought that its December update would also provide a solution, with even more aggressive culling. That didn't seem to help either. For one reason or another, Microsoft's test scenarios for the patches didn't reflect the experience of real Windows XP machines."
This is clearly the right time for Microsoft to completely rewamp the update system in XP; and what could possibly be better than to just remove the whole thing and import an already working package system from Debian?
That's the best way to force users to upgrade that I can think of. They're already planning to end-of-life it. After EOL, they can simply start adding empty patches to the update system until it drives left-over XP users to upgrade. ;-)
They should have been off Windows XP long ago.
Indeed. But it will stay for very very long I'm afraid. Lot's of systems still runs on XP with no available migration path. They just recently upgraded the security system where I work to XP. I don't want to think about what it ran before that.
I'm really not sure if I would put it past MS or not to do this intentionally and leave it unfixed while reporting (lying) about trying to fix it in order to force the death of XP on schedule. It seems too obvious.
Brought to you by Carl's Junior.
So someone thought it was a good idea to upgrade a security system with software that will have no security support in 4 months time?
And how exactly does Slashdot not have full Unicode support?
one thing you can do to fix this is the following
sc config wuauserv type= own
(the space between "type=" and "own" is important)
this tells the service manager to put windows update service (WUAUserv) into its own hosting process, e.g. a new/separate instance of svchost.exe
Another service that can be implicated in updates is the "BITS" service. You can use the same command to isolate it also.
Anytime I see a svchost.exe instance misbehaving I start isolating the services inside it and then seeing which individual service is being problematic.
My opinions are my own, and do not necessarily represent those of my employer.
to isolate windows update so you can kill it safely, do
sc config wuauserv type= own
next time service manager starts wuauserv, it will get its own private instance of svchost.exe, which you can kill with impunity :)
My opinions are my own, and do not necessarily represent those of my employer.
How many Microsoft Engineers does it take to change a lightbulb? None. They just redefine darkness as the new standard.
There may be no "I" in team, but there's also no "F" in way.
Just shoot the control panel. Door will just open
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
Additionally, "tasklist /svc" can be used to show which services each svchost.exe is running.
No. In my case, it's trying to apply the .NET updates that completely murders my system. Apparently MS wants a gigabyte or so of free disk space on C:\ (and nowhere else) or the update will fail miserably. As it happens, my system partition has about 200MB free space, so the update disappears down a rabbit hole and never completes.
I used to think it was because it needed a bunch of temporary disk space, so last night I changed the TMP and TEMP environment variables to point to a volume with tons of free space, rebooted (because, you know, it's Windows), set just one of the several .NET updates running, then went off to see The Hobbit. When I returned some three hours later, the update had hung, the disk was idle, C:\ had zero bytes free, and the system log was corrupted.
Honestly, I don't know why anyone continues to be surprised by Redmond's rank incompetence...
Schwab
Editor, A1-AAA AmeriCaptions
Absolutely.
However, one difference between how I work now vs. how I worked 20 years ago, is that now I am invariably working on somebody else's machine.
Once upon a time, I used to spend lots of time changing my settings, making customizations to the environment, installing all kinds of tools that made my life easier.
However, a large portion of my time is spent investigating situations that aren't on my own workstations. Either lab machines or other people's environments.
I don't want to be paralyzed when I need to work out of my environment. And so I tend not to invest in or assume the presence of tools that aren't strictly necessary to do a particular task.
This is especially true when there are workable tools included in the default software distribution. So, in the case of isolating bad services, using sc.exe is perfectly sufficient. I know it's going to be there and it's going to work.
About the only basic productivity tools I frequently install any more on a windows machine are gvim and fiddler, and if the IE F12 tools were just a little bit better, I might be able to stop depending on Fiddler....
My opinions are my own, and do not necessarily represent those of my employer.
Well, then good news! Windows XP is just four months away from being perfect.
Be sure to use bullets. Using a laser will just make the blast doors close.
This is really unrealistic. What if the original hardware supplier is out of business or has discontinued the product line? The supply chain for many industrial systems of this type can be 10 levels deep, and it's simply impossible (unless you make the kind of hyper-expensive arrangements the military does so that they can keep 50's era computers running today) for contractors in that chain to do as you suggest. Commodity computers are so powerful and cheap with such ubiquitous development tools and talent that it's hard for suppliers to ignore what's available just because traditional ideas of longevity can't be trusted.
Brackets contain world's first nanosig, highly magnified:[.]
No, but you can bet there are people sitting on exploits waiting for the security updates to stop.
Once that happens, their exploits will never be fixed and they've got free reign.