Windows users are still hit with error 0x8000FFFF
Windows administrators who install the October 2018 rollup patch on a Windows 7 device may run into error 0x8000FFFF once again.
Microsoft explained when update error 0x8000FFFF happens on Windows Update last month.
It boiled down to this: Microsoft released a Servicing Stack Update for the operating system back in October 2016 and made that update a requirement for the August 2018 update for Windows 7 Service Pack 1.
Systems threw error 0x8000FFFF when administrators attempted to install the monthly update rollout in August 2018 if the Servicing Stack Update was not installed on the device.
Microsoft promised to resolve the issue by pushing the Servicing Stack Update again to Windows Update. Previously, while it was marked critical back then, it was not installed on devices serviced with security updates only.
Microsoft wanted to avoid the same scenario by adding the security tag to the reissued update so that admins would not ignore it anymore.
Things are still not alright
Ideally, the issue should have been resolved by now. Admins should notice the Servicing Stack Update and install it on devices so that monthly rollup patches can be installed.
Problem is, this is not necessarily the case. Microsoft marked the Servicing Stack Update as exclusive and that turned out to cause another issue. Exclusive updates are not distributed with other updates. So, any other update pushed to the queue needs to be installed before the exclusive update can be installed using Windows Update.
As Woody Leonard puts it:
In simplest terms, a Windows update that’s marked “exclusive†won’t appear in the Update list until the whole queue is cleared out, either by installing everything that’s backed up, or by hiding available updates.
In other words: the required update to install the monthly rollup patch does not show up until the rollup update is installed. Since the rollup update requires the Servicing Stack Update to be installed, error 0x8000FFF is thrown and the vicious circle of getting nowhere continues.
Microsoft has yet to respond to the issue. Administrators who run into the issue may want to download the Servicing Stack Update from the Microsoft Update Catalog website to install it manually prior to running Windows Update or using other automated update systems to push the most recent updates to these systems.
Closing Words
It is clear that the updating system is still flawed in regards to Servicing Stack Updates, at least on Windows 7 devices. It would be a lot better if the update system would check for updates for components that it depends on first before it starts to check for other updates.
Issues like error 0x8000FFF would never have happened in that scenario.
Now You: What is your take on this never-ending story?
Very much thank you. This advice solved my problem.
“Microsoft released a Servicing Stack Update for the operating system back in October 2016[…]” : that’s when I stopped Windows Updates here on Windows 7. Two years now observing this tragicomedy which is even closer to a tragedy on Windows 10 systems and happy to be but a spectator.
Windows Update has become a total mess, need to say.
“Vicious” like their lobbying corrupting deputies and senators making my country a vassal of the USA. A “vicious circle” which make the USA great again.
@Anonymous:
“Vicious†like their lobbying that corrupts deputies and senators and makes my country their vassal, like the USA.
Fixed that for you, with greetings from one vassal’s serf to another’s.
Merci Peterc
I have it installed
imgur.com/ynP8bFK
It’s a bit annoying, but normally it gets installed from my experience. The bigger problem are these four updates:
3102810
949104
3020369
3172605
Without which WIndows Update on a fresh 7 does not work, and Microsoft only tries to send one of them, the WU agent update which is not enough to make it work.
I would still recommend Simplix Update Pack on 7, but if you really want to get everything via WU then manually installing those 4 updates, in that order and restart after every one is completed, is the way to make it work properly on 7.
One could get the impression this is M$ way to convince Win7 users to switch to Win10. But this would be a very nasty assumption since we all know M$ being a very user friendly company.
Martin, as this only affects Windows 7, you should add 7 to the sotry title.
That is unless it is your intent to get people to click on a link irrelevant to them.
Meanwhile my Linux box continues updating in the background with never a reboot even requested except for a kernel update…
Oh, and no system deleted files, either…
SO glad I’m no longer running Windows (for 12+ years now).
Have to admit Linux solves a lot of problems. I don’t really understand all of the business side of things that prevents MS from creating program repositories and a similar update system. So simple!
Aha! So you *admit* you have to reboot after a kernel update! Where is your Linux-on-the-Desktop god, *now*? ;-)
Just kidding. In around two years of running Linux Mint Cinnamon in a virtual machine I’ve had literally *one* genuine problem with the updating process itself: after doing a fresh install of Linux Mint 19 Cinnamon in VirtualBox and running the first big post-install update, a package was reported as having failed to install, but when I refreshed Update Manager it didn’t show up. When I ran Update Manager again after rebooting, it showed up and installed without issue. (I don’t remember whether there was a kernel upgrade in that first big post-install update.)
Apart from that, I have to think pretty hard to come up with “updating problems.” Once, my selected repository (the math department of my local university) apparently went offline for a short while. I started testing different repositories for speed, and my preferred one came back online (and went back to the top as fastest) while I was doing so. I’m not sure that a short-lived, one-off instance of server downtime *really* qualifies as an updating problem, compared to some of the frequent mind-numbing delays I used to run into with Windows Update (or, around a year ago, with Deepin’s repositories, from here in the US).
As for buggy *updates*, there was a minor bug in the updated version of Font Manager that came with one of Linux Mint’s point-release upgrades. (Importing fonts via Font Manager’s GUI didn’t work anymore.) I’m a Linux noob, and it took me maybe three minutes of searching online to find a snippet of command-line code that fixed the problem. A fixed version of Font Manager was released shortly afterwards.
And starting with Linux Mint 18.1 or 18.2 Cinnamon, I had a problem with certain Menu categories failing to populate. But it turns out that was the result of an incompatibility between Cinnamon’s bundled desktop themes and my particular implementation of VirtualBox on my particular computer. I set up the same version of Linux Mint in the same version of VirtualBox on someone else’s computer, and all of the Menu categories populated just fine with all of the bundled desktop themes. On my computer, I solved the problem by installing a third-party desktop theme. I’ve never seen this problem reported for a bare-metal install, so I’m going to consider it an idiosyncratic VirtualBox problem, not a Linux Mint problem. (Linux Mint, along with the now-defunct Chapeau Linux, has actually been the least problematic distro for me in terms of VirtualBox compatibility.)
So yes, compared to updating Windows in the past three and a half year or so, updating Linux — mainstream, non-bleeding-edge distros, at least — is an absolute joy.
that’s sort of comparing apples and oranges though seeing as this problem arises when people choose not to install certain updates.
however the no reboot thing is very valid and desirable.
@Richard Steven Hack: And that is relevant to this story how? It’s great for inflating your smugness but of little use to anyone.
Hawack, you are just as bad. Actually you’re worse by volume.
@Don Gately: Richard Steven Hack’s post is relevant because Windows 7, Windows 8.1, and Windows 10 users have been afflicted by frequent, sometimes serious update problems for several years now. Before late spring 2015, I didn’t think twice about allowing Windows to install updates automatically. That’s *out of the question* now, even for computers I may not see and manually update for two or three months at a stretch.
Many Windows users are being driven to seek other platforms because of two things: (1) loss of privacy and user control; and (2) unreliable, unpredictable updates. Linux is often rejected as an alternative out of hand, in part because “it’s too hard” and “it breaks too easily,” requiring high-level geek skills to fix. Richard’s experience, which mirrors my own, suggests that Linux updates actually break things considerably less often than Windows updates do, at least ever since Satya Nadella fired half of Microsoft’s testing and quality-assurance staff. And that’s useful for Windows users to know. There are reasons Linux might not be a suitable alternative for some Windows users, but buggier updating is not one of them.
Why exactly should people, who have taken all due steps to protect themselves, also afford themselves the chance to be a little “smug”.
After all, “smug” was your word anyway.
I would never berate anyone for looking down at the mess, and feeling greatly relieved that they are not also affected.
It does not mean they are happy for anyone else’s misery….just that they have saved themselves in a sea of nonsense, when it refers to what has become of Windows Updates.
Belarc Advisor was quick to update its Windows 7 database this month and flagged three missing security updates on the day after Patch Tuesday (a record?), including the Servicing Stack Update discussed here. WSUS Offline Update wasn’t so fast, apparently. Either that, or it blacklisted all three updates for some reason, maybe until they’d been vetted by real-world deployment.
I don’t know whether the Servicing Stack Update is necessary for people like me who have stopped using Windows Update and rely primarily on WSUS Offline Update, but I don’t like having to remember “false positives,” so I downloaded and installed KB3177467 manually. I wasn’t prompted to reboot, but I did so anyway (based on experience with Windows updates in general and what I’d read about KB3177467 in particular). It took a *long* time after the reboot to get to the Welcome Screen, but the install seems to have gone fine, and I’m down to two missing updates in Belarc Advisor.
As of today, two days after Patch Tuesday, WSUS Offline Update *does* seem to have downloaded the two missing security updates (KB4462915 and KB4462949), and I didn’t find them in any of WSUS Offline Update’s blacklists, so it’s time for another go at installing them. (I haven’t spotted any reports of problems with these updates, and I made a fresh clone of my system drive yesterday, so I’m not too worried.) Here goes nothing!
Update: Now that stage 1 of WSUS Offline Update had finally downloaded the security updates I was missing, I ran stage 2, only to run into a familiar Windows problem for the first time in quite a while:
I had selected WOU’s automatic reboot and recall option, and at shutdown, the computer hung at “Preparing to configure Windows” for a good 30 minutes, with no visible hard drive activity. Control-alt-delete didn’t work, so I tapped the power button for a controlled shutdown. I wasn’t presented any shutdown options, but the screen went off, there was a click, and the system did a kind of quick-resume without first POSTing, taking me right back to the pre-shutdown “Preparing to configure Windows” screen … with no hard drive activity.
This time I held the power button down for five seconds to do a hard shutdown, and the computer shut down. When I started the computer up again, it POSTed and then went directly to the pre-shutdown configuration stage (configuring up to 30%). Then it rebooted automatically and did the post-reboot configuration state (configuring from 31% to 100%). There was apparently no need for WOU to do a recall, and after logging in I examined WSUS’s installation log for errors and warnings, found nothing worrisome, dismissed the log, and my Desktop loaded more or less normally. (Iconoid initially thought it couldn’t hook into the Desktop, but it was wrong. Iconoid seemed to working fine, but I exited and restarted it manually, just for good measure.)
There are no obviously horrible problems, so far. Belarc Advisor is giving me a clean bill of health, so I am theoretically protected from all known critical and important bogeymen (except for Spectre). WPD (Windows Privacy Dashboard) showed that “Microsoft Compatibility Appraiser” and “ProgramDataUpdater” had either been added or turned back on (in the Base Privacy Settings section), so I turned them off. There weren’t any new rules to download for the Firewall section’s “Spy” category. (Incidentally, there have been two new updates to WPD in quick succession over the past two days. I updated it yesterday and had to update it again today. The newest version didn’t find anything that the previous version didn’t find, but that just might be true for Windows 7, so Windows 8 and 10 users might want to update just in case.)
Anyway, this month’s round of Patch Tuesday security updates using WSUS Offline Update was definitely more of a hassle than usual, but it seems to have worked okay. I’m guessing that the hang I experienced would have happened with Windows Update, too, and that it would have been a little scary for people unfamiliar with how to deal with post-update hangs. (You know what they say: “Windows is a *fine* operating system, but it *just isn’t ready* for desktop use…” ;-)
Second Update: I had to swap in my clone drive today! HOWEVER, it wasn’t because of this month’s Patch Tuesday updates — it was because I updated USBPcap (an optional component of Wireshark) and the update borked my system.
After uninstalling the old version of USBPcap, restarting, installing the new version, and restarting again, the computer just hung at the “Starting Windows” screen. System Repair didn’t work; the Repair Console command-line stuff I tried didn’t work; and System Restore would have zapped *way* too much stuff, even though a new restore point was created immediately before the USBPcap install. (What’s *that* about, anyway? What’s the point of making a new restore point if a bunch of stuff you installed and updated *before* the restore point is going to get zapped anyway? I sure hope Timeshift works better in Linux Mint than System Restore does in Windows.)
Anyway, the clone I made three days ago booted just fine, thanks to Macrium Reflect, and most of my recent configuration changes and *all* of my data were present and up to date on it, thanks to my FreeFileSync/RealTimeSync routines. The downside is that I have to clone my new system drive (the old, unborked clone drive) to my new clone drive (the old, borked system drive), and then apply the Patch Tuesday updates *all over again*. It could be much, much worse, however: I could have to reinstall and reconfigure everything from scratch. And on the upside, I’ll be *twice* as practiced at dealing with this month’s weird Patch Tuesday idiosyncrasies when I tackle the other computers I look after!