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."
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.
The dependency system in dpkg has been shown to be powerful enough to express sudoku puzzles which then APT has to solve to resolve conflicts. Technically still potentially exponential with improper use (I trust Microsoft would find some such non-working model reliably).
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.
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.
How much, exactly, would you charge for a fully functioning OS and a steady stream of updates until the end of time? I'd like to see the math on this.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.