Microsoft has tied a Windows 11 recovery failure to two recent hotpatch updates for Windows 11 Enterprise LTSC 2024: KB5077212 from February and KB5079420 from March. On affected systems, "Reset this PC" can fail whether the user chooses "Keep my files" or "Remove everything."
That sounds like a broad Windows problem. It doesn't appear to be.
What the reporting points to instead is something more specific, and more enterprise-flavored: commercial devices managed through Windows Autopatch, with hotpatch enabled, on Windows 11 24H2 and 25H2. Those hotpatch releases are publicly listed by Microsoft for builds 26100.7781 / 26200.7781 and 26100.7979 / 26200.7979, as seen in Microsoft-linked update coverage and release tracking from Neowin and Windows Forum.
The immediate practical consequence is ugly but straightforward. A reset attempt can drop to a black screen, then throw an error, or simply reboot back into the existing desktop unchanged. One reported message is the familiar: "There was a problem resetting your PC."
What Microsoft is saying, and what is still less certain
The core claim here is that KB5077212 and KB5079420 break Push Button Reset on some Windows 11 systems. Multiple outlets report that Microsoft updated its support material to acknowledge that, as Neowin and The Win Central both covered.
But there is one caution flag attached to the story: a secondary research review says it could not fully reproduce from open sources the exact wording that Microsoft explicitly confirmed both KBs as the cause in the way some reports described it. That does not erase the issue, but it does matter for precision. The safest reading is this:
- Microsoft has acknowledged a Reset this PC / Push Button Reset problem on the affected hotpatch track.
- The issue is associated with the February and March hotpatch cadence on Enterprise LTSC 2024 systems using that model.
- Some of the more detailed attribution in circulation comes from support-document interpretation and downstream reporting, not a detailed Microsoft postmortem.
That distinction matters because Windows update failures often get flattened into a simple "this KB broke that feature" headline. In practice, the breakage can sit in adjacent components, especially around recovery.
Why this looks like a WinRE problem, not a normal desktop-update problem
The technical explanation attached to the issue points to Windows Recovery Environment (WinRE) being disrupted, specifically through interference involving provisioning packages and recovery image pathing.
If that sounds niche, it is. It also fits the symptom pattern.
"Reset this PC" is not just another shell-level Windows feature. It depends on recovery components, image paths, and a boot flow that's separate from ordinary desktop operation. That helps explain why these machines can keep running day to day, receive monthly hotpatches, and only reveal the problem when an admin or user tries to reset them.
That also lines up with the remedy Microsoft is recommending: install KB5079471, a March Safe OS Dynamic Update, which is specifically the kind of update tied to Windows setup and recovery plumbing rather than a typical user-facing patch. Both Neowin's coverage of the update and follow-up enterprise reporting from Windows News point in that direction.
That is the part worth paying attention to. When the workaround is a Safe OS Dynamic Update rather than a conventional cumulative update, it usually means the failure lives in the recovery or setup layer, not in the main runtime OS.
The bigger story is really about hotpatch complexity
Hotpatching is supposed to reduce disruption. Microsoft's pitch is familiar by now: keep monthly devices protected without forcing a restart every time. For a lot of enterprise fleets, that's a meaningful operational win.
But hotpatching also adds conditions and moving parts. Microsoft's own guidance for hotpatch eligibility includes requirements such as VBS being enabled, and for Arm64 devices, CHPE being disabled, as reflected in Microsoft's Intune hotpatch configuration documentation and mirrored update references at Releasebot.
None of that means hotpatch is inherently fragile. It does suggest that when something goes wrong, the blast radius may be concentrated in environments that are already more specialized than consumer Windows PCs.
That seems to be the case here. The reporting says consumer systems are not affected. So this is less "Windows 11 reset is broken" and more "a particular enterprise servicing path appears to have damaged recovery on a subset of managed devices."
That's still serious. In some organizations, Reset this PC is not a convenience feature; it's part of support workflow, re-provisioning, and failure recovery. A bug that leaves the desktop running but quietly breaks reset can sit unnoticed until the exact moment a machine needs to be recovered fast.
A narrow bug can still be an expensive one
There's another reason this story matters beyond the immediate fix: it lands after a messy patching stretch for Windows 11 24H2 and 25H2.
The same reporting trail says Microsoft paused or withdrew a rollback related to KB5079391 on April 1, then issued an out-of-band cumulative update KB5086672 to address installation error 0x80073712. That sequence was covered by Notebookcheck, ZDNet, and PCWorld, all following Microsoft's release pages.
Those incidents are not proof of one single underlying problem. But taken together, they do suggest that 24H2/25H2 servicing has been unusually busy around the edges: previews pulled back, emergency updates shipped, and now a recovery-path failure tied to hotpatch-managed systems.
For IT teams, that doesn't automatically argue against hotpatching. It does argue for treating recovery validation as separate from "the machine booted and apps still work."
The Secure Boot wrinkle is separate, but it shows how crowded the servicing calendar is
One detail in the March hotpatch is easy to miss: KB5079420 did not include Secure Boot certificate updates, which were deferred to the April 2026 baseline update.
That doesn't appear to be the cause of the reset bug. Still, it helps explain the broader environment administrators are dealing with. Secure Boot certificate replacement has become a live issue because older Microsoft certificates begin expiring in 2026, something Microsoft and OEM support channels have discussed in public guidance, including Microsoft's Windows IT Pro blog and Microsoft's support material on certificate update status.
Why mention it here? Because it shows that enterprise Windows servicing right now is not just about monthly security quality updates. It's also carrying recovery updates, hotpatch baselines, and certificate transitions. The more layers involved, the more important it becomes that one update stream doesn't quietly poison another.
What affected systems look like
Here's the profile Microsoft's documentation and related reporting point to:
What this probably means for admins
A few practical conclusions look fair, with the usual caution that Microsoft says a more permanent fix is still being worked on.
First, if your fleet is not on Enterprise LTSC 2024 with hotpatch via Autopatch, this story probably does not describe your environment. The available reporting keeps pointing to a specific servicing path, not a universal Windows 11 defect.
Second, if you are on that path, the important test isn't just whether devices take the latest update and stay online. It's whether WinRE-based recovery actions still function. That's a different validation step, and this bug is a reminder that it deserves its own checklist.
Third, Microsoft's recommendation to deploy KB5079471 only once suggests the company sees the current workaround as a recovery-stack correction, not something that needs to follow every monthly patch. If that guidance holds, this should be containable. If a Known Issue Rollback or emergency patch lands in the next few days, as the current reporting suggests, then this may turn into one of those enterprise Windows bugs that is sharp but short-lived.
The real lesson is narrower than the headline. Hotpatching still does what it promises for restart reduction. But this incident is a good example of the tradeoff: fewer reboots do not mean fewer dependencies. And when one of those dependencies is WinRE, the bug may stay invisible right up until the moment a machine needs rescue.
Comments