Windows Shutdown Glitch: VSM and Memory Integrity Clash (Jan 2026)

A widely distributed January 2026 security update left a slice of Windows PCs unable to power off cleanly: hitting the shutdown button causes some machines to restart, and in other cases the system refuses to hibernate. Microsoft acknowledged the problem, released emergency out‑of‑band patches, and has been updating the release notes — but for many users the issue persists until the company ships a final fix. This feature‑level failure is unusual, because it’s not a typical driver or hardware incompatibility — it’s a clash between Windows power transitions and the operating system’s virtualization‑based security stack. If your PC is rebooting when you tell it to shut down, here’s exactly why that’s happening, how to check whether your device is affected, and which fixes and mitigations you can apply now — plus the security tradeoffs you must understand before changing system protections.

Background / Overview​

The problem began after Microsoft’s January 13, 2026 cumulative security update for certain Windows builds. Administrators and home users reported a symptom that’s simple to describe but disruptive in practice: when users select Shut down or attempt to enter Hibernation, the system instead restarts. Microsoft documented the issue on its Windows release health pages and followed with out‑of‑band updates that fix the problem for many Secure Launch configurations — but not for all scenarios. The variant that remains unresolved involves systems that use Virtual Secure Mode (VSM) or Memory Integrity (Core isolation), where turning off those protections is the only reliable workaround for some users at the moment.
This is not a universal bug: it primarily affects devices that meet a specific set of security conditions — notably systems configured with System Guard Secure Launch and VBS‑centric protections. That typically includes Enterprise, IoT, and Secured‑core PC configurations, but the bug has been observed across client platforms where those protections are enabled. Microsoft’s staged responses (an emergency January 17 out‑of‑band update and a follow‑up on January 24) addressed many cases, yet the VSM‑enabled edge cases still require a future update.

---

What happened (the short technical summary)​

• On January 13, 2026 Microsoft shipped a security cumulative update that, for some Secure Launch‑capable devices, caused shutdown and hibernation actions to produce an unexpected restart.
• Microsoft issued an out‑of‑band (OOB) update on January 17 to address many affected devices; a further OOB on January 24 extended fixes and rolling changes to delivery.
• The remaining failing scenario involves Virtual Secure Mode (VSM) — a Hypervisor/Virtualization‑Based Security (VBS) configuration often surfaced as Memory integrity (Core isolation) in the Windows Security app. Machines with VSM enabled can still experience restart‑in‑stead‑of‑shutdown behavior; Microsoft says a future update will address that variant.
• Workarounds include installing the OOB patches (if available for your build), temporarily disabling Memory integrity/VSM, using an alternative shutdown command, or uninstalling the problematic update(s) — each with tradeoffs and operational risks.

---

Why Secure Launch and VSM matter — and why they can break shutdown​

What is Secure Launch?​

System Guard Secure Launch is a security feature that leverages hardware capabilities (TPM, DRTM, and platform firmware support) to strengthen the chain of trust at boot. It’s designed to reduce the risk of firmware‑level compromises by ensuring the system transitions into a known good state before the OS kernel is trusted.

What is VSM / Memory integrity?​

Virtual Secure Mode (VSM) and Memory integrity are part of Windows’ Virtualization‑Based Security (VBS) family. VSM uses virtualization to isolate security services from the main OS, and Memory integrity (sometimes shown as Core isolation > Memory integrity) protects kernel code execution integrity by enforcing checks inside a hypervisor‑backed environment.

Why these interact with shutdown​

Power state transitions (shutdown, restart, hibernate) require coordinated logic between firmware, hypervisor, kernel, and ACPI power management. The January update changed or patched code paths that interact with Secure Launch and VSM — and in certain configurations the new code path doesn’t reach the expected “power off” branch. Instead, the system executes a restart flow. Because Secure Launch and VSM alter the initialization and runtime assumptions of the platform, the resulting symptom appears only when those protections are active. That’s why a plain‑vanilla consumer install without VSM generally doesn’t see the problem.

---

Who is affected (practical checklist)​

Check the following on your machine to estimate whether you’re in the impacted set:

• Is your device running Windows 11 version 23H2 (or one of the enterprise builds to which Microsoft applied the January security update)?
• Do you have Secure Launch configured or running? (Visible via System Information → Virtualization‑based Security Services Running / Configured.)
• Is Memory integrity enabled in Windows Security → Device security → Core isolation details?
• Did you install the January 2026 security update (released January 13) and subsequent emergency OOB updates on or after that date?

If you answered “yes” to the last two, there is a realistic chance the shutdown or hibernation commands will behave incorrectly on your PC.

---

How to check your machine’s status (quick steps)​

• Open System Information (type msinfo32 and press Enter). Look for the fields “Virtualization‑based Security Services Running” and “Virtualization‑based Security Services Configured.”
• Open Settings → Windows Security → Device security → Core isolation details. Check the Memory integrity toggle. If it’s On, VSM is in play.
• Open Settings → Windows Update → Update history → Installed updates (or Uninstall updates) and confirm whether KB5073455 (the Jan 13 security update), KB5077797 (Jan 17 OOB), or KB5078132 (Jan 24 OOB) are present.

---

Immediate fixes and mitigations you can try now​

Below are the practical ways people have used to regain a normal shutdown flow. Each option includes an explanation, step‑by‑step actions, and a clear note on risks.

1) Install Microsoft’s OOB patches (first, always try this)​

Microsoft’s emergency patches were intended to resolve the issue for Secure Launch configurations. If your device appears eligible for KB5077797 or KB5078132, install them and reboot. After that, test normal Shutdown and Hibernation.
Why try this first: this is the vendor fix and preserves your security posture when it works.
How to get it:

• Open Settings → Windows Update → Check for updates.
• If the patch appears, install and restart.
• Test shutdown/hibernate.

Important: Microsoft’s notes say some devices and the VSM variant remain unresolved; if the OOB patches don’t help, continue to the other mitigations.

---

2) Temporary alternative shutdown method (no security changes)​

If you just need a reliable way to power off while keeping security settings intact, use the Windows shutdown command.

• Open Command Prompt or PowerShell and run:
  shutdown /s /t 0

This instructs Windows to shut down immediately and bypasses the UI path that may trigger a restart. For convenience you can create a desktop batch file:

• Open Notepad and type: shutdown /s /t 0
• Save as All Files → name it shutdown.bat.
• Create a shortcut or pin it to Start for quick access.

Why use this: low risk, no security features disabled. It’s a reliable stopgap for daily use until Microsoft ships a definitive fix.
Drawback: it’s a manual workaround and offers no solution to hibernation failures.

---

3) Disable Memory integrity (VSM) — the “fix that works” for many​

If you confirm Memory integrity (Core isolation) is On and the OOB patches did not fix the restart behavior, turning Memory integrity Off will often restore normal shutdown and hibernation behavior.
How to disable Memory integrity:

• Press Win + I → Privacy & security → Windows Security → Device security.
• Click Core isolation details.
• Toggle Memory integrity to Off.
• Restart to apply changes.
• Test a normal Shut down.

Why this works: the remaining failing path is associated with the VSM/Memory integrity case; disabling it removes the hypervisor‑backed protection that interacts poorly with the current update.
Security tradeoff and risks:

• Disabling Memory integrity reduces kernel protection and increases exposure to certain classes of advanced attacks (kernel‑level exploits).
• Some systems will experience driver incompatibilities or performance differences when VSM is toggled off or back on.
• Memory integrity can re‑enable itself in some environments after policy pushes or subsequent updates; check the setting if the symptom recurs.

Recommendation: if you disable Memory integrity, treat it as a temporary measure. Re‑enable VSM as soon as Microsoft releases an update that explicitly states the VSM case is resolved.

---

4) Uninstall the problematic updates (when the OOB patches and Memory integrity changes aren’t right)​

If you cannot tolerate the issue and need a more permanent roll‑back until a tested patch appears, uninstall the specific KBs that introduced the problem.
How to uninstall:

• Open Settings → Windows Update → Update history → Uninstall updates.
• Find KB5073455, KB5077797, or KB5078132 in the list. Select and click Uninstall.
• After uninstalling, go back to Settings → Windows Update and toggle off Get the latest updates as soon as they’re available and temporarily use Pause updates to stop immediate reinsertion.
• Reboot and verify shutdown behavior.

Important caveats:

• Uninstalling security updates increases exposure to the vulnerabilities the update addressed. If you remove a security update, you should understand the tradeoff and make sure the machine has other compensating controls (network segmentation, firewall, reduced exposure).
• Microsoft’s “go back” 10‑day window applies to feature upgrades; quality updates and individual KBs can often be removed via Update history, but not all KBs are uninstallable. If an update is combined with a servicing stack update, it may be harder to remove.
• If your device is managed by IT (Group Policy, MDM), uninstalling updates or disabling the “get updates early” toggle may be constrained or overwritten by policy.

---

5) Disable hibernation (if hibernate specifically fails)​

If your system cannot reliably hibernate and you don’t use hibernation, turn it off to prevent lost work and battery drain.
From an elevated Command Prompt or PowerShell:

• Disable: powercfg.exe /hibernate off
• Re‑enable later with: powercfg.exe /hibernate on

Benefit: removes one problematic power state. It also frees the disk space used by hiberfil.sys.
Drawback: you lose the fast boot/hibernate capability and any dependent workflows.

---

Step‑by‑step troubleshooting checklist (recommended order)​

• Check Windows Update settings and install any pending OOB patches (KB5077797, KB5078132) and reboot.
• If problem persists and Memory integrity is On, try the alternative shutdown command first: shutdown /s /t 0.
• If the Shutdown command works but the normal UI does not, consider disabling Memory integrity temporarily (Core isolation) and reboot to confirm.
• If that resolves the issue but you need the security feature, re‑enable Memory integrity only after Microsoft confirms a VSM fix.
• If you cannot disable Memory integrity (policy locked) or need an immediate machine that cannot be rebooted into a safe state, uninstall the specific KBs and pause updates — only if you understand the security consequences.
• If hibernation is unreliable and you depend on uptime, disable hibernation until the VSM fix is delivered.

---

Critical analysis — strengths, risks, and longer‑term implications​

• Strengths of Microsoft’s response: Microsoft acknowledged the regression and released out‑of‑band updates within days, which is the right approach for critical power‑state regressions in enterprise environments. The company also updated release notes and the Windows release health dashboard to inform administrators about the different affected scenarios and the state of mitigation. Emergency OOB updates fixed many Secure Launch cases without requiring users to change system security settings.
• Weaknesses and operational risks: the remaining VSM variant demonstrates the fragility of complex interactions between security features and low‑level power management. VBS and Secure Launch are intentionally invasive to achieve stronger protections; that same invasiveness raises the bar for testing across the diversity of OEM firmware, drivers, and enterprise configurations. The fact that Memory integrity and VSM still produce failures after the initial OOB patches suggests either an incomplete test matrix across OEM firmware variants or a late regression introduced by interaction with certain drivers or platform firmware.
• Security tradeoffs for users: disabling Memory integrity removes a significant layer of kernel protection. For many home users, the short‑term risk may be acceptable if they prioritize predictable shutdown behavior. For enterprises and Secured‑core deployments, removing VSM can materially reduce protection against firmware‑level threats. IT teams must weigh operational continuity (a functioning shutdown and hibernate) against the higher security posture that VSM offers.
• Long‑term implications: the patching cadence and the rise of hotfixes/out‑of‑band releases highlight the increasing surface area Microsoft must test as Windows integrates more hardware‑backed protections. Vendors, OEMs, and enterprise admin teams should expect more rapid remediation cycles and should tighten rollback and update staging policies to reduce production exposure. For users, this incident strengthens the argument for disciplined update testing on representative devices before wide deployment.

---

Recommendations for home users and IT teams​

• Home users: install Microsoft’s OOB updates and test. If the issue remains and you occasionally rely on hibernation, consider the simple workaround of shutdown /s /t 0 or temporarily disabling Memory integrity — but only if you understand the security tradeoffs. Re‑enable protections after Microsoft announces a fix for VSM.
• IT administrators: treat any rollout as potentially disruptive if VBS, Secure Launch, or Memory integrity are in use. Delay wide deployment of the January updates until you’ve validated them in your environment. Use controlled deployment rings and test machines that mirror Secured‑core and Secured‑launch configurations. If the organization cannot disable VSM for business reasons, follow Microsoft’s recommendations and coordinate with OEM firmware vendors for compatibility testing.
• Backup and incident readiness: regardless of the chosen mitigation, ensure you have current backups and a recovery plan. Uninstalling security updates or disabling kernel protections increases the chance of exploitation, so balance the decision against the presence of other controls (network isolation, EDR, up‑to‑date antivirus).

---

What to expect next from Microsoft​

Microsoft’s release notes and update cadence indicate a layered mitigation plan: OOB updates fixed many Secure Launch cases, and a future cumulative update will address the VSM variant. Expect the next rolling quality update to explicitly state that the VSM/Memory integrity scenario is resolved for specific builds. Enterprises should track the Windows release health dashboard and test the update in a pre‑production ring before broad deployment.

---

Final practical checklist (copyable)​

• Check: msinfo32 → Virtualization‑based Security Services Running/Configured.
• Check: Windows Security → Device security → Core isolation details → Memory integrity.
• Update: Settings → Windows Update → Install KB5077797 / KB5078132 if offered.
• Quick workaround: shutdown /s /t 0 (create shutdown.bat for convenience).
• Temporary fix for stubborn cases: Core isolation → Toggle Memory integrity Off → Restart.
• If necessary, uninstall KB5073455 / KB5077797 / KB5078132 from Update history → Uninstall updates, and Pause updates temporarily.
• If hibernation is failing, consider: powercfg.exe /hibernate off.
• Re-enable Memory integrity as soon as Microsoft confirms a VSM fix.

---

This shutdown regression is a reminder that advanced security features — those that use the hypervisor and firmware attestation — change basic assumptions about how the operating system interacts with platform hardware. The right long‑term outcome is simple: let vendors ship strong protections that are also robust across firmware and driver variants. In the short term, use the vendor fixes first, use command‑line shutdown if you want to avoid changing security posture, and only disable Memory integrity as a last‑resort temporary measure. Keep machines that must remain secured in a controlled test ring and press vendors (Microsoft and OEMs) for explicit, tested updates that resolve the VSM edge cases without forcing administrators to choose between security and usability.

---

Source: Make Tech Easier Windows Won't Shut Down After Update? Here's How to Fix It - Make Tech Easier