Microsoft issues out-of-band patches for Windows 11 startup failure

Windows administrators stung by a faulty Microsoft update in the May Patch Tuesday releases now have fixes for the problem.

Over the weekend, Microsoft released out-of-band updates to correct the failure of Windows 11 computers running versions 22H2/23H2 of the operating system, mainly in virtual environments, to start.

The problem: While installing the May Windows security update (KB5058405) on some of these computers, the OS thinks a crucial file – ACPI.sys – is missing. The Advanced Configuration and Power Interface is a critical Windows system driver that enables Windows to manage hardware resources and power states. Lacking the file, Windows won’t load, and an error message with the code 0xc0000098 pops up listing the missing file.

Microsoft notes there are also reports of this same error occurring with a different file name.

“This issue has been observed on a small number of physical devices,” Microsoft says, “but primarily on devices running in virtual environments, including Azure Virtual Machines, Azure Virtual Desktop and on-premises virtual machines hosted on Citrix or Hyper-V.”

The fixes  –  KB5027397 for PCs running version 23H2, and KB5062170 for PCs running version 22H2  – are only available through the Microsoft Update Catalog.

If for some reason you are among the few who haven’t yet installed the May 2025 Patch Tuesday security fixes and run a virtual desktop infrastructure, apply the out-of-band update instead.

The out-of-band update contains all of the improvements and fixes included in the May 2025 Windows non-security preview update, in addition to this issue’s resolution, says Microsoft. Since this is a cumulative update, admins don’t need to apply any previous update before installing KB5062170. That’s because it supersedes all previous updates for affected versions. Installation of this update will require a device restart.

Users of Windows Home or Pro editions are unlikely to face this issue, says Microsoft, because they aren’t likely to be running virtual machines.

Human error or edge case?

Microsoft, like other major software vendors, does a lot of testing of patches before they are released. Still, says Tyler Reguly, associate director of security R&D at Fortra, they can’t catch everything. “It’s impossible to test every edge case and scenario,” he said in an email. “On top of that, at some point testing at a large scale requires humans – and humans make mistakes.

“The question I always want to have answered [when a vendor has to fix a fix] is whether it was human error or an edge case that was deemed unlikely. Unfortunately, very few vendors are willing to publish the results of their Root Cause Analysis (RCA). Instead, the best we can hope for is a quick fix and a mutual understanding that it won’t happen again.

In the case of human error, ensuring it won’t happen again may mean process or policy changes, he wrote, while edge cases could be the result of any number of variables. “When we talk about hardware and virtualization on top of hardware, we’re talking about a lot of things that can go wrong,” he pointed out. “In that case, while we hope vendors catch everything, we need to recognize that as an unrealistic expectation.”

Someone will tout AI as the solution to ensure this doesn’t happen, he added, but as long as our technology exists outside a walled garden, and as long as users have choice in their technologies, problems like this will continue to arise. IT leaders just need to figure out how to respond quickly and calmly.

“If I were a CSO, this is where I would look at my organization and, if we were impacted, I would look at how we responded and how quickly we recovered,” Reguly said. “This is why business continuity planning exists and, if errors like this are hugely impactful, you need to wonder if your BCP is as robust as it needs to be.”

A complexity problem

Even extensively tested code can fail on first contact with production systems, observed Gene Moody, field CTO at patch management provider Action1.

“This isn’t a QA failure, it’s a complexity problem. Test environments, no matter how thorough, can’t replicate the quirks of real-world systems, undocumented changes, legacy software, obscure drivers, or corrupted system states. A patch may behave differently depending on what’s running, what’s been previously installed, or how the system was maintained and managed. Timing issues, environmental drift, and configuration edge cases are almost impossible to predict in labs. And in production, security tools, compliance agents, or even partially failed updates from the past can all sabotage patch behavior,” he said.

“This is why progressive ringed rollout, strong telemetry, and fast rollback are more critical than any lab test. Real-world variability is the wildcard no simulation can fully cover; admins need to be familiar with their own environments to be able to test and recover from unforeseen circumstances caused by unstable patches.”