Microsoft explains Windows 7 update error 0x8000FFFF
A group of administrators and users who tried to install the August or September 2018 patches on Windows 7 devices reported that the update installation would fail withÂ error 0x8000FFFF.
The issue affected the monthly rollup updates and the security-only updates and meant that important security updates could not be installed on affected machines until the issue was resolved.
Admins and users who check the support article will notice that the error is listed as a known issue but that was not the case when the update was first released.
This update may fail to install with error 0x8000FFFF.
Before installing this update, install KB3177467, the last Servicing Stack Update for Windows 7 and Windows Server 2008 R2 SP1, to resolve this issue.
Microsoft published an article on the Windows IT Pro blog that provides details on the issue and why it was not recognized by Microsoft earlier.
The company released a Servicing Stack Update for Windows 7 Service Pack 1 in October 2016. You can look it up underÂ KB3177467.
The update was marked critical even though it was not a security update for Windows 7. The reason that Microsoft gives for the rating is that servicing stack updates are essential for the updating process.
Servicing stack updates, or SSUs, are periodic updates released to specifically service or update the software stack for Windows platforms. These are fixes to the code that process and manage updates that need separate servicing periodically to improve the reliability of the update process, or address issue(s) that prevent patching some other part of the OS with the monthly latest cumulative update (LCU).
Servicing stack updates ensure that you have a robust and reliable servicing stack so that your devices receive and install Microsoft security fixes.
Some organizations, admins and home users did not install the update on devices running Windows 7 and not doing so did not appear to have a negative effect on the update process as updates that were released after the release of the servicing stack update installed just fine.
That changed with the release of the August 2018 update for Windows 7 SP1. The update could not be installed on devices that did not have the servicing stack update installed; these devices threw errorÂ error 0x8000FFFF instead.
Installation of KB3177467 resolved the issue immediately but users and admins did not know about that until Microsoft added the information to the known issues of these updates.
Why did not Microsoft catch the error?
Microsoft states that it tests its monthly patches against fully patched systems only. The issue slipped by because Microsoft tested the patches only on systems with the updated servicing stack.
What is Microsoft going to do about it to avoid future issues?
Microsoft plans to reissue the updateÂ KB3177467 on the October 2018 Update Tuesday and classify it as a security update. While not a security update, classifying the update as such ensures that the update won't go unnoticed by customers this time.
Any future servicing stack update will be classified as a security update as well.
Now You: Did you experience the issue?
That one guy, Simplix, does more testing to his update pack for Windows 7 alone to ensure it installs fine every month than Microsoft does combined for all their supported software.
So basically it’s fallout from their attempts at forcing people to upgrade to W10, IIRC most Servicing Stack Updates come with support articles that mention making it easier to upgrade to newer OS’s such as W10 and when people read that they’re immediately suspicious due to previous attempts at slipping W10 onto peoples systems.
Web sites should just stop covering Microsoft completely. Just stick a fork in it. It’s done.
On a system with automatic updates enabled wouldn’t the SSUs be installed automatically?
In other words, they don’t test themselves their own crap patches. Why don’t they release a ‘rolling’ Windows 10 version like ArchLinux, to make possible to avoid the complete ISO upgrades twice per year? I am expecting W10 1809, however I must install again first 1803 and then upgrade to 1803, that means 6 Gb at least of data to download and to uninstall almost all my programs to leave free space for that amount of data. My SSD is not so big enough to play these funny upgrade games! My sister also has a ‘major’ problem, because her version 1803 works like a charm in her computer (yes, it’s so hard to say that if your W10 version works good you may have a problem, because the lottery of bugs is expecting for you and probably something will fail). :(
When 1809 comes out, just download the MediaCreationTool1809 and install it directly. There is no need to install 1803 first.
Martin’s article says
“Why did not Microsoft catch the error?”
“Microsoft states that it tests its monthly patches against fully patched systems only. The issue slipped by because Microsoft tested the patches only on systems with the updated servicing stack.Microsoft states that it tests its monthly patches against fully patched systems only. The issue slipped by because Microsoft tested the patches only on systems with the updated servicing stack.”
I did not have this problem on Windows 10 1808 when I installed KB4458469 on 2018-09-20 because Microsoft apparently knew of the potential servicing stack problem and included installation of KB4456655 for those who needed it, if WU was used.
It is a shame Microsoft apparently did not implement this information for older Windows versions in their 2018-09-20 update.
They will do everything in their power to shove Win 10 to all users . I remember how hard it was for them to overcome the Vista debacle and from its ruins emerged the best Windows OS since Win 2000( some would say DOS:/ ). I was so disappointed when i heard that “Hardware cabal” joined the effort denying Win 7 users newer and faster hardware. Shame on them!
The KB4457145 September 2018 Security Only patch installed fine without the KB3177467 Servicing Stack when I tested it.
Emoji designers run microsoft. Wait, emojis run microsoft.
Is it related to my issues here?
No it’s not, the issue you’ve got is the post reboot part of Windows update that’s meant to replace a file that was in use has been unable to replace said file, in this case “auditpol.exe.mui”.
Try running check disk to make sure there’s no problems with the file system and if that doesn’t find any problems then you’d need to look into why the “auditpol.exe.mui” file located in “C:\Windows\WinSxS\x86_microsoft-windows-m..ditevtlog.resources_31bf3856ad364e35_6.1.7601.24214_en-us_5c965eb9d13c77e9” isn’t being replaced.
It could be that your AV is blocking the replacement, it could be a permissions thing, or it could be that the hardlink is missing or broken.
The part of this story that jumps out at me is, now M$ will classify anything they want as a “security patch” :(
We have an old laptop still running windows 7 because it just can’t run windows 10. I keep it updated but there nearly 100 “optional” updates I’ve never installed because I don’t need them.
Now M$ will just reclassify them as Security patches :(
Thank you it fixed my issue.