Microsoft acknowledged on January 30 that its emergency patch for the Windows hibernation bug didn't actually fix the problem for all affected systems. Devices with Virtual Secure Mode (VSM) enabled are still rebooting when they should be hibernating or shutting down.
This is the second time this issue has appeared. The January 13 Patch Tuesday update broke hibernation on Windows 11 23H2 systems with System Guard Secure Launch enabled. Microsoft pushed an out-of-band fix on January 19. By January 23, reports emerged that the fix hadn't worked for all configurations.
The trade-off is awkward: skip the January security update and leave devices vulnerable, or install it and deal with systems that won't actually power down. For enterprise fleets running security-hardened configurations, this creates battery drain and unplanned reboots.
VSM is the hypervisor foundation for Device Guard, Credential Guard, and other Windows security features. Secure Launch protects boot processes from firmware attacks. These are precisely the features enterprise environments enable - which makes the recurring failure pattern worth noting.
Microsoft's solution this time: wait for a "future Windows update." No emergency patch, no timeline. Windows boss Pavan Davuluri told The Verge the day before this announcement that the company would focus on improving reliability.
The pattern is clear. This is the latest in a series of Patch Tuesday issues that required emergency fixes - which then required fixes themselves. For CIOs managing update policies, the question becomes whether Microsoft's quality control processes are keeping pace with their security update cadence.
Microsoft hasn't explained what change in the January update caused the issue, or why the emergency patch missed VSM-enabled configurations. What's documented: the problem affects Windows 11 23H2 Enterprise and IoT editions, plus Windows 10 22H2 systems in the Extended Security Updates program.
We'll see if the next Patch Tuesday actually resolves it.