Windows 11 Shutdown Bug With Secure Launch: KB5077797 Fix

Background​

What Microsoft confirmed — the facts​

• After installing security update KB5073455 (January 13, 2026) for Windows 11, version 23H2, some PCs with Secure Launch enabled cannot shut down or enter hibernation; instead the device restarts. Microsoft added that the condition was configuration‑dependent and primarily observed on enterprise and IoT images where Secure Launch is more commonly enforced.
• Microsoft released an out‑of‑band cumulative update KB5077797 on January 17, 2026, which includes fixes for the Secure Launch shutdown regression as well as an authentication/sign‑in regression affecting Remote Desktop flows. The KB notes list both fixes explicitly.
• The company also followed up with additional emergency packages to address collateral regressions (for example issues with cloud storage and Outlook in certain configurations), indicating that the January cycle required more than one emergency intervention. Major outlets and the Windows Release Health notes documented that sequence.

Why this happened: a short technical primer​

• Stage and validate update payloads while the OS is running.
• Perform one or more offline servicing passes during shutdown or a restart to replace files that cannot be updated while the OS is live.
• Preserve the user’s final power intent (restart vs shut down vs hibernate) across transition points and complete the requested action after offline servicing finishes.

Why Secure Launch matters​

Who’s affected — scope and scale​

• Primary scope: Windows 11, version 23H2 systems that have Secure Launch enabled — commonly enterprise and IoT SKUs and images. Microsoft’s advisory explicitly calls out the correlation with Secure Launch and that not all Windows 11 devices are impacted.
• Secondary concerns: other January KBs caused separate regressions (Remote Desktop credential prompts, cloud‑storage app hangs) that affected broader builds and required OOB fixes for other servicing streams (24H2/25H2). Those issues were corrected by subsequent OOB KBs targeted at those branches.
• Real‑world footprint: Microsoft characterized the problem as configuration‑dependent and not universal. Community reporting shows that affected devices are a small but operationally important subset — particularly for managed fleets where Secure Launch is deployed for compliance or hardened footprints. Even so, a small percentage of a large fleet can translate into many impacted endpoints for large organizations.

Timeline — what happened and when​

• January 13, 2026 — Microsoft publishes Patch Tuesday cumulative updates including KB5073455 (Windows 11 23H2) and companion updates for other Windows branches.
• January 13–16, 2026 — Telemetry and user reports surface two primary regressions: a restart‑instead‑of‑shutdown symptom on Secure Launch‑enabled 23H2 devices, and Remote Desktop/Cloud PC authentication failures across other builds. Community threads and tech outlets pick the issues up rapidly.
• January 17, 2026 — Microsoft issues out‑of‑band cumulative updates, notably KB5077797 for 23H2, which includes fixes for the Secure Launch shutdown regression and Remote Desktop sign‑in failures. Administrators are advised to pilot and then deploy the OOB packages as needed.
• January 21–24, 2026 — Microsoft updates the KB entries and release‑health notes to reflect additional known issues and follow‑on fixes (for example cloud‑storage app unresponsiveness) and publishes further OOB packages where required. Tech press and forums document the staggered nature of fixes and the need for careful testing.

Practical guidance — what end users should do now​

• First, check whether your device is running Windows 11, version 23H2 and whether Secure Launch is enabled (many consumer systems do not have Secure Launch enabled by default).
• If you experienced unexpected restarts when attempting to shut down or hibernate after January updates, install the matching OOB update for your build (for 23H2, Microsoft published KB5077797). Windows Update or the Microsoft Update Catalog will surface the packages.
• As a temporary workaround until the OOB update is installed, Microsoft documented an explicit command‑line shutdown that often forces a proper power‑off: open an elevated Command Prompt and run:
• shutdown /s /t 0
  This is a one‑time manual fix that must be repeated when you need to ensure the device powers off. Microsoft notes there was no general workaround for hibernation until the fix ships.
• Maintain backups and save work regularly. If a restart occurs unexpectedly it can lead to unsaved data being lost.

Practical guidance — what IT administrators and enterprises should do​

• Inventory and prioritize: identify devices with System Guard Secure Launch or Virtual Secure Mode (VSM) enabled. Those devices are the highest priority for verification. Use your tooling (Intune, SCCM, or third‑party endpoint management) to query relevant configuration flags.
• Pilot before wide deployment: apply the OOB packages to a representative pilot ring that includes the range of firmware versions and OEM driver sets in your fleet. Watch for side effects — the initial OOB fixes addressed shutdown and RDP issues but subsequent emergency packages were required to fix other regressions.
• Preserve rollback and emergency access: because some OOB packages combine servicing stack updates (SSU) and LCUs, removal can be nontrivial. Document and test rollback procedures (DISM package removal where possible, known‑issue rollback guidance) and ensure you maintain out‑of‑band management channels for devices that may fail to boot into a usable state.
• Collect diagnostics: if you encounter the symptom after installing the OOB update, collect Event Viewer logs (System and Setup channels), Windows Update logs, and any pre/post OS boot failure artifacts. These details help Microsoft support and OEM partners diagnose lingering issues.
• Communicate with users: unexpected restarts can erode user trust. Communicate clearly about the issue, the workaround (shutdown command), and the planned remediation path. For devices used in mission‑critical or scheduled power‑state workflows (kiosks, imaging rigs, conference room devices), adjust maintenance windows until remediation is validated.

Risk analysis — strengths, weaknesses, and what this episode exposes​

Strengths: Microsoft’s rapid OOB response​

• Microsoft moved quickly to publish OOB packages within four days of the Patch Tuesday rollout, reflecting mature telemetry, release health monitoring, and prioritization processes. Emergency updates are costly and disruptive, and the rapid remediation limited exposure.
• The vendor provided a documented interim workaround (shutdown /s /t 0), explicit KB notes, and targeted fixes rather than sweeping rollbacks, enabling administrators to address the problem more surgically.

Weaknesses and risks revealed​

• Complexity of platform hardening: virtualization‑based protections such as Secure Launch and VBS increase the test matrix dramatically. Deep security features interact with servicing in ways that are hard to reproduce at scale in lab environments, especially across diverse OEM firmware and driver sets. The incident underlines how hardening increases validation surface.
• Collateral regressions: emergency fixes themselves introduced additional problems (for example cloud storage/Outlook hangs) that required further OOB patches. This cascade effect shows how narrow fixes can surface unforeseen side effects in other subsystems. Administrators should expect some degree of churn during emergency sequences.
• Communication and transparency: while Microsoft published KB notes and Release Health updates, the technical explanation remained deliberately high level. Vendors historically avoid deep post‑mortems for internal orchestration fixes, leaving admins and engineers to diagnose interactions across firmware and drivers. That can slow diagnosis of edge cases in heterogeneous fleets.

How to test and validate fixes in your environment​

• Create a representative pilot ring that includes the primary OEMs, chipsets, and firmware versions found in your fleet. Include a sample of endpoints with Secure Launch enabled.
• Apply the OOB packages to the pilot devices (for 23H2, install KB5077797), reboot, and verify:
• Normal Shut down from Start → Power → Shut down results in a powered‑off state.
• Hibernate is functional where expected and not producing an unexpected restart.
• Remote Desktop and cloud‑storage app authentication/behavior are validated if those devices use AVD or OneDrive‑backed stores.
• Run regression checks on common business apps (Outlook, Teams, cloud file clients) and capture telemetry (Event Viewer, Windows Update logs).
• If issues appear, preserve logs, escalate to Microsoft support with detailed diagnostics, and consider reverting the device to the pre‑patch state only after documenting the rollback method.

Broader implications for Windows servicing strategy​

• Hardening features (Secure Launch, VBS, TPM‑anchored flows) are essential for defending firmware and early‑boot attacks but they increase the number of state permutations that update orchestration must correctly handle.
• Rapid OOB engineering is an important capability, but it can produce a short period of instability as fixes are iterated. Organizations must invest in pilot rings and telemetry to catch subtle regressions before mass deployment.
• For users and administrators, the practical lesson is perennial: maintain robust backup practices, pilot updates on representative hardware, and keep emergency access channels intact. These measures mitigate fallout when a security‑first update interacts poorly with a particular hardware configuration.

Recommended checklist (quick reference)​

• For home users:
• Install Windows updates promptly but check Release Health notes for any OOB advisories.
• If you see restarts instead of shutdowns after January updates, install the correct OOB package or run shutdown /s /t 0 as a temporary measure.
• For admins:
• Inventory endpoints for Secure Launch and VSM.
• Pilot OOB fixes on representative hardware families, validate shutdown/hibernate and critical apps.
• Keep rollback/diagnostic procedures documented for combined SSU+LCU packages.
• Communicate to end users: provide the temporary workaround and expected timeline for patched rollouts.

Conclusion​

Background: what happened and why it matters​

Timeline — patch, problem, response​

• January 13, 2026 — Microsoft publishes the January security rollup KB5073455 (Windows 11 23yment, reports surface of devices with Secure Launch enabled restarting instead of shutting down or hibernating. Microsoft documents the behavior as a known issue.
• January 13–16, 2026 — Community and enterprise reports proliferate: helpdesks log battery drain incidents, imaging pipelines fail to complete, and end users notice systems returning to the sign‑in screen after an attempted shutdown.
• January 16, 2026 — Microsoft posts interim, manual guidance: run shutdown /s /t 0 from an elevated Command Prompt to force an immediate, orderly shutdown. Microsoft notes there was no general workaround for hibernation at that time.
• January 17, 2026 — Microsoft releases out‑of‑band cumulative update KB5077797 for Windows 11 23H2, which Microsoft documents as fixing the Secure Launch restart‑on‑shutdown regression (and Remote Desktop sign‑in failures) for many devices. Administrators are advised to validate the OOB update in test rings and deploy as appropriate.
• Late January 2026 — Microsoft updates the KB and Release Health pages to add that some devices with VSM enabled might still fail to shut down or hibernate and that further remediation is pending. This leaves a narrower subset of systems unresolved and highlights the complexity of virtualization‑based protections interacting with servicing orchestration.

Technical anatomy: why Secure Launch and VSM complicate shutdown​

What Secure Launch and VSM actually do​

• System Guard Secure Launch inserts a virtualization boundary early in the boot chain to establish a measured, trusted envi firmware and boot components from tampering (DRTM techniques). It depends on TPM 2.0, UEFI Secure Boot, and CPU virtualization features.
• Virtual Secure Mode (VSM) extends virtualization‑based security by isolating critical OS components (like Credential Guard or memory protections) inside a separate, secure execution environment.

Servicing orchestration: multi‑phase updates and power intent​

Who's at risk — the affected populate: Windows 11, version 23H2 devices (Enterprise and IoT editions) that have System Guard Secure Launch enabled. These SKUs and images are often used in managed fleets, kiosks, and specialized hardware.​

• Lower risk: typical consumer Home and Pro devices that do not enable Secure Launch by default. However, consumers who explicitly configured Secure Launch or VSM (for example, on Secured‑core or enterprise provisioning images) could be affected.

Real‑world impact: operations, battery life, and trust​

• Laptops intended to hibernate overnight may remain powered and drain batteries, causing unexpected device unavailability in the morning.
• Automated imaging, provisioning, or maintenance windows that depend on deterministic shutdown or hibernate states can fail, breaking workflows and increasing helpdesk load.
• Users who assume a device is powered off or safely hibernated risk unsaved work loss if a restart is triggered unexpectedly.
• For organizations that mandate Secure Launch for compliance, disabling it as a quick fix is often non‑viable due to policy, making timely and controlled remediation paramount.

Mitigation and troubleshooting: practical steps for users and admins​

Immediate actions for end users (consumer and small business)​

• If you experience the restart‑on‑shutdown symptom, run an elevated Command Prompt and execute: shutdown /s /t 0. This is Microsoft’s documented manual workaround and forces an immediate, orderly shutdown. Note: it does not guarantee hibernation behavior.
• Check installed updates: confirm whether KB5073455 is present and whether KB5077797 (the OOB fix) has been applied. Validate yd (22631.x).
• Save work often and avoid relying on hibernation until your device has the OOB update and you have vali Recommended steps for IT administrators and fleets
• Inventory and prioritize:
• Query devices to identify which have Secure Launch or VSM enabled. Tools: msinfo32 (System Information), Intune/Endpoint Management queries, SCCM/ConfigMgr reporting.
• Pilot before wide deployment:
• Apply KB5077797 (OOB) to a representative pilot ring including the most complex OEM and firmware combinations in your estate. Look for regressions or remaining symptoms.
• Preserve rollback and emergency access:
• Because combined SSU+LCU packages can complicate removal, document DISM removal steps and maintain out‑of‑band management channels (iLO, iDRAC, Intel AMT). Don’t rely solely on Windows Update rollback for mission‑critical endpoints.
• Collect diagnostics:
• If a device still misbehaves after the OOB update, gather Event Viewer logs (System, Setup), Windows Update logs, and pre/post‑boot traces to open a support case with Microsoft and track OEM‑specific anomalies.
• Communicate with users:
• Proactively notify affected users about the issue, the workaround (shutdown command), and expected remediation timelines to reduce helpdesk pressure and restore confidence.

When the OOB update doesn’t fully fix a device​

Risk assessment: strengths, weaknesses, and broader implications​

Notable strengths​

• Microsoft’s response was rapid: the company acknowledged the regression, published an interim workaround, and issued an OOB package (KB5077797) within four days of the January 13 rollup. That speed reduced the window of operational exposure for many fleets.
• The incident demonstrates that the combination of Release Health tracking and targeted out‑of‑band fixes can be effective when configuration‑dependent regressions emerge at scale. Administrators had clear vendor guidance and a concrete remediation path.

Potential risks and weaknesses​

• The underlying problem underscores a systemic risk: security hardening and update orchestration are increasingly entwined, and cirtualization boundaries can produce non‑obvious interactions with servicing flows. This makes update validation more complicated and expensive for organizations that enforce strong platform protections.
• Patching complexity: combined SSU+LCU packages reduce the ability to surgically uninstall problematic changes. That complexity makes emergency reversions or rollbacks riskier and places a premium on pre‑deployment validation.
• Residual impact: Microsoft’s later note that some VSM‑enabled devices still experience shutdown/hibernate failures indicates that edge cases persist. Organizations with heterogeneous OEMs and older firmware may face longer remediation windows and greater operational friction.

Broader lessons for patch management​

• You cannot rely solely on functional testing in a homogeneous lab; validation must exercise the full stack (firmware, drivers, VBS features) and reflect production‑grade device diversity.
• Segmented rollout policies and pilot rings remain essential. Fast global deployment of a security Lut it can increase blast radius when low‑level interactions are brittle.
• Known Issue Rollback (KIR) mechanisms and the ability to quickly issue targeted mitigations are valuable tools for balancing security and reliability in enterprise environments.

Verification and cross‑checks​

Checklist: what to do now (concise)​

• Verify whether your estate runs Windows 11 23H2 and whether Secure Launch or VSM is enabled on affected devices. Use msinfo32 and your management tooling.
• Ensure KB5077797 (OOB) is installed on impacted 23H2 systems; validate shutdown and hibernation behavior in a controlled pilot group before broad deployment.
• If immediate shutdown is required and the device shows the symptom, use the documented manual workaround: run an elevated Command Prompt and execute shutdown /s /t 0. Save your work first.
• For persistent failures after the OOB update, collect logs and open a coordinated support case with Microsoft and the OEM; consider temporary mitigations aligned with your security posture.
• Revisit patch validation playbooks to include VBS/Secure Launch/VSM permutations and representative OEM firmware sets. Consider expanding pilot rings for early vetting of future LCUs.

Conclusion​

Background​

What exactly happened​

Symptom and immediate impact​

• Symptom: selecting Shut down (Start → Power → Shut down) or attempting Hibernate on affected devices can result in an immediate restart rather than a power‑off or successful hibernation.
• Scope: primarily observed on devices running Windows 11, verstem Guard Secure Launch (a virtualization‑based early‑boot protection) or Virtual Secure Mode (VSM) is enabled — settings more common in Enterprise and IoT images than on consumer Home/Pro PCs.

Why the command-line workaround works​

• Open Command Prompt (administrator).
• Run:
  shutdown /s /t 0

Technical anatomy — why Secure Launch interacts with shutdown semantics​

Verification — what Microsoft and independent sources confirm​

• Microsoft’s KB article for KB5073455 (January 13, 2026) lists a known issue: "Devices with Secure Launch might fail to shut down or hibernate — instead, the device restarts." Microsoft’s guidance recorded that the issue was addressed (in part) by a subsequent OOB update. (support.microsoft.com)
• Microsoft’s OOB KB5077797 (January 17, 2026) explicitly lists a Power & Battery fix: "Some devices with Secure Launch enabled restart instead of shutting down or entering hibernation." The OOB also addresses Remote Desktop sign‑in failures that appeared with the January cumulative update.
• Independent outlets and community trackers (technical press, forums, and Windows community wikis) reproduced the symptom, confirmed the Microsoft advisory, and advised the same manual shutdown workaround while KB5077797 was prepared and distributed. These independent corroborations provide strong cross‑validation for the vendor’s advisory.

How to check whether your PC is exposed​

• Confirm Windows build:
• Press Win+R → type winver → Enter. Look for Windows 11, version 23H2 and the OS build noted in the KB articles.
• Confirm KB presence:
• Open an elevated PowerShell or Command Prompt and run:
  DISM /online /Get-Packages | findstr 5073455
• Or check Settings → Windows Update → Update history for KB5073455 or KB5077797.
• Confirm Secure Launch / VSM status:
• Open Windows Security → Device security → Core isolation details and check whether Secure Launch or Virtual Secure Mode is enabled.
• Or run msinfo32 and inspect the "Virtualization‑based security services running / configured" entries.
• Reproduce carefully:
• Close unsaved work. Attempt Shut down / Hibernate. If the PC immediately restarts, the symptom is present. Check logs for correlated shutdown/reboot events.

Practical mitigation steps​

For home users​

• If you are unaffected or unsure, do nothing immediately — rely on Microsoft Update to deliver KB5077797 automatically.
• If you see restart‑on‑shutdown behavior and need a fast workaround:
• Save work and run (in an elevated prompt if preferred): shutdown /s /t 0.
• This forces a clean shutdown without uninstalling security updates.
• If you prefer not to run KB5073455 yet (not recommended for most users because it contains important security fixes), consider:
• Deferring the January Rollup until your next maintenance window, or
• Testing KB5077797 on a spare device on.

For IT administrators and fleet managers​

• Inventory and prioritize:
• Use management tooling to identify devices with KB5073455 installed and with Secure Launch / VSM enabled.
• Flag Enterprise/IoT images where Secure Launch is enforced by policy or OEM.
• Create a representative pilot ring:
• Include devices that use Secure Launch and other hardened‑boot settings; test shutdown, hibernate, Remote Desktop, and critical application workflows after deploying KB5077797.
• Deploy the OOB update (KB5077797) via your management platform:
• Validate the remediation and monitor telemetry for remaining edge cases.
• Avoid uninstalling security updates as a broad mitigation:
• Uninstalling an LCU may reintroduce critical security exposures. Use Known Issue Rollback (KIR) or targeted mitigations where Microsoft provides them (for example AVD issues had KIR guidance).
• Prepare playbooks:
• Train helpdesk staff on the interim command‑line workaround and on verifying Secure Launch configuration; prepare communication templates for affected users.

Why Microsoft’s response matters — strengths of the vendor approach​

• Rapid acknowledgement and remediation: Microsoft publicly recorded the symptom in its Release Health / KB notes and produced an out‑of‑band cumulative update (KB5077797) just days after reports emerged. That speed shows a pragmatic operational posture: prioritize a fix for regression that impacts availability and security.
• Clear interim guidance: the documented workaround (shutdown /s /t 0) is safe and preserves OS shutdown integrity compared with forcing physical power loss. Microsoft’s KB pages and community guidance consistently promoted that measure while the fix circulated.
• Trlth process: Microsoft’s KB change log and Release Health updates trace the known issue and subsequent remediation steps, allowing administrators to make evidence‑based deployment decisions.

Remaining risks, trade‑offs and cautionary points​

• Residual edge cases: Microsoft’s own Release Health notes and community telemetry indicate some devices remain impacted after KB5077797; these are likely driven by OEM firmware, drivers, or unusual management agent interactions. Administrators should treat the fix as high‑value but not absolutely final for all permutations. Flag: treat post‑OOB residuals as plausible until your piloted tests confirm otherwise.
• Hibernation is explicitly more fragile:es reported that hibernation remained unreliable in many cases and that no universal workaround for hibernation was available at the time of initial advisories. Expect hibernate‑specific diagnostics and testing to be required.
• Potential for collateral regressions: fixes that touch the servicing or boot orchestration cabsystems. Community reports during preview testing previously noted regressions such as Task Manager duplication in related servicing changes. Pilot and regressions tests are therefore essential.
• Don’t rush to uninstall security updates: removing antom is a blunt instrument that reduces security posture. Prefer OOB remedial packages, KIRs, or targeted mitigations that Microsoft provides.

Forensics and telemetry: what to collect if you need to escalate​

• Windows build and OS version (winver output).
• Installed KB list (output of DISM /online /Get-Packages).
• Secure Launch / VSM configuration state (msinfo32 output, Windows Security → Device security screenshot).
• System Event Viewer logs (System channel) around the shutdown event timestamps.
• Any OEM firmware versions, BIOS/UEFI logs or vendor update history.
• Management agent logs where applicable (MDM, SCCM/ConfigMgr, third‑party agents).

Broader lessons for Windows servicing and platform security​

• Security and operational determinism can collide: virtualization‑based hardening (Secure Launch) raises platform security but also modifies low‑level state transitions that update servicing assumes. Organizations should broaden test coverage to include hardened‑boot configurations.
• Pilot rings must reflect production diversity: firmware, OEM drivers, and third‑party agents can create edge conditions; pilot rings that omit secure‑boot or IoT images will miss these regressions. Expand pilot matrices to include hardened images.
• Treat Patch Tuesday as an operational event: security rollups that touch low‑level code require operational readiness: inventory, phased rollouts, telemetry, and communications plans — not just automatic acceptance.

Quick checklist — what to do now​

• Home users:
• If you’re unaffected, allow Microsoft Update to deliver KB5077797.
• If you experience restart‑on‑shutdown, use shutdown /s /t 0 to force power‑off until KB5077797 is installed and validated.
• IT teams:
• Inventory devices for KB5073455/KB5077797 and Secure Launch status.
• Validate KB5077797 in a representative pilo Launch devices.
• Deploy to production ring after regression checks and telemetry validation.
• Maintain communication templates for end users and helpdesk playbooks.
• Keep an eye on Microsoft Release Health for follow‑ups and any additional KIRs or corrective updates.

Conclusion​

Background / Overview​

The technical anatomy — why a security hardening change can affect shutdown​

What is System Guard Secure Launch?​

What is Virtual Secure Mode (VSM) and how is it related?​

Why shutdown/hibernate can convert into a restart​

Timeline — key dates and what Microsoft shipped​

• January 13, 2026 — Microsoft publishes KB5073455 (Windows 11, version 23H2, OS Build 22631.6491). Release‑health notes document the shutdown/hibernate regression for devices with Secure Launch enabled and a separate Azure Virtual Desktop/Windows 365 authentication regression.
• January 17, 2026 — Microsoft publishes an out‑of‑band update KB5077797 (OS Build 22631.6494) that includes a fix for the Secure Launch restart-on-shutdown regression for many impacted devices and addresses Remote Desktop sign‑in failures. This package first appeared via the Microsoft Update Catalog.
• January 24, 2026 — Microsoft publishes KB5078132 (OS Build 22631.6495), an out‑of‑band cumulative update available via Windows Update that includes the fixes from KB5073455 and KB5077797 and adds additional improvements (including addressing app unresponsiveness when using cloud-backed storage). Microsoft reported no current known issues for this package at the time of the advisory.

Scope and platforms affected​

• Primary footprint: Windows 11, version 23H2 devices where System Guard Secure Launch is enabled. Microsoft notes KB5073455 is offered to Enterprise and IoT editions of 23H2 — the SKUs where Secure Launch is commonly enforced — which reduces the probability that typical Home/Pro consumer devices will receive the package (or be in the affected configuration) by default.
• Microsoft and several outlets also list additional affected platforms (for related issues in the January servicing wave) including Windows 10 branches and LTSC variants; Notebookcheck and Microsoft’s release-health entries enumerate affected client versions where relevant. The shutdown/hibernate symptom itself was most visible on 23H2 configurations with Secure Launch active; the VSM expansion widened the surface for some devices. Where Microsoft’s KB notes differ in phrasing across updates, the release‑health dashboard was the authoritative source for the per‑SKU details.
• Real‑world impact: reports and forum diagnostics showed the behaviour across multiple OEMs — Dell, HP, Lenovo and others — in managed fleets and IoT devices where Secure Launch is enabled by policy or OEM image. The symptom is intermittent and environment‑dependent, because it depends on the interaction of firmware, drivers, the servicing stack, and Secure Launch/VSM.

How to confirm whether your machine is at risk​

• Confirm the update is installed:
• Settings → Windows Update → Update history and look for KB5073455 (dated January 13, 2026), KB5077797 (January 17), or KB5078132 (January 24).
• Or run in an elevated Command Prompt:
  DISM /online /get-packages | findstr 5073455
• For the remedial packages check for 5077797 and 5078132.
• Check Secure Launch / VBS / VSM state:
• Open System Information (msinfo32.exe). Look under System Summary for the rows: Virtualization‑based Security Services Running and Virtualization‑based Security Services Configured. If Secure Launch or System Guard is listed as running/configured, the device is likely configured for the feature.
• Use PowerShell for a scripted check:
  Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
  This exposes Device Guard / VBS status and indicates whether VBS is enabled and running. Microsoft’s guidance also shows a registry path for System Guard configuration: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard\Enabled (value 1 for configured). Use caution when reading or editing the registry.
• Functional test (only on non‑critical machines): with the update installed and Secure Launch active, choose Shut down from the Start menu. If the device restarts instead of powering off, it reproduces the vendor‑described symptom. Save work and test cautiously — this can cause battery drain on mobile devices if left unattended.

Mitigations, fixes and practical steps​

Short‑term, vendor‑documented workaround (immediate)​

• Microsoft’s documented interim workaround to force a shutdown is to run an elevated Command Prompt and execute:
  shutdown /s /t 0
  This issues an immediate shutdown request that bypasses the Start menu path and will reliably power the machine off while the regression is present. Microsoft explicitly stated there is currently no workaround for hibernation — hibernation attempts remain unreliable on affected devices until a permanent fix is applied.

Official remediation path (recommended)​

• Install KB5077797 (the January 17, 2026 out‑of‑band update) if your device is on Windows 11, version 23H2 and exhibits the Secure Launch restart behaviour. Initially this package was offered via the Microsoft Update Catalog to accelerate remedial distribution. Administrators can deploy the catalog package to targeted machines or let devices pull the update if available through their management channel.
• Install KB5078132 (the January 24, 2026 cumulative OOB package). KB5078132 is cumulative, includes fixes from KB5073455 and KB5077797, and is offered via Windows Update for devices that installed one of the January updates associated with the issue. Microsoft’s advisory showed that this package addresses the Secure Launch case (and additional cloud-storage app responsiveness issues). After KB5078132 is installed, Microsoft reported no current known issues in that package at the time of the KB note.

Note: If your environment uses WSUS, SCCM/Configuration Manager, or other management tooling, follow standard testing and staged deployment practices — deploy to a pilot ring first and validate on representative hardware. Do not assume the OOB package is universally harmless: the original issue itself was caused by an interaction of platform hardening and servicing orchestration.

Click to expand...

If the OOB update does not clear the symptom​

• Check whether the device also has VSM enabled; Microsoft flagged that some VSM-enabled devices may still be impacted and indicated that the VSM variant would be handled in a future update. If a device remains affected after KB5077797, consult Microsoft’s release‑health notes and product advisories for the latest status and remediation guidance.

Practical guidance for enterprise IT and administrators​

• Inventory first: Use automated scripts or management tooling to identify devices with Secure Launch enabled and with KB5073455 installed. Prioritise laptops, kiosk systems, and remote IoT endpoints where an unnoticed restart could cause battery drain or data loss.
• Pilot and stage: Test KB5077797 and KB5078132 in a representative pilot ring that includes a cross section of firmware vendors and hardware generations before broad deployment. This regression was environment‑dependent; the cost of hurried, untargeted rollout can be high.
• Communicate to users: If you manage fleets with Secure Launch enabled, inform end users about the workaround (shutdown /s /t 0) and the need to save work frequently until remediation is applied. For laptops, warn users about potential overnight battery drain if hibernation fails.
• Avoid unnecessary disabling of VBS/Secure Launch in production: Disabling Secure Launch or VBS reduces a platform’s security posture. Only consider feature adjustments where a strong operational imperative exists and after formal risk approval. Where feasible, isolate impacted devices and remediate via Microsoft updates instead of disabling platform protections.
• Track Microsoft’s release‑health updates: Microsoft updated the KB notes and release-health entries iteratively as fixes and edge cases were added; keep an eye on those entries and test against the specific OS build strings (22631.6491 → 22631.6494 → 22631.6495).

Risks, lessons and wider implications​

• The bug illustrates a recurring trade‑off: as platform hardening moves earlier into the boot path, the surface area for interaction bugs increases. Secure Launch and VSM are advanced protections designed to neutralise firmware‑level threats; their presence changes timing and state semantics for servicing and boot transitions, and that complexity can reveal latent assumptions in update orchestration logic. The result here was a configuration‑dependent regression — narrow in scope but materially disruptive where it occurred.
• Testing and OEM coordination matter. The issue underlines the need for broader, representative testing across OEM firmware variants and enterprise images before shipping changes that alter early-boot behavior. Administrators and OEM partners should be included in validation pipelines to reduce the chance of regressions in managed fleets and IoT deployments.
• Operational costs can be non‑trivial. For fleets where Secure Launch is mandated for compliance, the regression increased helpdesk load, risked data loss (unsaved work), and created battery‑drain incidents on mobile devices. Those are real operational expenses that go beyond the headline of a single bug.
• Communication transparency matters. Microsoft documented the issue and shipped an out‑of‑band fix quickly, but the iterative nature of the advisory (expanding the impact to VSM cases and adding fixes in subsequent KBs) demonstrates how release-health advisories evolve as engineering learns more from telemetry. Administrators should treat initial vendor notes as accurate but potentially incomplete and plan for staged remediation.

Quick checklist — what to do right now​

• Verify whether KB5073455, KB5077797, or KB5078132 is installed on your device(s).
• Use msinfo32 or Get‑CimInstance (Win32_DeviceGuard) to check whether Secure Launch / VBS / VSM are configured and running.
• If affected and you need an immediate power‑off, run: shutdown /s /t 0 (elevated prompt). Do not rely on hibernation while the issue persists.
• Deploy KB5077797 (Update Catalog) or KB5078132 (Windows Update) in a tested pilot ring, then roll out broadly once validated.
• Communicate to end users and operations teams: save work frequently, avoid relying on hibernation for now, and report any machines that still reboot after installing the OOB updates.

Final analysis — strengths, weaknesses and what to watch next​

• Treat security features like Secure Launch as managed configuration items — inventory them, test updates against them, and treat their activation as a policy-controlled change rather than an always‑on consumer default.
• Use pilot rings and phased deployment to catch configuration‑dependent regressions before broad rollout.
• Coordinate with OEMs for firmware patches when update orchestration crosses firmware boundaries.