You click Shut Down. The screen goes dark for a second, the fans spin down… and then, without warning, your PC boots right back up to the login screen. If this has happened to you recently, you’re not imagining things, and you’re not alone.
In January 2026, Microsoft’s monthly Patch Tuesday update introduced a frustrating regression: instead of powering off or going into hibernation, many Windows 11 machines restart themselves. The bug is tied to a security feature called System Guard Secure Launch, which is designed to verify firmware integrity before the operating system boots. Ironically, that same protection appears to misread a normal shutdown command as an unauthorized system state change, and forces a reboot instead of letting the PC power down cleanly.
The practical fallout has been real. Laptops left “shut down” overnight are found still running (or restarting) in the morning, draining their batteries. IT teams managing fleets of enterprise machines have had to fall back on manual workarounds. And plenty of everyday users have spent hours assuming their hardware was failing, when the actual culprit was a botched update.
The good news is that this is a known, well-documented issue with a real fix — not a hardware fault, and not something you caused. Below, we’ll walk through exactly why it happens, who’s affected, and every method available to resolve it, from a quick command-line workaround to the permanent patch.
Why This Is Happening
Before jumping into fixes, it helps to understand the root cause, because it affects which fix is right for you.
The problem traces back to the January 13, 2026 cumulative update, identified by Microsoft as KB5073455. This update altered how Windows 11 communicates with firmware-level security protections during power state transitions. On systems where Secure Launch is turned on, the update caused shutdown and hibernate commands to be misinterpreted, triggering a restart instead of a proper power-off.
Secure Launch isn’t enabled by default on most consumer PCs — it’s primarily a feature of Windows 11 Enterprise and IoT editions, where it’s used to harden firmware against rootkits and boot-level attacks. That’s why this bug has hit businesses, schools, and government fleets especially hard, while most Home and Pro users running default configurations have been largely unaffected. If your organization enabled Secure Launch manually for compliance reasons, or you’re running an Enterprise/IoT image, you’re in the affected group.
Microsoft acknowledged the issue shortly after reports started rolling in and pushed out an emergency out-of-band patch, KB5077797, on January 17, 2026, to correct the underlying kernel-level callback issue. If your system hasn’t picked up that patch yet, or if you need an immediate workaround before you can update, the methods below will get you back to normal.
Methods to Fix the Shutdown Bug
Method 1: Force a Shutdown from Command Prompt (Immediate Workaround)
If you need your PC to actually turn off right now, this is the fastest fix. It bypasses the graphical shutdown process entirely.
- Press Win + S, type
cmd, and select Run as administrator. - In the elevated Command Prompt window, type:
shutdown /s /f /t 0
- Press Enter. This forces an immediate shutdown, closing any open applications without the usual prompts.
The /f flag forces running applications to close, and /t 0 sets the shutdown timer to zero seconds, so the command executes instantly. This is the same workaround Microsoft itself recommended to affected users while a permanent fix was being finalized. It’s reliable, but it’s a stopgap — you’ll need to repeat it every time until the underlying issue is patched.
Method 2: Install the Official Fix (KB5077797)
This is the permanent solution and should be your priority.
- Go to Settings > Windows Update.
- Click Check for updates.
- If KB5077797 (or a later cumulative update that supersedes it) appears, install it and restart when prompted.
- If Windows Update hasn’t offered it to you yet, you can download it directly from the Microsoft Update Catalog — search for “KB5077797,” choose the correct package for your system architecture (x64 or Arm64), and install it manually.
Once this update is installed, the conflict between Secure Launch and the power-management stack is resolved, and shutdown/hibernate should behave normally again without any workaround needed.
Method 3: Temporarily Disable Secure Launch
If for some reason you can’t install the patch right away (for example, you’re waiting on IT approval in a managed environment), disabling Secure Launch will stop the bug from occurring, since it’s the specific feature triggering the conflict.
From Windows Security:
- Open Windows Security > Device security > Core isolation.
- Look for System Guard Secure Launch and toggle it off.
- Restart your PC for the change to take effect.
From BIOS/UEFI (if the option isn’t available in Windows):
- Restart your PC and enter BIOS/UEFI setup (usually by pressing F2, F10, Del, or Esc during boot — check your manufacturer’s key).
- Look for a setting labeled Secure Launch, DRTM, or similar under security or boot options.
- Disable it, save changes, and exit.
Keep in mind that Secure Launch exists for a legitimate security reason — it protects against firmware-level attacks. Disabling it isn’t dangerous for most everyday use, but organizations with strict compliance requirements should treat this as a temporary measure only, and re-enable it once the official patch is installed.
Method 4: Enterprise and IT Admin Deployment
If you’re managing multiple machines, individually running command-line workarounds isn’t practical. A few extra steps make this manageable at scale:
- Deploy KB5077797 fleet-wide through Windows Server Update Services (WSUS), Intune, or your patch management tool of choice as a priority out-of-band update.
- Use Known Issue Rollback (KIR) where available, rather than uninstalling the entire January update, since KIR lets you surgically reverse the specific regression without losing other security fixes.
- Distribute a temporary shutdown script to end users while the patch rolls out. A simple batch file can standardize the workaround:
@echo off
echo Initiating safe shutdown...
echo Please save any unsaved work before proceeding.
pause
shutdown /s /t 10
echo System will shut down in 10 seconds...
Save this as SafeShutdown.bat and distribute it to affected users as a stopgap desktop shortcut.
- Run targeted validation tests for shutdown and hibernate behavior as part of your standard patch-testing process going forward, since this class of regression (updates interfering with power states) has appeared more than once in past Windows update cycles.
- Communicate clearly with end users about what’s happening and when the fix is expected, so they don’t waste time troubleshooting hardware that isn’t actually broken.
Method 5: Run the Built-In Power Troubleshooter
For less severe cases, or if you’re not certain Secure Launch is the cause, it’s worth ruling out other possibilities first:
- Go to Settings > System > Troubleshoot > Other troubleshooters.
- Run the Power troubleshooter.
- Also check Event Viewer (search “Event Viewer” in the Start menu) under Windows Logs > System for entries around the time of a failed shutdown — a shutdown attempt immediately followed by a restart event is a strong indicator of this specific bug rather than a hardware or driver issue.
Conclusion
The Windows 11 shutdown bug is a good reminder that even routine security updates can introduce unexpected side effects, especially when they interact with lower-level firmware protections like Secure Launch. If your PC has started restarting instead of shutting down since mid-January 2026, the cause is very likely the KB5073455 update, not a failing battery, a bad driver, or hardware wearing out.
The fastest way to regain control right now is the command-line workaround (shutdown /s /f /t 0), but that’s only a band-aid. The real fix is installing KB5077797, which Microsoft released specifically to correct the kernel-level issue at the root of the problem. If you’re managing a fleet of machines rather than a single PC, prioritize rolling that patch out organization-wide, and keep the batch-script workaround on hand for anyone waiting on the update.
Once the patch is installed, there’s nothing else you need to do — shutdown and hibernate should return to working exactly as expected, and you won’t need to keep Secure Launch disabled or rely on manual commands going forward.
FAQ
1. Is this shutdown bug a sign that my hardware is failing? No. This is a software regression introduced by a Windows update, specifically KB5073455, not a hardware problem. If your PC restarts instead of shutting down and you have Secure Launch enabled, that’s the update bug, not a failing power supply or motherboard.
2. Does this affect all Windows 11 PCs? No. It primarily affects Windows 11 Enterprise and IoT edition systems with System Guard Secure Launch enabled. Most Home and Pro users don’t have this feature turned on by default, so they’ve seen far fewer reports of the issue.
3. Is it safe to just disable Secure Launch instead of installing the patch? It’s safe for most everyday users, since Secure Launch is a supplementary firmware-security feature rather than something your PC depends on to function. However, organizations with compliance or security policies requiring Secure Launch should treat disabling it as a temporary workaround only, and re-enable it once KB5077797 is installed.
4. How do I know for sure that KB5073455 is causing my shutdown problem? Check Event Viewer under Windows Logs > System for a shutdown attempt immediately followed by a restart event, with no other error explaining the reboot. If your system also has Secure Launch enabled (visible under Windows Security > Device security > Core isolation) and installed updates in mid-January 2026, that combination is a strong match for this specific bug.


