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?
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.
And how exactly does Slashdot not have full Unicode support?
I'm really - I mean really, uncomfortable with the thought of Microsoft planning this kind of thing 12 years in advance...
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
Additionally, "tasklist /svc" can be used to show which services each svchost.exe is running.
Be sure to use bullets. Using a laser will just make the blast doors close.