KB5077797 Out-of-Band Patch Fixes Windows 11 23H2 Shutdown and Remote Desktop Issues

Microsoft moved fast this week to contain a disruptive Windows 11 reliability regression: an urgent, out‑of‑band patch labeled KB5077797 was published on January 17, 2026 to repair a shutdown/hibernate regression and related Remote Desktop authentication failures introduced by January’s Patch Tuesday rollup. The fixes target Windows 11 version 23H2 devices — primarily those with System Guard Secure Launch enabled — and were released alongside companion OOB packages for other servicing branches to restore predictable power‑state behavior and remote sign‑in functionality.

Background / Overview​

Microsoft’s regular January Patch Tuesday updates shipped on January 13, 2026 and included cumulative servicing for multiple Windows 11 branches. Within days of that rollup, administrators and cloud operators began reporting two distinct, high‑impact regressions: (1) some Windows 11 23H2 machines with System Guard Secure Launch enabled were restarting instead of powering off or entering hibernation, and (2) several Remote Desktop/Cloud‑PC authentication flows began failing with repeated credential prompts. Microsoft acknown its Release Health notes and shipped targeted out‑of‑band updates four days later to remediate the issues. This article synthesizes the vendor advisories and community telemetry, explains the technical causes at a high level, evaluates Microsoft’s response, and provides practical guidance IT teams and power users can use to confirm remediation and reduce future risk.

---

What broke: the shutdown and hibernate regression​

The symptom in plain language​

On affected systems, a normal shutdown or an attempt to hibernate would appear to start but the machine would instead immediately restart and return to the sign‑in surface. In other cases hibernation failed outright. For laptop users this meant unexpected battery drain overnight; for managed fleets it broke imaging workflows, scheduled maintenance, and kiosk or field device expectations. The symptom was not universal — it required a particular configuration to align.

Who was affected​

• Primary exposure: Windows 11, version 23H2 devices that have System Guard Secure Launch enabled. This configuration is common in Enterprise, Education, and specialized IoT/managed images but is not typically present on consumer Home installations unless explicitly enabled.
• Secondary impact: Remote Desktop authentication failures affected additional servicing branches (Windows 11 24H2/25H2, some Windows 10 ESU and server SKUs) and therefore required broader remediations across multiple OOB packages.

Why the configuration mattered​

System Guard Secure Launch is a virtualization‑based early‑boot hardening feature; it inserts a measured virtualization boundary during platform initialization to defend against firmware‑level tampering. That boundary changes early‑boot semantics and timing. Windows update servicing uses multi‑phase commits that may finalize offline during shutdown/reboot — the OS must preserve the user’s final power intent (shutdown vs restart vs hibernate) across those phases. When the servicing orchestration does not correctly carry the intent through the Secure Launch path, the system can conservatively choose a restart to guarantee offline commits complete, producing the observed restart‑in‑stead‑of‑shutdown behavior. Microsoft characterized the regression in these orchestration/regression terms.

---

The emergency response: KB5077797 and companion updates​

What Microsoft shipped​

• KB5077797 — Out‑of‑band cumulative update for Windows 11, version 23H2 (OS Build 22631.6494), released January 17, 2026. The package bundles the January security content and includes targeted fixes that explicitly address the Secure Launch restart‑on‑shutdown/hibernate regression and Remote Desktop authentication failures.
• KB5077744 — Out‑of‑band cumulative update for Windows 11 versions 24H2 and 25H2, also released January 17, 2026, which focuses on restoring Remote Desktop authentication flows affected by the January 13 rollup.

Microsoft also published companion OOB packages for server and ESU servicing branches to address the Remote Desktop authentication regression there. The vendor made these updates available via Windows Update and the Microsoft Update Catalog, and included Servicing Stack Updates (SSUs) inside the combined packages where needed.

Interim mitigations Microsoft documented​

While engineering prepared the OOB patches, Microsoft documented a pragmatic but limited workaround: run an elevated command prompt and issue:

• shutdown /s /t 0

That forces an immediate, orderly shutdown and was recommended as a temporary mitigation for affected systems. Microsoft warned that hibernation had no reliable workaround before the remedial update, and that the shutdown command may not succeed in every edge case. Administrators were asked to conserve hibernation workflows until the OOB packages were applied and validated.

---

Additional fixes and the broader January servicing context​

January’s Patch Tuesday rollup (the initial packages shipped January 13, 2026) included a wide range of security and quality fixes across Windows servicing branches. That package — tracked as KB5073455 for Windows 11 23H2 — is the update that introduced the configuration‑dependent regression that KB5077797 later remedied. Microsoft’s public KB for the January rollup documents the update and the known issue tied to Secure Launch. Alongside the shutdown regression, the January updates also correlated with other user‑facing problems (for example, credential prompt loops in some Remote Desktop and Cloud PC flows). Those authentication issues prompted Known Issue Rollback (KIR) mitigations for managed environments in some cases and were a primary reason Microsoft issued out‑of‑band updates covering multiple servicing lines. Note: some earlier summaries circulating online misdated the remedial package to 2023. That is incorrect — the Patch Tuesday rollup and the subsequent OOB fixes were published in January 2026, and the authoritative Microsoft KB pages carry those dates. Administrators should use the vendor KB pages and update history dialogs to confirm install status and build strings on endpoints.

---

Technical analysis: root cause, attack surface, and why this happened​

High‑level cause​

The regression is best described as a servicing‑orchestration interaction introduced by the January rollup that surfaced when Secure Launch changed the pre‑OS/boot sequencing. In multi‑phase updates, offline commits during shutdown must be coordinated precisely with the power intent that the user selected. Secure Launch’s early virtualization boundary alters both timing and the route by which intent is persisted and reconstituted. If the updated servicing stack failed to persist or reapply the requested power state across that boundary, a conservative fallback to restart would occur so that update commits could complete predictably — at the cost of violating the requested shutdown. Microsoft’s public advisory frames the problem this way; while the vendor has not published low‑level source code or trace artifacts publicly, the orchestration explanation fits the observed configuration dependency and the timing pattern.

Why this is particularly tricky for testing​

• Hardware and firmware diversity: OEM firmware revisions, UEFI implementations, and platform‑specific drivers cause variability in how early‑boot features behave.
• Security hardening features: Features like Secure Launch and other VBS components add protection but also multiply the interactions the servicing stack must handle.
• Multi‑phase updates: Modern cumulative updates involve runtime stagingion steps that must interoperate with firmware behavior — a fragile, stateful choreography.

Those three factors mean a narrowly scoped code or timing regression may only appear in test beds that replicate enterpriSecure Launch enabled; consumer desktops that don’t enable Secure Launch by default will see far less exposure.

---

Practical guidance for administrators and power users​

Detection: how to know if you’re exposed​

• Confirm OS and build: run Win+R → winver and verify Windows 11 version 23H2 and the re2631.*). Check Update History for KB5073455 (January 13 LCU) and KB5077797 (January 17 OOB).
• Check Secure Launch status: open System Information (msinfo32.exe) and look for Virtualization‑based Security / System Guard flags, or query management tooling/MDM for System Guard policies. Secure Launch enabled is a precondition for the shutdown regression.
• Reproduce carefully: save work, then select Shut down. If the device restarts instead of powering off, it matches the documented symptom. Investigate Event Viewer (Kernel‑Power events) for abnormal transitions.

Immedi you see symptoms)​

• Save all work and notify end users to avoid data loss.
• Force a shutdown as Microsoft recommended: open an elevated prompt and run shutdown /s /t 0. This often forces a clean power‑off. Note it is an interim mitigation and may not work in every edge case.
• Install KB5077797 (for 23H2) or the appropriate OOB packageranch as soon as practical via Windows Update, WSUS, or the Microsoft Update Catalog. Validate shutdown and hibernate semantics after installation.

Deployment checklist for enterprise rollouts​

• Pilot the remedial update in a ring that includes representative OEMs, firmware revisions, and devices with Secure Launch enabled.
• Test both shutdown and hibernation explicitly; hibernation may require additional validation because firmware and drivers affect that path.
• Avoid disabling Secure Launch as a permanent workaround — that reduces platform security and may violate compliance. Prefer targeted remedial updates and KIR e telemetry and help‑desk feedback to monitor for residual regressions post‑deployment.

---

Critical assessment of Microsoft’s response​

Strengths​

• Speed: Microsoft released out‑of‑band updates within four days of the initial rollup, demonstrating an effe pipeline for operationally impactful regressions.
• Targeted fixes: The vendor used focused OOB packages per servicing branch (KB5077797 for 23H2 and KB5077744 for 24H2/25H2) rather than a blanket reversion, which allowed security fixes to remain in place while addressing regressions.
• Interim guidance: Microsoft published a practical forced‑shutdown command and KIR options where appropriate to mitigate user and enterprise impact while the fix shipped.

Risks and shortcomings​

• Testing surface limitations: This incident underscores the difficulty of validating updates across the explosion of hardware/firmware permutations and security hardening states used by enterprises. The regression was narrowly scoped but very disruptive where present, indicating gaps in representative test coverage.
• Hibernation remains tricky: Microsoft’s interim workaround did not restore hibernation reliably, and administrators must explicitly validate Hibernate behavior post‑patch — a nuance that raises risk for laptop fleets and field devices reliant on low‑power state.
• Communication friction: Rapid fixes are necessary but can cause confusion about what to install and when. Clear, time‑stamped guidance and concise remediation playbooks are essential to reduce help‑desk churn during these emergency cycles. Community reporting and forum telemetry filled important gaps, but reliance on community signals points to the need for more proactive notification strategies for enterprise customers.

-rational lessons

• Build representative pilot rings that include devices with strong security posture (Secure Launch, VBS) and diverse OEM firmware. This prevents surprises that only emerge on highly hardened images.
• Use staged rollouts and telemetry gating rather than broad automatic cumulative updates, especially early in the year when many enterprises perform reboots and maintenance windows.
• Maintain rapid rollback and KIR capabilities as part of a mature patch management playbook so that emergency regressions can be scoped and mitigated without discarding critical security content.
• Treat emergency OOB updates as inevitable; design incident response playbooks that include immediate mitigation steps, communications templates, and prioritised validation checklists.

---

Quick checklist (one page) for administrators​

• Confirm OS and builds: Win+R → winver. Look for 23H2 (22631.*), KB5073455 (Jan 13) and KB5077797 (Jan 17).
• Inventory Secure Launch: msinfo32 or management tooling. Devices with Secure Launch enabled are the primary risk group.
• If symptoms present: run shutdown /s /t 0 to force shutdown, then install KB5077797. Validate shutdown and hibernate.
• Pilot OOB packages across representative firmware/OEM combinations before broad deployment. Monitor telemetry for 72 hours.

---

Conclusion​

The January 2026 Patch Tuesday cycle delivered important security and quality fixes, but it also highlighted the operational fragility that can appear when low‑level platform hardening features intersect with complex servicing workflows. Microsoft’s rapid, targeted response — shipping KB5077797 and related OOB packages on January 17, 2026 — corrected a configuration‑dependent shutdown/hibernate regression and restored Remote Desktop authentication flows for affected servicing branches. Administrators should confirm that KB5077797 (for Windows 11 23H2) or the corresponding OOB package for their servicing line is installed, validate shutdown and hibernation behavior across representative hardware, and avoid permanent disablement of security features such as Secure Launch. The incident is a clear reminder: patching remains essential, but so does disciplined, telemetry‑driven testing and staged deployment to keep both security posture and operational reliability intact.

---

Source: filmogaz.com Microsoft Tackles Windows 11 Shutdown Bug with Urgent Fix

 

[ChatGPT]

Microsoft’s January security rollup introduced a narrowly scoped but disruptive Windows 11 regression: after installing the January 13, 2026 cumulative update (tracked as KB5073455073455), some systems—primarily those running Windows 11, version 23H2 with System Guard Secure Launch enabled—would not remain powered off when users chose Shut down or Hibernate, instead rebooting immediately; Microsoft acknowledged the problem and issued an emergency out‑of‑band remedial update on January 17, 2026 (notably KB5077797 for 23H2) to correct the behavior and several related remote‑access authentication issues.

---

Background​

The January Patch Tuesday wave published on January 13, 2026 bundled the typical servicing-stack updates (SSU) and Latest Cumulative Updates (LCU) for multiple Windows servicing branches. For Windows 11, version 23H2, that LCU was released as KB5073455 (OS Build 22631.6491). Within hours and days of rollout, field telemetry and community reports surfaced two distinct regressions: a power‑state regression that caused some Secure Launch start when asked to shut down or hibernate, and a separate Remote Desktop / Cloud PC authentication regression that broke certain sign‑in flows. Microsoft documented both issues and moved quickly to publish out‑of‑band fixes on January 17, 2026.

What System Guard Secure Launch is and why it matters​

System Guard Secure Launch is a virtualization‑based early‑boot protection designed to harden the pre‑OS environment and guard against firmware-level compromise. It inserts additional virtualization boundaries and alters early boot semantics to create a measured, secure launch path. Because Secure Launch changes how the platform initializes and persists state across the shutdown/reboot boundary, it can interact with update servicing orchestration in ways that don’t appear on consumer machines that lack this enforcement. That combination of deep security and increased complexity is the root reason this regression was configuration‑dependent and concentrated in Enterprise and IoT deployments.

---

What happened: timeline and technical anatomy​

The sequence is short but instructive.

• January 13, 2026 — Microsoft published the January cumulative updaversion 23H2 this was KB5073455.
• January 13–16, 2026 — Administrators, telemetry, and community channels reported systems failing to complete shutdown or hibernate and instead returning to the sisters reported Remote Desktop authentication failures. Microsoft logged the conditions on Release Health and provided interim guidance.
• January 17, 2026 — Microsoft released targeted out‑of‑band cumulative updates that included fixes for the reported regressions, notably KB5077797 for Windows 11 23H2 (OS Build 22631.6494). The OOB packages combined SSU + LCU elements and were distributed through normal channels (Windows Update, Microsoft Update Catalog) to speed remediation.

Why the system restarted instead of powering off​

Windows cumulative updates use a multi‑phase servicing orchestration: files are staged while the OS runs, then offline commits happen across a shutdown or reboot. The sersist the user’s final power intent (shutdown, restart, or hibernate) across those phases. Secure Launch modifies early‑boot and runtime boundaries; on certain firmware/driver combinations the servicing orchestration failed to preserve or reconstitute that final power intent across the Secure Launch boundarc conservatively fell back to performing a restart to guarantee update commitments completed, producing the visible symptom: a brief black screen followed by an unexpected boot. Microsoft characterized the issue as a configuration‑dependent orchestration interaction rather than a single, default.

---

Who was affected​

• Primary footprint: Windows 11, version 23H2 systems where Secure Launch is enabled — typically Enterprise, Education, and IoT images and devices. These SKUs and managed images are where Secure Launch is most commonly enforced.
• Secondary footprint: Remote Desktop / Cloud PC authentication failures impacted a broader set of servicing branches (d some Windows Server and Windows 10 ESU channels); those authentication regressions were addressed in companion OOB updates.
• Consumer Home and most Pro devices were far less likely to be affected becauot usually enabled by default on those editions. That explains why the overall percentage of Windows installations exposed was small while the impact in affected fleets could be significant.

Important caveat: Microsoft has not published a precise count of affected devices, and public telemetry estimates are noisy and largely anecdotal. Enterprises should treat prevalence numbers from community reporting as directional rather than definitive.

---

Symptadmins saw​

• Selecting Shut down from Start or executing a hibernate often produced a brief screen blanking followed by a return to the sign‑in screen or a full reboot. This made the device appear to refuse to power off.
• Hibernation could fail entirely, leading mobile and field devices to remain powered and drain batteries.
• Separate Remote Desktop workflows could fail during authentication, presenting repeated credential prompts or immediate sign‑in failures in the Wsome Cloud PC / AVD scenarios.

Symptoms were typically silent — there was no explicit error dialog; the device simply executed the wrong power action. That made detection harder unless administrators were watching automated maintenance windows or received user reports.

---

Microsoft’s response: emergency out‑of‑band fixes and guidance​

Microsoft logged the regression on its Release Health pages, published interim guidance, and shipped one or more out‑of‑band cumulative updates on January 17, 2026. The corrective packages combined SSU improvements with the LCU fixes and explicitly listed the two high‑impact regression items: power & battery behavior on Secure Launch devices and Remote Desktop sign‑in failures. Administrators were urged to deploy the OOB packages via managed channels (Windows Update, WSUS, Microsoft Update Catalog, Intune) and validate remediation in pilot rings first.

Verified patch identifiers and dates​

• KB5073455 — January 13, 2026 cumulative update for Windows 11, version 23H2 (original rollup that introduced the regression).
• KB5077797 — January 17, 2026 out‑of‑band cumulative update for Windows 11, 23H2; it includes the fix for instead of shutdown and RDP sign‑in fixes.

These KB numbers and dates appear on Microsoft’s official support pages and match independent reporting in major outlets.

---

nd cautions​

Until the remedial packages reach every system, Microsoft documented an emergency workaround to force an immediate shutdown:

• Open an elevated Command Prompt and run:
  shutdown /s /t 0

This forces an immediate, orderly shutdown and served as a pragmatic stop that forced shutdowns can close applications abruptly and risk data loss if unsaved work is present; it was intended as a short‑term emergency measure only. A separate thread of community and Q&A reporting indicates that, on some systems where Secure Launch is enforced in firmware, the OOB patch did not completely restore shutdown semantics and admin reporting to disabling Secure Launch (via UEFI/BIOS or registry changes) to recover deterministic shutdown behavior. Microsoft’s public guidance does not recommend disabling Secure Launch as a long‑term fix because it reduces boot‑time protection be a controlled, last resort and only with clear risk acceptance. Treat those reports as case‑specific and use caution before altering Secure Launch settings in production.

---

How administrators should detect and remediate exposure​

Follow a controlled, auditable approach when assessing exposure and deploying the OOB updates.

• Inventory exposure:
• Check installed updates: Settings → Windows Update → Update History; look for KB5073455 (installed Jan 13) and whether KB5077797 has been applied.
• Confirm OS verslaiming the issue are on Windows 11, version 23H2 (OS Build 22631.x).
• Detect Secure Launch status: use System Information (msinfo32) and review System Guard / Secure Launch flags, or query firmware/Group Policy settings used to enforce Secure Launch. Secure Launch requires TPM 2.0, UEFI Secure Boot, and CPU virtualization extensioptom:
• On candidate machines, select Shut down from the Start menu (or call shutdown /s /t 0 to test the forced path) and observe whether the system completes S5 or reboots. Collect Event Viewer logs (System and Setup channels) for diagnostics.
• Pilot remediation:
• Acquire KB5077797 (orackage for your servicing branch) and stage it in a pilot ring that accurately represents Secure Launch–enabled devices. Validate shutdown, hibernate, and RDP/cloud desktop connections.
• Deploy broadly:
• Use staged rollouts (pilot → broad test → production) andd support tickets. Prefer managed channels (WSUS, Intune/ConfigMgr, Microsoft Update Catalog) for traceability and rollback capability.
• If the OOB patch does not resolve the symptom:
• Escalate to Microsoft Support with collected logs and environment details. Consider controlled, temporary changes only with explicit risk acceptancearily disabling Secure Launch in UEFI as a diagnostic step), but avoid altering security posture without management sign‑off.

---

Enterprise impact and operational risks​

This incident exposes the tension between platform hardening and servicing reliability. The mechanics are straightforward but meaningful.

• Operational disruption: For enterprises that depend on deterministic shutdown/hibernate behavior (imaging systems, overnight maintenance windows, kiosk/POS fleets, or IoT endpoints), a small configuration‑dependent bug can brea battery or availability issues.
• Security vs. convenience tradeoffs: Secure Launch improves boot integrity and defends against sophisticated firmware attacks. However, enabling changes the test matrix and increases the chance that a servicing change will interact badly with device firmware, drivers, or vendor‑specific implementation differences.
• Patch governance: Rapid out‑of‑band fixes are necessary when regressions threaten reliability, but they also complicate change control if teams push updates too quickly without representative pilot rings. This event highlights the need for conservative deployment l fleets.

Notably, the bug was not a security compromise; it was an availability/reliability regression. That distinction matters for incident prnications, but it does not reduce the operational urgency for fleets dependent on deterministic power states.

---

What this episode reveals about modern Windows servicing​

• Complexity multiplies risk: Virtualization‑based protections like Secure Launch and VBS increase the attack surface for low‑level regressions because they alter assumptions about boot and runtime state. When servicing code touches those paths, edge cases become visible.
• The value of rapid remediation: Microsoft’s decision to publish an out‑of‑band fix within four days demonstrates a reasonably fast vendor response model for high‑impact regressions. That rapidity mitigates downstream operational damage but does not eliminate the need for local validation and patch governt be representative: Organizations that enforce Secure Launch or other advanced platform hardening must ensure their preproduction test rings include devices with those protections enabled, plus real firmware vendor variants and driver sets. Generic pilot rings that omit such combinations will miss regressions that matter in the field.

---

Recommended checklist for IT teams (prioritized)​

• Immediate (0–24 hours)
• Inventory and tag devices that are Windows 11, version 23H2 and have Secure Launch enabled.
• Apply KB5077797 via your managed pilot devices.
• Use shutdown /s /t 0 as an emergency measure for symptomatic devices only, after saving wot.
• Short term (1–7 days)
• VaC sign‑in workflows after applying the OOB updates.
• Expand the pilot to include firmware variants from all major OEMs represented in your fleet.
• Ongoing (2–8 weeks)
• Update change management procedures to include Secure Launch–enabled device classes in preproduction testing matrices.
• Maintain a rollback plan and document any temporary security posture changes (for example, temporarily disabling Secure Launch) and attendant risk approvals.

---

Strengths and limitations of Microsoft’s handling​

Strengths:

• Microsoft publicly acknowledged the issues on Release Health and issued documented interim guidance.
• The vendor produced targeted OOB cumulative packages quickly and distributed them through managed channels.

Limitations and risks:

• The initial regression reveals gaps in prerelease testing coverage for hardened configurations; Secure Launch and similar features require representative OEM/firmware test permutations that evidently weren’t exhaustive.
• Some field reports and Q&A threads indicate the OOB fix did not fully resolve every case where Secure Launch was envel, forcing administrators into riskier mitigations (temporary Secure Launch disablement). Those isolated cases underscore the need for thorough vendor/OEM collaboration and clear escalation paths.

Where public telemetry is absent, external observers should be cautious about extrapolating scale from forum posts; authoritative prevalence numbers remain internal to Microsoft and OEM telemetry.

---

Looking ahead — practical lessons for reliability and security​

• Expand representative testing to include security-hardened configurations. When enterprises adopt features like Secure Launch, those configurations must be part of the primary test matrix, not optional edge cases.
• Maintain controlled pilot rings and use telemetry thresholds to gate broad rollouts. Patch cadences are necessary, but so is conservative rollout for mission‑critical endpoints.
• Preserve fast remediation channels: out‑of‑band packaging and Known Issue Rollback (KIR) options are useful mechanisms; IT teams should have procedures to detect and act on such vendor advisories quickly.
• Balance security posture changes with risk acceptance: disabling Secure Launch reduces protections; such steps must be temporary, documented, and approved at the appropriate risk level.

---

Conclusion​

The January 2026 Windows 11 servicing episode is a textbook case of the tradeoffs inherent in modern platform hardening: advanced protections like System Guard Secure Launch materially improve boot‑time security, but they also enlarge the test matrix and reveal fragile intersections with update servicing orchestration. Microsoft’s admission of the issue and the rapid publication of out‑of‑band fixes (notably KB5077797 on January 17, 2026) were appropriate responses that mitigated immediate operational pain for many organizations. However, the incident reinforces that enterprises adopting hardened configurations must demand representative preproduction validation, maintain disciplined patch governance, and prepare operational mitigations that preserve both security and reliability. The practical next steps for IT teams are clear: inventory Secure Launch exposure, deploy the January 17 remedial packages through managed channels after piloting, validate shutdown/hibernate and remote‑access workflows, and update testing and rollout policies so that future updates do not produce similar interruptions in critical fleets.

---

---

Source: The420.in Windows 11 Bug Triggers Automatic Restarts, Microsoft Issues Emergency Fix - The420.in