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 saw this during video playback, checked to see why the video was barfing and saw the svchost.exe chewing up 100% just like they say. It didn't happen on boot. I think it can happen whenever Windows Update scans for updates.
However, when I killed the svchost just to watch my video, I lost sound which made me think it had to be Media Player.
Well, maybe it was; but eventually I found out about this bug and realized I had to just sit through it.
The questions for me are "WTF does it do?", "Why does it have to walk this tree, and what is so bloody CPU intensive about it?" followed by, "Why does an update have to care what patches are superseded? As long as you're up to the latest patch level, it should be all good".
I think the whole thing is fundamentally broken. You have your current version of $Thing, it depends on N other things which must be of a given version. When you upgrade $Thing you just check to make sure the things it depends on are there and if they aren't, then you get them. The old stuff? You just check to see what depends on it, and if there is no longer anything depending on it you can quarantine it. If anything tries to access a quarantined dependancy, then your dependencies are broken and you need to patch the app that tried to do that.
I know I'm glossing over some things, and package management is not trivial; but there's no excuse I can see for exponentially growing scan algorithms.
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?
I just put XP on an old laptop to run some specialized automotive software. This svchost bug has been bothering me ever since. If you kill the process it also takes out other services (like wifi).
Only the State obtains its revenue by coercion. - Murray Rothbard
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
And how exactly does Slashdot not have full Unicode support?
Slashdot used to have at least some level of Unicode support. Then vandals discovered directionality override characters and used them to break the layout and spoof moderation. The admins responded by instituting a strict code point whitelist to prevent the use of directionality overrides and the use of characters that are more useful for Unicode art (the successor to ASCII art) than for English text.
Many reasons.
1. It's light enough.
2. It's air gapped.
3. It's secured via elimination of infection vectors.
4. It's needed for legacy reasons.
5. Etc.
Is everybody stupid. XP is fast. Faster than all the current consumer grade PC OSes
I think that is what this patch... Sorry... BUG is supposed to fix.
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
They actually just fixed the SxS bloat with a patch a month or two ago. Link : here.
Big! Strong! Wow! Tada-O!
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.
Proper software firewall, hand built firewall security policy i.e. all ports stealthed nothing goes in our out without asking (important as it enables you to see if you do get hit regardless of everything else). Essentially machine is autistic to the internet unless there's software running on it that is asking for connection. This weeds out most of the problems.
I followed up by going through process list and weeding out everything I didn't need. The windows notification process to (dysfunctional) WAU and so on. If it's not needed, disable it, as it's a potential vector.
Use a decent block list. I used peerguardian's malware/known botnet blocklist. It severely cuts down on number on potential infection sources and again, it lets you spot a potential threat that has gotten through as such software would likely start hitting known botnet addresses for control information.
Sane antivirus. Specifically one that isn't too sensitive, but isn't too aggressive. Check everything with it.
Reasonably updated internet facing software. That's browser, mail software and so on. It may also help to sandbox these with something like sandboxie (I didn't bother because I kept them up to date and felt that was enough, now that I no longer do so on this machine I sandbox the browser and email software).
Effectively a mix of sane security policy, locked down machine and common sense. What most people appear to not understand on /. is that windows being vulnerable isn't the end of the world, nor is it a guarantee of infection. You still need an infection vector and infection source in addition to vulnerability to get infected, and locking those down is often enough, as long as you're not someone like Valve who is going to get hit by specifically tailored directed attack, you're going to be fine. Or at least much better off than someone who's all updated but doesn't secure infection vectors or infection sources.
"Tried" several times to patch an error but "couldn't". "Coincidence" that it is planning to retire the platform. Smells a lot like planned obsolescence. Helps sell more junk products that become useless faster. Buy a new one!
Build your own energy sources from scratch. http://otherpower.com/
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.