Posted
by
samzenpuson Monday December 16, 2013 @05:57PM
from the no-pep-in-your-step dept.

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?

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).

It just isn't possible. There is a whole api (WUA) built on top of how it works now. Everything using it would fail if it moved to something different. That is, it is very evident that it was built with the update format currently in use to guide its direction. An emulation layer may not be possible, and even if it is, may not be more efficient than what is there now and also is work toward something that is EOL in 4 months.

The current way it works now, is the client downloads wsusscn2.cab, which in turn contains package.cab (among many others), which contains package.xml. Package.xml contains the updates in such a way that is flexible in that it can address more than one OS/platform/application/etc per patch, or more than one patch per update, or more than one file per patch, and so on. The Update nodes only point to categories/patches/files/locations/prerequisites/revision/etc via ids which have to be looked up deep in the file. Right now, that xml file is over 65MB. It would have made this easy if it were stored in a relation database, instead of an xml file, but it isn't and like I said, the API was built around the source of the information being an xml file, among other things.

I'm not sure why any intelligent person would think this is funny. THREE operating systems have come out after XP-- it's not like this 12 year old OS is the latest from Microsoft. You're making Linux zealots look even dumber than they are.

That's exactly why it's funny, you crusty old bastard. (At least, judging by your UID, anyway....)Besides, I'm guessing in a few years we'll start seeing the same problem on Vista and 7, too.

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.;-)

Why? People paid good money for working supported product. Just because Microsoft wants to bait and switch doesn't make it right. I hope some deep pockets corporation sues the bejesus out of them to force this issue.

I don't see a bait and switch. People knew(or could find out if they wanted) the EOL dates before they purchased it with their "good money", and MS has been extending them since many many years even though they didn't have to. That sounds exactly like the opposite of a bait and switch.

If there's no more updates, what's the point of fixing the update mechanism?

There will be more updates. It just means that they won't be free after April. My company has already begun discussions with MS as to how much they will have to pay for those updates as the sheer number of computers and lack of staff means that the upgrade to Win7 will not be done by that time. Figure in all the various departments that have apps that won't run in Win 7 or can't be upgraded till capital budget has the money for the upgrades and that could take years still. I'm sure many other large corps ar

It killed my Web browsing virtual machine until I used an offline update utility and fixed it manually.

Yes, XP needs to die, because it is made to deal with threats from 2000-2001, with added security patches strapped on as the need arose. Windows 7 and newer help address this issue.

However, I know plenty of places where XP is used that can't be fixed by a upgrade or platform change. Embedded stuff for example. Another are dedicated machinery that interfaces with a PC, does have newer drivers, and likely will not get newer drivers. A friend's $3000 sewing machine is one example.

Another person's CNC wood mill is another item. So, those machines are stuck with XP pretty much for good, because who is going to throw out a perfectly functioning mill just because it requires a legacy OS? Even some CD/DVD duplicators only will interface with XP, and moving to Vista or newer will be an exercise in futility.

Another person's CNC wood mill is another item. So, those machines are stuck with XP pretty much for good, because who is going to throw out a perfectly functioning mill just because it requires a legacy OS?

There are still options. You'd be surprised how much old oddball hardware *someone out there* has written Linux drivers for.

Failing that, there's Wine. Or XP emulation mode in Win 7.

Or pay a homeless developer some cash & Red Bull to write you some new software. CAM has been around forever and it's not complicated.

Yes, XP needs to die, because it is made to deal with threats from 2000-2001, with added security patches strapped on as the need arose. Windows 7 and newer help address this issue.

Help address this issue..except not really.:/ Windows 7 was made to deal with threats from 2009-2010, with added security patches strapped on as the need arose. Windows 8 was made to deal with threats from 2012-2013, with added security patches strapped on as the need arose. You see a trend? The biggest things that consisten

Yes, XP needs to die, because it is made to deal with threats from 2000-2001, with added security patches strapped on as the need arose. Windows 7 and newer help address this issue.

No, not really. Windows 7's - and for that matter Linux's - security model is centered around users rather than applications. It's designed for multi-user central computers of old, not modern single-user desktops that run random code downloaded from the Internet. It protects the system from user-level code, but your personal files are screwed, should any of it be malicious. And not even the system is really safe: a program asks for administrative privileges, and you have no option to give it "fake" permissions in its own little sandbox or even any way of knowing what it has done, even after the fact.

Android comes closer, but still has the problem of not allowing you to fake permissions. I doubt that will change, it ultimately being a glorified data mining and ad delivery platform for Google.

As for a better security model, I'd really like to see a "tree" of virtual machines, with every program running in its own leaf it can mess to its digital heart's contents and any changes being merged into upper-level machine only at the approval of said upper level. That way you could do away entirely with the concept of administrator - since every program is the master of its own virtual machine - and try out new programs safely, since no matter what devastation they cause it's limited to their own playpen.

After MS effectively killed off the desktop-database competition, MS-Access mostly stagnated. I've seen silly bugs last for almost a decade.

They mostly just shuffled the menus around (driving existing users nuts), and added an HMTL-like forms/report editor about 5 years ago. I prefer the older WYSIWYG editor for most tasks, which is only half supported now. WYSIWYG is more natural for fine control where managers want to squish as much as possible on a single page. (Whether that's a good h

Upgrading to Windows 7 or Windows 8 certainly fixes one issue, but it creates a whole new set of problems.

1.) There is guarantee that this won't be a problem in Win7 or Win8. This only showed up when there were *Lots* of updates to IE. In three or four years, Win7 could have a similar problem, or at least a problem with similar symptoms.

2.) Win7 did redesign the update process. (Actually Vista first showed up with it, but many people are skipping Vista altogether.) But in their great (for very, very small

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.

Why not just do:net stop wuauservThat way you're not killing processes, and possibly corrupting the update database, which causes its own set of problems.In fact, I've got a desktop icon that does exactly that on one of my XP machines, so I can kill it quickly when I need the machine to be responsive in less than 10 minutes...

Wow. 4 hours for your VM to check for updates? What the heck processor are you running this thing on? I've got a bare-metal 1GHz PIII with 256MB RAM (all it will hold, unfortunately) and it only takes 10 minutes or so to finish the update check process.

I've noticed that this is an issue on Windows Server 2003 (I believe R2 included). I have noticed that this is less of an issue once IE8 is installed (this should have already been done by this point), but this is still definitely an issue. I will be glad when I am rid of this OS (soon!).

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.

I've thought the same thing, especially since I saw the delay go from nearly no delay to an hour delay from one month to the next. There was no "exponential Increase", it was more like a step function. That is why I think the update delay was intentional in order to push people off XP.

My work computer has been cursed with this problem. Eventually it started locking up every patch Tuesday, so I just killed automatic updates..... problem solved. Something with the Dell OEM XP install is clearly fubared with regards to the actual patch service as manually installing an update causes the machine to lock up too. Rebooting causes an evil "We had to shut your machine down to protect its hardware" blue screen until I go into safe mode once and reboot again. IT will get around to it eventually. I

Even better: install the latest Internet Explorer cumulative security update manually, then re-run Windows Update. It seems that if IE is fully up-to-date, WU can chew through the remaining updates much faster. Then you're good for another month.

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....

Because there aren't enough months of Windows XP's extended support left for it to be worth fixing. Microsoft refused to fix a few bugs near the end of Windows 98's service life as well; see this story from June 2006 [slashdot.org].

I run a small computer store and this issue has been driving me crazy the last few weeks, we have had a few XP machines come back because customers are complaining they are so slow! When we refurbished them before these patches they were fine! I have had to disable Windows update to fix the issue, not the best solution at all. 100% CPU from svchost.exe for hours, how can Microsoft mess up so bad..!

I couldn't tell you why, but I haven't (yet) observed the described behavior on my XP system. The auto-updater ususally settles down in a matter of minutes.

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.

This has been happening on and off for more than a year. I found the last couple of times that it was helped if I manually fetched and installed the latest "Cumulative Security Update for Internet Explorer" for version 8 (http://technet.microsoft.com/en-us/security/bulletin/ms13-088 at time of writing). Never understood why; perhaps it allows a serious chunk of the search tree to be pruned quickly avoiding the exponential stupidity.

If you need to stop the 100% CPU while you fetch this then Start -> Run, "Services.msc", locate and stop "Automatic Updates".

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.

It's not just a (physical, building) security system, it's ANY system. Why on earth would you choose to base your product (something that presumably companies will use for many, many years) on something that will have no security support in just 4 months? It's really quite idiotic; there's lots of freely-available OSes (including an RTOS) out there that you can use instead which don't have this problem.

There are lots options here any current *BSD or Linux Kernel with basic gnu tools and a purpose built interface would still be lighter than XP. No X and Gnome 3 or KDE 5 won't be but there are plenty of things that would. That's before you even look into the other choices like QNX and friends out there as well.

2. It's air gapped.

That's bullshit son and you know it. Nothing air-gapped ever stays air-gapped. Anyone who has worked in a manufacturing environment and delt with plant engineers knows "it won't be on the network,

We are talking about XP. Not other OSs. It's exceptionally obvious that it's light enough stands for "it's light enough to run wintel software on older machines".

I genuinely don't understand why there are so many people here on slashdot talking about windows security and not understanding it. It's entirely possible to secure a completely vanilla XP machine (zero updates, just basic boxed copy from release) to use on a fixed, open to internet static IP. I have done so myself, after my first XP machine borked

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.

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.

I have a perfectly fine multipage scanner here that doesn't have drivers for Windows 7 and the manufacturer is out of business. You do know that Windows 7 implemented driver signing right? So even if you do find a legacy driver it probably won't start because it won't be signed. And don't give me this "Linux is your route" because no driver exists for it there either. So my choices are toss a perfectly working, expensive at the time and in demand scanner just to update from a working OS to one that doesn't or stick with what is working.... Hmmmm Hard choice that one.

It would have helped if you mentioned brand and model. Perhaps people could have helped you out...

The fact that you think that #2 and #3 are the same thing shows a massive level of ignorance of IT, to the point where I have a hard time seeing how we could have any kind of argument on topic of IT security without you taking at least a few basic courses on IT security.

"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!

As mentioned above win XP is nearing its end of life where it will not get anymore security updates. Software updates can be done without throwing away hardware. That's a good reason to change the software on the machine to something else: win 7, RHEL, SUSE, something.

Actually, I installed windows 7 on a lenovo laptop that shipped with XP. While it didn't look as fancy as it could have (I blame the intel graphics card) it was very effective. It even booted faster and ran smoother than a fresh XP installation. Also all the hardware was recognized and worked with the Win 7 drivers.

In any case, something needs to be done to the boxes. If the software cannot be updated for what ever reason, they should be replaced. Leaving unpatchable xp boxes is not a good solution. I don't think you can call such boxes "perfectly fine" if they can't be updated to a secure solution. Unless, you have a strange set up with an unbreachable air gap that doesn't allow any networked connections, or physical media. If that were the case, they wouldn't care how long windows updates take as it would be impossi

Any car built in the last 50 years is capable of highway speeds. I assume that you are still driving the first car that you ever bought?

Most people replace their cars every 5 years, the average life expectancy of a car especially in places where salt is an issue is 10-15 years. In places with high grades, which can put a heavy toll on the engine and drivetrain it's 8-12 years.

This patch was premature. It wasn't supposed to be released until the last patch batch before XP goes out of support. Fortunately they have more like these to share with us between now and March, so the motivation to get off XP by April should be quite strong.

Not trying to be patronizing or sarcastic here, but have you thought about Linux? Throw Lubuntu on it and it'll run at least twice as fast. For the small amount of things you say they do on it, there really shouldn't be many migration pains.

Slashdot used to have at least some level of Unicode support. Then vandals discovered directionality override characters [slashdot.org] 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.

But somehow most websites out there manage to implement Unicode just fine. Which proves that it is possible to implement good Unicode support and avoid all those bombs. Seems that Slashdot just chose the easy way out of the problems.

"It's just a temporary fix. We will replace it with something better after we meet the next deadline."

Keep saying that until you are reassigned to a different team or "decide to pursue interests outside of the company", and then it changes from a temporary fix to a permanent and immutable bit of legacy code.

It's OK to check in as long as you meet your deadline and it seems to work. Performance (esp. years down the road) isn't important. Do you think people buying computers at Best Buy are going to avoid your product because it's going to become ridiculously slow many years later? Of course not. So just throw in a crappy algorithm, it doesn't matter. It's not like this is a free/open-source OS where someone will fix it just out of academic interest. With commercial code, if there isn't a compelling busine

This is built into their display list widget. How shameful past the early 1980s.

What are you talking about? Do you not realize that far superior sorting algorithms were invented as long ago as the 40s? Quicksort was invented in 1960, and mergesort was invented in 1945, for example. Being the early 1980s is no excuse for using crappy sort algorithms.

Well, if they did it right they would be on SP5 or SP6 by now, since they should be releasing a new SP annually to roll up all the existing patches.

I seem to recall there being a demand for an SP4 at least two years ago due to the volume of updates post-SP3. I think the motivation wasn't necessarily SVCHOST but just the sheer download & install time for even new installs with SP3 slipstreamed in.

You would think this would also somewhat lighten the support burden and maybe even the burden on update serv