I happen to own several old laptops, now about 10 years old, that had the misfortune of being delivered with a Windows Vista license and matching Windows Vista OEM installations on their recovery partitions/media. About a year ago, I noticed that updating Vista no longer worked. That is to say, trying to look for updates just took for ever and ever, eating CPU cycles but never coming up with any result. Nothing happened overnight, nothing happened after two or three days, Windows Update just kept wasting CPU cycles.
This problem started sometime in early 2017, and only affected Vista SP2. It was perfectly possible to update a Vista installation to SP1 and then SP2 through Windows Update, but not to the latest state, it would just get stuck. The same problem was visible on three laptops and in several VMs.
Over a month ago I decided to see what would happen if I just left one of those old laptops running. It was a circa 2008 Compaq Presario V3000 with an AMD Turion 64 X2 processor. I booted it up and left it chugging along in the basement. Every few days I’d check on it and the CPU fans were still spinning, with Windows Update keeping one CPU core more or less fully loaded. Then I went on vacation for over a week, and when I came back, the fans were still spinning, and Windows Update was still busy.
Then one day I checked on the laptop and it was silent. Not dead, just resting. I started wondering what happened and soon enough I discovered that lo and behold, Windows Update in fact installed a number of updates from 2017 and was finally done! And that is why the laptop could finally go to sleep.
I don’t know how long the process actually took, but I estimate that it was about three weeks, give or take a few days (more likely give than take).
Now, a fully updated Windows Vista laptop is only marginally more useful than one which keeps wasting CPU cycles by checking for updates. The experiment was however useful in highlighting that a) Windows Update is (or at least was) seriously out of control, and that b) even if it took several weeks, the update process eventually did finish, as surprising as that was.
This is a good example of software which is functional yet its performance is so awful that it might as well be completely broken. With no progress indication whatsoever, after a day or two users have absolutely no reason to expect that the update process might ever successfully complete and give up.
I ran into this updating a Vista desktop PC. It seems to be quite a common problem; the usual explanation is that there’s an algorithm in the update utility which becomes horribly inefficient as more updates are loaded.
The solution seems to be to stop the Windows Update service and manually load a number of updates in a specified order.
I don’t have the KB # but awhile back there was an update for Windows 7 that fixed the long update issue. Obviously it was best to manually download it or integrate the update into the ISO before install than trying to download through Windows Update. I have Windows 10 running on my parents Dell Latitudes from 2006 with Core Duo and C2D chips and they work fine for surfing the Internet but you’re probably better off with Linux on those machines
WSUS offline update v 9.2.4 (latest support for the XP /2003 /Vista)
Windows Update had the same problem with Windows XP in its twilight years. The algorithm that determines the installed patches and dependencies becomes overloaded after years of patches from a “base” level (the service pack). Windows 7 had the problem too, but Microsoft sort of fixed it with the cumulative monthly rollup updates. For old machines, I just make a CD of patches using WSUS Offline Update and patch the system that way.
Windows Update also likes to break in unexplained ways. My main Windows 7 machine no longer shows the monthly rollup updates on WU. I have to download and manually install it every month now. I tried just about everything to fix it (rebuild the database, etc.) and it still doesn’t work right.
There was a PTF for Windows 7 that seems to have corrected the bad behaviour, or at least, made it far less egregious. Windows Update on 8.x or 10 seems to be fine.
If I need to deploy a new Windows 7 system for whatever reason, I use: https://decentsecurity.com/enterprise/#/windows-7-fast-update/
Windows Update even on Windows 10 is terrible. I have had it start downloading updates and take over my internet connection (DSL) for spans up to hours. It basically makes the browser worthless, loading a page of simple text would timeout 9 times out of 10. Then after it spends many minutes installing as it shuts down, on restart I have had it take 1-2 hours to complete the install and boot the system to a usable state. I don’t use that machine too often so it is typically powered off, so much for a quick 30 minute session to get something done when it takes over an hour to boot. It will be the one main issue that moves me completely away from Windows, mostly there already.
Tried that, didn’t work for me. That is to say, it had the exact same problem figuring out the update plan for ever and ever.
Windows 7 could also suffer from long update checks but never that bad. And yes, the current behavior of Windows 7 is decent (no worse than when Windows 7 was new).
Speaking of Vista, I’m updating a 2008 server right now. I loaded the SP1, and it’s currently installing 269 updates. It’s been going for hours but the progress – o – meter is going though….
I wonder if that Aero thing is screwing it up, as I’m RDP’d into the 2008 server.
You must be the only one in the world who actually ran this test to completion! Everyone else just gives up and stays un-updated.
For Vista users, this issue started coming up in 2016. For a long time the best solution was the manual update steps at
http://wu.krelay.de/en/
You can still use those steps for Windows 7. But after Microsoft stopped updates to Vista, krelay put up the last set of Vista updates at http://wu.krelay.de/en/Vista.htm, then effectively announced “You’re on your own.”
There’s a forum thread about the issue (that’s grown to 33 pages) at:
https://www.bleepingcomputer.com/forums/t/611898/windows-vista-update-hangs-at-checking-for-updates/
You could say there’s light at the end of the tunnel… but it’s a really, really long tunnel.
I think a huge problem is that the update check isn’t incremental, and every time the system is rebooted it starts from scratch.
The latest WSUS that should work on XP won’t download the uptade that came around new year last winter, which fixes the CPU bugs that were uncovered at that time.
(Yes, there were actually two updates released for XP at that time, even though the support for the XP based POSready and WES9 (or whatever they are called) ended before that).
Embedded XP is still supported until 2019.
Oh!
Sorry for a stupid question that I really should be able to find the answer for, but is “Embedded XP” the same as the “WES9/POSready” thing that you can registry hack a normal XP into thinking it is?
If so it seems like there haven’t been any updates in a long while.
Probably because the supported stuff might actually be rather bug free.
http://catalog.update.microsoft.com/v7/site/Search.aspx?q=posready
It receives regular monthly updates still. AFAIK they haven’t bricked anyone’s machine that used the registry tweak yet either.
Trowa: Oh shit, then Windows Update is broken on my old machines.
But anywas the WSUS tool seems to not download anything released after 2017-06-13
Could this be a language thing, i.e. that the english versions is still supported but they dropped support for other languages?
Sorry for posting two replies. Just saw that there were actually updates for one of my old machines. The other one suffers from the “three weeks” problem but WSUS won’t download any new updates. Might leave that machine on the next time I’m going on vacation 🙂
Sorry to go off topic, but I wanna test something with your comment system. I hope you don’t mind.
(Heeeeeere’s Unicode…)
Here is some text.
And here’s a greek letter: μ.
Part of the problem (part!) is that Windows Update calls QueryPerformanceFrequency constantly, and this is a syscall on Windows, and sometimes this is a fairly expensive syscall.
One fix (though http://wu.krelay.de/en/ works better) is to patch kernel32.dll in memory for the Windows Update process so that QueryPerformanceFrequency only makes the syscall once, and subsequent calls return the value it got the first time. Here is one such tool that does this: .
Windows Update is an excellent reason to not use Windows.
I’m guessing my angle brackets got interpreted as HTML…let me try that again:
Here is one such tool that does this: https://github.com/dmo2118/PatchQPF
Did you really mean QueryPerformanceFreuency or QueryPerformanceCounter? The former should be a constant. The latter is not and what the call actually does is pretty hardware specific. Some methods are more expensive than others.
Agree about Windows Update. Worst in the industry, no competition.
Yes, I really did mean QueryPerformanceFrequency. QueryPerformanceFrequency calls NtQueryPerformanceCounter, which gets both the time (always), and the frequency (optional).
I see. That’s then one of the cases where the documentation is seriously at odds with actual implementation. Because the QueryPerformanceFrequency documentation strongly suggests that it’s a cheap API call returning a constant. Actually querying the perf counter is of course a very different story.
I remember reading some benchmark report mentioning that on recent Intel CPUs, reading the HPET is shockingly expensive, noticeably more so than it was on earlier Intels and much slower than on AMDs. That’s where the Windows configuration makes a difference, and API calls like QueryPerformanceFrequency can be much more expensive than one would expect.
For anyone experiencing these problems on a (hacked) Windows XP PosReady System (I recently had the problem getting it up-to-date again after I had reset the VM to an old snapshot):
The one update which apparently solved the Windows Update issue, which I had to install manually (in addition to those found elsewhere) is the Cumulative Update for IE8. I did that for July 2018, and had to do do it for August also, because it again showed the same symptoms. But once again, installing the IE update manually (obtained from the Update Catalog) helped. The other updates could be installed normally.
Thank you Joachim Mairböck, that did the trick on my hacked XP machines!
Something that I’ve done with my Windows 10 machines is use WUB (Windows Update Blocker) (google it.)
It prevents update from running until you turn wub off and let it run when you want it to run. Never fear that in the middle of your presentation that windows will start an update and wreck your screen.