January 2026 Windows OOB Updates: KB5077744 and KB5077797 Explained

Microsoft released emergency out‑of‑band updates on January 17, 2026 — most notably KB5077744 and KB5077797 — to address critical post‑Patch‑Tuesday regressions that left many users unable to sign in to Remote Desktop services or in some cases unable to shut down cleanly. The packages are available through Windows Update for automatic deployment, and Microsoft has also published standalone installers in the Microsoft Update Catalog for administrators or users who need to download and apply the fixes manually.

Background​

Windows Update occasionally issues out‑of‑band (OOB) releases when a broad reliability or security regression is discovered after the normal Patch Tuesday cycle. These emergency updates are cumulative and typically include the latest servicing stack update (SSU) combined with the latest cumulative LCU (latest cumulative update) so devices receive both servicing and quality fixes in one package. Microsoft documents this combined SSU+LCU approach and publishes KB articles for each OOB release that describe the scope, affected builds, and known issues. Out‑of‑band updates are inherently reactive: they are designed to restore critical functionality quickly. That speed is a strength when businesses and remote workers are impacted, but it also raises deployment and testing concerns for IT teams responsible for large fleets. The January 17 releases are a clear example — Microsoft acted quickly to remediate serious regressions introduced by January 13 updates, but a handful of other regressions remain under investigation.

---

What Microsoft released: the KBs and what they fix​

KB5077744 — Windows 11 (25H2 / 24H2)​

• Applies to: Windows 11 versions 25H2 and 24H2.
• Identified OS builds: 26200.7627 (25H2) and 26100.7627 (24H2).
• Primary fix: restores Remote Desktop credential and sign‑in flows that were failing after the January 13 security update (customers reported immediate authentication failures in Remote Desktop clients and the Windows App).
• Package notes: cumulative LCU plus a servicing stack update (SSU KB5071142) and updates to certain AI components used on Copilot‑enabled devices.
• Availability: automatic via Windows Update and as a standalone download through Microsoft Update Catalog for manual deployment.

KB5077797 — Windows 11 (23H2)​

• Applies to: Windows 11 version 23H2.
• Identified OS build: 22631.6494.
• Primary fixes: resolves the Remote Desktop sign‑in failures observed after January 13, and fixes a separate regression where some devices with Secure Launch enabled would restart instead of shutting down or entering hibernation.
• Package notes: combined SSU (KB5071963) and LCU; Microsoft reports no known issues at the time of publication for this KB.
• Availability: automatic via Windows Update and as a manual download from the Microsoft Update Catalog.

Windows 10 and other platform coverage​

Microsoft published out‑of‑band updates for a range of platforms alongside the Windows 11 fixes. For Windows 10 and extended servicing channels there are corresponding OOB packages (for example, KB5077796 and others) that also address Remote Desktop authentication failures introduced by the January updates. Administrators should consult the relevant Microsoft KB page for their specific platform/version to confirm the correct package.

---

Why these fixes mattered: impact and scope​

The post‑Patch‑Tuesday regressions struck at core remote access and power management behaviors:

• Remote Desktop credential prompt failures were widespread enough to affect cloud PC, Azure Virtual Desktop, and Windows App RDP use. The authentication flow was terminating early on the client side, blocking session creation and leaving users unable to connect to managed remote desktops. This created a high‑priority availability problem for remote work.
• Some devices with Secure Launch enabled — a security feature used on certain enterprise hardware — were experiencing restarts when issuing a shutdown or hibernate. That behavior directly affects shutdown automation, imaging scripts, and power control in managed data centers and branch offices. KB5077797 explicitly lists this regression and its fix.

Enterprises relying heavily on remote desktop services saw productivity disruptions and escalations to MSPs and Microsoft support. Independent community reporting and enterprise telemetry signals were cited in Microsoft’s KB text and industry coverage, which helped prioritize the rapid OOB release strategy.

---

How Microsoft made the fixes available​

Microsoft’s OOB KB pages make two deployment paths clear:

• Automatic rollout via Windows Update and Windows Update for Business/WSUS, where devices will receive the update through normal channels based on rollout policies.
• Manual download from the Microsoft Update Catalog for direct deployment, offline installation, or pushing via systems management tools.

Microsoft explicitly notes that the combined SSU+LCU package cannot be uninstalled using wusa.exe /uninstall because the SSU is included, and SSUs cannot be removed after installation. Administrators who need to remove the LCU component must use DISM with the appropriate remove package command specifying the LCU package name — but this is advanced and requires careful attention to dependencies.

---

Manual download and installation: practical steps​

For administrators and power users who prefer manual control or need to apply the fix immediately to affected machines, the Microsoft Update Catalog provides standalone packages (.msu or .cab). The following is an actionable, verified procedure based on Microsoft documentation and Microsoft Learn guidance.

• Search the Microsoft Update Catalog
• Open the Microsoft Update Catalog in a web browser and search for the KB number (for example, KB5077744 or KB5077797). Select the row that matches your OS architecture (x64, ARM64).
• Download the package
• Use the Catalog’s Download button and save the .msu or .cab files to a local folder on the target machine or your management server. Modern browsers are supported; Internet Explorer/ActiveX is no longer required.
• Install using WUSA (for .msu)
• Double‑click the .msu file to start the Windows Update Standalone Installer (WUSA), or run it from an elevated Command Prompt:
• wusa C:\path\to\Windows10.0‑KB5077744‑x64.msu /quiet /norestart
• Use the /quiet switch for unattended installs; use /norestart to delay automatic reboot. Microsoft’s WUSA documentation explains these switches and their behavior.
• Install using DISM (for .cab or image servicing)
• For CAB files or offline images use DISM:
• start /wait DISM.exe /Online /Add‑Package /PackagePath:C:\path\Windows11.0‑KB5077744.cab /Quiet /NoRestart
• DISM is also the supported tool for servicing offline WIM images and is documented for handling checkpoint cumulative updates.
• Verify installation and reboot
• After installation, check the OS build and installed packages (Settings → Windows Update → Update history or use DISM /online /get‑packages) and then reboot if required. Reboots may be necessary to complete SSU and LCU updates.

Important notes and verifications:

• Microsoft’s KB articles explicitly warn that combined SSU+LCU packages cannot be uninstalled using wusa.exe /uninstall because the SSU cannot be removed once applied. If rollback is required, administrators must follow DISM remove package procedures and have a tested recovery plan.
• When multiple checkpoint cumulative updates are required, WUSA and DISM support installing the necessary sequence when the files are placed in the same folder; Microsoft documents the correct ordering behavior for checkpoint cumulative installs.

---

Recommendations for administrators and power users​

• If your environment is affected: prioritize patching. If you see RDP authentication failures or unexpected restart-on-shutdown behavior, apply the appropriate OOB package immediately. Manual install from the Update Catalog is acceptable for urgent remediation. Test the package on a small pilot group before broad deployment.
• If you are not affected: consider a measured approach. Monitor Windows Update deployment and the Windows release health dashboard; avoid rushing updates into production without testing if no symptoms are present.
• Enterprise fleets: prefer Known Issue Rollback (KIR) where Microsoft provides the rollback artifact, or use Group Policy to deploy KIR when applicable. KIR is a more surgical mitigation for managed fleets than uninstalling cumulative updates.
• Back up before mass deployment: because SSUs are non‑removable via wusa and because OOB packages are cumulative, ensure you have system state/backups and tested rollback procedures for critical servers.
• Check dependent components: for environments using Azure Virtual Desktop, Cloud PCs, or third‑party RDP clients, validate connectivity post‑patch and confirm no other app‑level side effects (Outlook, Teams, browser integrations) have been introduced. Industry reporting indicates some app interactions remain under review.

---

Critical analysis: strengths and risks​

Strengths — Microsoft’s response and communication​

• Rapid remediation: Microsoft identified a major regression (Remote Desktop authentication failures) and issued OOB cumulative updates within days of Patch Tuesday. Quick OOB releases reduce downtime for businesses reliant on remote work. This responsiveness is a clear operational strength for Microsoft’s servicing model.
• Clear KB documentation: the KB articles list affected versions, OS builds, the user‑visible symptom, the fix, and known issues, allowing admins to match package to platform. The inclusion of SSU details and explicit install/uninstall guidance helps reduce accidental missteps during manual deployment.
• Catalog availability: publishing manual installers in the Microsoft Update Catalog gives IT full control when automatic updates are delayed by policy, network constraints, or urgent remediation needs.

Risks and outstanding concerns​

• Regression risk from emergency patches: OOB fixes are designed to be fast, not deeply experimental, yet every update changes system components. There are documented cases of residual regressions (black screen delays, desktop background resets, and an Outlook POP client freeze) reported by community outlets and users, which Microsoft has acknowledged in part and continues to investigate. That creates deployment risk for organizations lacking robust test windows. These remaining issues are under active investigation and may not yet be fully validated across all hardware/driver combinations.
• Uninstall complexity: combined SSU+LCU packaging means administrators cannot trivially undo an OOB installation with wusa.exe /uninstall. Removing the LCU requires DISM remove operations and dependency checks; in production environments, this adds operational overhead and risk if a rollback becomes necessary. Microsoft explicitly calls this out in the KBs.
• Incomplete public telemetry details: reporting and KB text indicate the issue affected “many” enterprise users, and third‑party outlets reference broad impact, but Microsoft does not publish raw telemetry or exact counts of affected devices. Claims about the scale of the outage should therefore be treated cautiously until Microsoft releases more detailed telemetry numbers. This is an example of where independent verification from large IT customers or Microsoft’s telemetry release would be necessary to quantify the outage precisely. This specific telemetry is not publicly available at the time of writing.
• Intersections with Copilot/AI components: KB5077744 updates several AI components used on Copilot+ devices. While Microsoft lists component versions, it does not imply these components affect every machine; they install only where applicable. Administrators in mixed fleets should be mindful of which devices receive those AI packages.

---

Frequently encountered questions (quick answers)​

• Will my PC get the update automatically?
  Yes — Windows Update will deliver the OOB package according to Microsoft’s rollout and your update policy; for immediate control, download the package from Microsoft Update Catalog.
• Can I uninstall the update if it causes trouble?
  Not via wusa.exe /uninstall if the combined SSU+LCU package is installed. Removing the LCU requires DISM and careful package‑dependency management. Back up and test before wide rollouts.
• Are servers affected?
  Microsoft released corresponding fixes for server SKUs as well (for example, Server 2025 and Server 2022 packages to address Remote Desktop issues). Check the Microsoft KBs for server‑specific packages.
• Is this a security vulnerability exploit?
  The published KBs describe regressions introduced by the January security update that impaired functionality — Microsoft’s language indicates these were not compromises or active exploitations, but reliability regressions that needed fixing.

---

Final assessment and practical takeaways​

Microsoft’s January 17 emergency updates — including KB5077744 and KB5077797 — demonstrate an effective rapid‑response cycle: a high‑impact regression was identified, investigated, and patched within days. For organizations and individual users struggling with Remote Desktop authentication or Secure Launch shutdown regressions, the OOB packages and Microsoft Update Catalog downloads provide immediate remediation options. At the same time, these emergency fixes underline two continuing realities of modern OS servicing:

• Rapid updates are essential but can introduce secondary regressions; thorough testing in a staged rollout remains the most reliable mitigation for enterprise risk.
• SSU+LCU combined packages simplify future servicing but complicate rollback paths — admins must prepare recovery plans and rely on Known Issue Rollback artifacts when available.

Practical next steps: verify whether your devices show the documented symptoms; apply the appropriate OOB package from the Microsoft Update Catalog to affected systems; pilot broadly before mass deployment; and maintain backups and recovery procedures in case further rollbacks are required. For environments managed at scale, prefer known mitigations like KIR or deploy the update via the organization’s patching infrastructure after testing.
The January emergency releases are a textbook case in balancing speed and caution: Microsoft acted quickly to restore critical functionality, but administrators must still exercise discipline when deploying these out‑of‑band packages across production fleets.

---

Conclusion: The KB5077744 and KB5077797 out‑of‑band updates are available now, through Windows Update and the Microsoft Update Catalog, and should be applied by affected users and administrators after appropriate testing. Administrators should pay particular attention to the combined SSU+LCU packaging, known remaining issues called out by Microsoft and industry reporting, and the recommended deployment best practices (pilot, backup, rollback planning) before mass rollout.

---

Source: Neowin https://www.neowin.net/news/microso...797-emergency-updates-for-manual-downloading/

 

[ChatGPT]

Microsoft pushed an emergency out‑of‑band (OOB) update on January 17, 2026 after its January Patch Tuesday rollup caused some Windows machines to refuse to power off and others to fail Remote Desktop sign‑ins — the fix (delivered as KB5077744, KB5077797 and companion packages) is rolling out now via Windows Update and the Microsoft Update Catalog.

Background / Overview​

Microsoft’s January cumulative updates (delivered on January 13, 2026) were intended to deliver routine security hardening and bug fixes across supported Windows branches. Instead, telemetry and rapid community reports surfaced two high‑impact regressions: a shutdown/hibernate failure that affected some Windows 11 devices running System Guard Secure Launch, and Remote Desktop authentication failures that broke cloud‑PC and RDP scenarios for several Windows branches. Microsoft acknowledged the problems publicly and issued targeted OOB packages on January 17 to remediate the most urgent regressions. Those rapid fixes are significant because out‑of‑band updates are reserved for problems that cannot wait for the normal monthly cadence; in this case Microsoft judged the regressions severe enough to warrant an emergency patch cycle. The immediate OOB packages include both the January fixes and the corrective code, and they bundle servicing‑stack updates (SSUs) that change how removals and rollbacks behave.

---

What went wrong: the two regressions explained​

1. Shutdown and hibernate — Secure Launch interaction​

• Symptom: On some Windows 11 devices, choosing Shut down or attempting Hibernate resulted in a restart instead of powering off or entering hibernation. In many cases the screen briefly went dark and fans or disks continued spinning before the device returned to the sign‑in screen.
• Scope: Microsoft tied the symptom to devices on Windows 11, version 23H2 where System Guard Secure Launch is enabled — a virtualization‑based early‑boot protection typically enforced in Enterprise and IoT images. That configuration dependency means consumer Home/Pro devices are far less likely to be affected.
• Immediate user impact: Laptops expected to hibernate overnight could instead stay powered on and drain battery; maintenance scripts and imaging processes that assume deterministic power‑off behavior could fail; helpdesks saw spikes in tickets. The inability to reliably hibernate or shut down has real operational consequences in managed fleets.

2. Remote Desktop / Cloud PC sign‑in failures​

• Symptom: After the January rollup, several Remote Desktop clients and Cloud PC scenarios experienced credential‑prompt or authentication failures that prevented sign‑in. That included certain Azure Virtual Desktop, Windows App client, and other RDP flows across Windows 11 and some Windows 10 Extended Security Update (ESU) channels.
• Scope: This issue impacted multiple branches — Windows 11 (various channel builds), Windows 10 ESU channels, and some Windows Server builds — making it particularly disruptive for organizations that rely on remote access as their primary work surface.

Both failures are configuration‑sensitive and surfaced quickly because remote access and power‑state determinism are highly visible, high‑urgency surfaces for admins and end users alike. Microsoft’s OOB packages targeted those two failures specifically.

---

Microsoft’s response: the emergency patches​

Microsoft released a set of out‑of‑band cumulative updates on January 17, 2026 to address the regressions:

• KB5077797 — OOB cumulative update for Windows 11 version 23H2 (OS build 22631.6494). This package specifically lists fixes for the Secure Launch shutdown/hibernate regression and Remote Desktop sign‑in failures.
• KB5077744 — OOB cumulative update for Windows 11 versions 24H2 and 25H2 (OS builds 26100.7627 and 26200.7627). This package restores Remote Desktop sign‑in/authentication flows broken by the January 13 security update.
• Companion OOB packages (KB5077796, KB5077795, KB5077793, etc. were published for Windows 10 ESU and server branches addressing the Remote Desktop authentication problems in those channels.

Microsoft’s KB pages emphasize that the OOB updates are cumulative and include the earlier January fixes plus the corrective code and servicing‑stack updates. Administrators should expect the SSU component to be present in the package and to affect uninstall behavior, so pilot testing is advised. Major independent outlets and platform community reports corroborated Microsoft’s timeline and the nature of the fixes, noting the patches were pushed quickly because the regressions could block business continuity for remote work or automation workflows.

---

How to know whether you’re affected​

Start with two questions: which OS/build do you run, and is System Guard Secure Launch active?

• Confirm the installed January update (Windows Update → Update history) or run:
• DISM listing command in an elevated prompt:
• DISM /online /get-packages | findstr 5073455
  This shows whether the January 13 cumulative (for example, KB5073455) is installed on 23H2 devices.
• Check Secure Launch state:
• Run System Information (msinfo32.exe). Under System Summary, look for Virtualization‑based Security Services Running and Virtualization‑based Security Services Configured; if System Guard / Secure Launch appears as running or configured, the feature is active.
• For scripted checks, verify the registry key:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard\Enabled
• If this DWORD = 1, Secure Launch is configured (confirm with msinfo32 that it’s actually running).
• For Remote Desktop problems, verify whether the January 13 security update affected your branch (Windows 11 24H2/25H2 or Windows 10 ESU) and whether users report immediate RDP/Cloud PC authentication failures. Microsoft’s KBs and status pages explicitly call out which builds and platforms were impacted.

If your device is Home/Pro and Secure Launch is not enabled, you are less likely to be affected by the shutdown regression — but Remote Desktop authentication problems could still appear on some branches, so monitor RDP behavior and apply the OOB fix if you experience sign‑in failures.

---

Short‑term workarounds and mitigations​

Microsoft documented vendor‑approved, immediate mitigations while the OOB packages rolled out:

• Force a guaranteed shutdown (temporary): open an elevated Command Prompt and run:
• shutdown /s /t 0
  This forces an immediate shutdown and is the recommended short‑term workaround for devices that restart when choosing Shut down from the Start menu. Note that Microsoft said there was no workaround for hibernation at the time of the advisory. Save work before running the command.
• Alternate Remote Desktop access: if Cloud PC or AVD connections fail, use the AVD web client or the classic Remote Desktop client as temporary fallbacks while the OOB packages are applied. Deploy Known Issue Rollback (KIR) Group Policy artifacts for managed fleets where Microsoft published them, rather than uninstalling security updates.
• Admin rollout guidance: do not broadly uninstall January security fixes to “solve” the problem — that exposes endpoints to security risk. Instead:
• Validate OOB packages in a pilot ring that represents the most complex hardware/firmware combos in your fleet.
• Use staged deployment (Windows Update for Business, WSUS, MECM/Intune) to minimize blast radius.
• Where KIR is provided, use it to surgically disable the specific change that caused the regression without removing the security content.

---

How to apply Microsoft’s fix now​

• Check Windows Update (Settings → Windows Update) — Microsoft has begun rolling the OOB packages through Windows Update channels. The KB pages list availability and OS build numbers.
• For controlled deployments, fetch the OOB packages from the Microsoft Update Catalog and import them into WSUS/MECM/Intune as required. The KB pages include guidance for enterprise deployment.
• After installing:
• Validate that the system no longer restarts when instructed to shut down (test on representative devices).
• Confirm Remote Desktop sign‑in flows by testing AVD/Cloud PC or Windows App client sign‑ins in pilot groups.
• If you rely on automated rollback for testing, remember that the OOB packages include a servicing‑stack update and LCU combined; SSUs are not always removable and can affect uninstall semantics. Plan rollbacks accordingly.

---

Why this happened: a technical anatomy​

The failures are not random UI bugs — they are servicing orchestration and security‑platform interaction issues:

• Modern cumulative updates perform multi‑phase servicing: some changes are staged while the OS runs, and other pieces are committed during offline phases that occur during shutdown/restart. The system must preserve the user’s final power intent (shutdown vs. restart vs. hibernate) across that sequence. If that intent is lost or misinterpreted, the servicing stack may choose a safe fallback (restart).
• System Guard Secure Launch inserts virtualization‑based protections and early boot measurements. Those protections change the boot chain and the paths an update must traverse; if the servicing stack’s offline‑commit logic didn’t correctly persist power intent across the Secure Launch boundary, the device can restart instead of powering off. In short: a fragile intersection between firmware/boot‑time virtualization and update commit orchestration produced the regression.
• The Remote Desktop authentication failures likely stemmed from an authentication flow change or regression in the January rollup that affected credential prompts across multiple client surfaces; Microsoft’s rapid OOB patches focused on restoring the affected authentication steps.

These are the kinds of cross‑layer interactions that are difficult to exhaustively test across the vast matrix of OEM firmware, drivers, third‑party agents, and enterprise policies that exist in the real world — which is why staged rollouts and pilot testing remain essential.

---

Critical analysis — strengths, risks, and what this episode tells IT teams​

Notable strengths in Microsoft’s response​

• Microsoft identified the regressions quickly and issued targeted out‑of‑band patches within days rather than weeks — an appropriate use of OOB releases for high‑impact regressions. The KBs are explicit about affected builds and include SSUs and rollback guidance for enterprise deployments.
• The vendor documented interim mitigations (forced shutdown command, KIR artifacts, alternate AVD clients) so administrators and helpdesk staff had pragmatic, supported options to reduce immediate disruption.

Persistent risks and unresolved pain points​

• Regressions that affect power state or remote access are operationally serious. Even with quick OOB fixes, organizations that applied January updates broadly without adequate piloting faced short‑term disruption. There is also the risk that SSU‑combined packages make clean uninstalls more complex.
• The frequency of emergency patches has increased compared to historical norms. While this reflects a responsive engineering posture, it also signals that the complexity of platform servicing and the variety of managed configurations are stretching traditional QA models. Organizations should expect occasional high‑urgency patches and plan operating procedures accordingly.
• Some related issues remained under investigation at the same time (for example, Outlook Classic POP profiles hanging after January updates), reminding admins to watch multiple vendor advisories in parallel rather than treating January updates as a single, monolithic change.

Practical recommendations for IT teams​

• Preserve a strict pilot ring policy: validate updates on representative devices (firmware, drivers, security agents) before broad deployment.
• Instrument devices for observability: collect firmware versions, VBS/Secure Launch state, update payload IDs, and relevant logs so triage teams can reproduce problems and file high‑quality telemetry with vendor support.
• Use KIR where Microsoft publishes it instead of uninstalling updates when possible — KIR surgically disables problematic changes without exposing endpoints to unpatched vulnerabilities.
• Prepare helpdesk scripts that include the documented temporary mitigations (force shutdown command, AVD web fallback) and a brief checklist for triage.

---

Quick reference: commands and checks​

• Force immediate shutdown (temporary workaround)
• Open elevated Command Prompt and run:
• shutdown /s /t 0
• Save work first — this closes apps immediately.
• Verify whether KB5073455 (January 13, 2026) is installed (example for 23H2):
• DISM /online /get-packages | findstr 5073455
• Or check Settings → Windows Update → Update history.
• Confirm Secure Launch is active:
• Run msinfo32.exe → inspect Virtualization‑based Security Services Running and Virtualization‑based Security Services Configured.
• Apply OOB fixes:
• Settings → Windows Update (or use Microsoft Update Catalog / WSUS / Intune to deploy KB5077797 / KB5077744 and companion KBs). Validate in pilot ring before broad rollout.

---

Conclusion​

The January 2026 Patch Tuesday cycle exposed a brittle intersection between modern update servicing and virtualization‑based boot protections: when an update touches early‑boot or authentication flows, even a narrowly scoped regression can produce disruptive, high‑urgency failures. Microsoft’s rapid out‑of‑band releases (KB5077797, KB5077744 and companion packages) and documented mitigations bought time and remedied the two primary regressions, but the episode reinforces the need for disciplined pilot rings, better instrumentation across firmware/agent surfaces, and cautious rollout strategies for managed fleets.
For most consumer devices without Secure Launch enabled the risk was low, but organizations running Enterprise or IoT images — and any environment relying on Remote Desktop or Cloud PC access — should validate that the January OOB packages are applied and that RDP and shutdown behaviors operate as expected. Keep update testing deliberate, communicate mitigations to end users, and prefer KIR or targeted OOB packages over uninstalling security updates to maintain security posture while restoring reliability.

---

Source: News9live Can’t shut down your PC? Microsoft patches Windows 11 January bug

 

[ChatGPT]

Microsoft pushed emergency out‑of‑band Windows fixes on January 17, 2026 after its January Patch Tuesday rollup caused disruptive regressions that left some machines unable to shut down or hibernate and many users unable to sign in to Remote Desktop and Cloud PC sessions. ates — shipped as combined servicing‑stack updates (SSU) plus latest cumulative updates (LCU) and published under KB identifiers such as KB5077744 and KB5077797 — were intended to restore basic power‑state determinism and authentication flows that the January 13 security rollup inadvertently broke.

---

Background​

The second Tuesday of each month is Microsoft’s standard Patch Tuesday, when the company releases cumulative security and quality updates for Windows. On January 13, 2026 Microsoft shipped that month’s security rollups across multiple servicing channels. Within days, telemetry and community reports converged on two operationally serious regressions: a widespread Remote Desktop/Cloud PC authentication failure and a more narrowly scoped power‑state regression on Windows 11 devices running System Guard Secure Launch. Microsoft acknowledged the incidents and issued out‑of‑band (OOB) cumulative packages on January 17, 2026 to r
Why an OOB release? Out‑of‑band updates are not routine — they are emergency corrective packages used when an issue causes immediate operational pain or a potential safety/availability hazard. Microsoft’s January 17 OOB packages combine the earlier January fixes with corrective code and updated servicing stacks to ensure devices can receive and install the remediation reliably. That combined packaging has deployment implications (notably uninstall semantics) that administrators must understand before mass rollout.

---

What broke: Two distinct regressions​

Remote Desktop / Cloud PC authentication failures​

• Symptom: After the January 13 update, administrators and end users reported repeated credential prompts, immediate sign‑in failures, or aborted authentication handshakes when using Remote Desktop clients — including the modern Windows Remote Desktop App and cloud‑brokered scenarios such as Azure Virtual Desktop (AVD) and Windows 365 Cloud PC. Sessions failed to establish because the client‑side authenticationaturely.
• Scope: The authentication regression was observed across several servicing branches: Windows 11 25H2, 24H2 and 23H2 builds, multiple Windows 10 ESU channels, and several Windows Server SKUs. Because remote desktop and cloud PC access are foundational for modern hybrid work, the impact was immediate — helpdesks and managed service providers reported rapid ticket increases and availability incidents.
• Why or breaking authentication flows to managed desktops causes near‑instant business continuity issues for organizations that rely on remote access. For many IT teams, this kind of regression is high‑urgency because large user populations can lose access in minutes.
• What Microsoft documented: The January 17 OOB notes explicitly list the Remote Desktop sign‑in/authentication fix as a primary improvement in the corresponding KBs. Administrators were advised to apply the OOB packages where RDP/Cloud PC sign‑ins were failing.

Secure Launch — restart instead of shutdown / failed hibernation​

• Symptom: On some Windows 11 devices where System Guard Secure Launch was enabled, selecting Shut down or Hibernate resulted in an immediate restart instead of powering off, and hibernation could fail outright. The device might briefly appear to power off, only to return to the sign‑in screen while fans and disks reme: This regression was configuration‑dependent and primarily affected Enterprise, Education and IoT SKUs that enable Secure Launch for early‑boot hardening. Typical consumer Home and Pro machines — where Secure Launch is rarely enabled — were much less likely to encounter the issue.
• Intesoft published a deterministic workaround for immediate power‑off: run an elevated command and force shutdown — shutdown /s /t 0. This forces a power‑off but does not restore hibernation behavior. Microsoft noted there was no workaround for hibernation at the time the advisory was published.
• Why it mattered: Determine critical for imaging, scheduled maintenance, kiosk devices, and battery‑sensitive laptops. Unexpected restarts or failed hibernation can cause data loss, battery drain, and broken automation workflows.

---

The emergency fixes Microsoft shipped​

Microsoft released a set of out‑of‑band cumulative packages on January 17, 2026 that address the two primary regressions and include servicing stack updates. Key packages include:

• KB5077744 — Out‑of‑band cumulative update for Windows 11 versions 25H2 and 24H2 (OS Builds 26200.7627 and 26100.7627). Primary fix: restores Remote Desktop sign‑in/authentication flows that were disrupted by the January 13 security update. This package also includes an SSU (servicing stack update).
• KB5077797 — Out‑of‑band cumulative update for Windows 11 version 23H2 (OS Build 22631.6494). Primary fixes: resolves Remote Desktop sign‑in failures and corrects the Secure Launch restart‑on‑shutdown/hibernate regression. This package includes an SSU and is targeted at 23H2 builds where Secure Launch is likely enabled.
• Companion OOB packages for other servicing lines: KB5077796, KB5077795, KB5077793, etc., target Windows 10 ESU branches and Windows Server builds to address the Remote Desktop authentication problem in those environments. Microsoft’s KB pages confirm these packages and list their affected builds and release details.

Important deployment notes published by Microsoft:

• The OOB packages are cumulative — they include the January security fixes plus corrective code.
• Microsoft combined SSU and LCU in these installers; once the SSU portion is applied it cannot be removed by the normal wusa uninstall switch. Removing the LCU portion requires DISM with the exact package name if necessary. Administrators should plan for this servicing behavior prior to mass deployment.

---

How toted​

Start with two questions: which OS/build are you running, and is Secure Launch active?

• Check installed updates:
• Open Settings → Windows Update → Update history, or run:
• DISM: DISM /online /get-packages | findstr 5073455 (substitute the January KB for your OS channel) to see whether you installed the January 13 cumulative update.
• Check Secure Launch status:
• Run System Information (msinfo32.exe) and lmary* for virtualization‑based security entries; if System Guard / Secure Launch appears as running or configured, the feature is enabled.
• Registry check for automation: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard\Enabled = 1 indicates configured; verify actth msinfo32.
• Symptoms to watch for:
• Repeated credential prompts or immediate Remote Desktop sign‑in failures across modern RDP clients and Cloud PC connections.
• Devices that restart when selecting Shut down or fail to enter hibernation (particularly in enterprise images whenforced).
• Temporary mitigations:
• Force immediate shutdown with elevated command: shutdown /s /t 0.
• Use alternative connection paths (AVD web client or classic Remote Desktop client) if the modern Remote Desktop App is failing for Cloud PC connections until the OOB fix is applied.

---

Deployment recommendations and cautions for IT​

The January 17 OOB packages were shipped quickly for good reason, but rapid emergency fixes carry their own operational tradeoffs. Follow these best practices:

• Pilot before mass rollout. Even OOB fixes should be validated in a controlled pilot group because the packages include SSUs and can change servicing semantics.
• Prioritize affected systems. Deploy OOB packages to devices exhibiting Remote Desktop failures or the Secure Launch shutdown symptom first. Systems that show no symptoms can remain on the normal update cadence if desired.
• Be aware of SSU bundling. The combined SSU+LCU installer cannot be uninstalled via wusa.exe — removing the LCU is M if needed. Plan rollback and recovery steps accordingly.
• Use Known Issue Rollback (KIR) where offered. Microsoft may publish KIR policies or group policy downloads to mitigate a problem without installing or uninstalling updates in managed environments. Evaluate KIR as a tempon for large fleets.
• Update management controls. For WSUS/SCCM/ConfigMgr environments, add the OOB packages to pilot rings first and monitor health dashboards before wider deployment. Treat WSUS servers and update infrastructure as critical assets: ensure they are patched and isolated if necessary.
• Monitor Microsoft’s Release Health dashboard and KB pages. Microsoft’s KB pages list known issues and file information for each OOB package; use these official pages to confirm applicable builds and known side effects.

---

Technical analysis: how did this happen?​

Modern Windows is a highly integrated platform spanning firmware, early‑boot virtualization protections, kernel subsystems, authentication brokers, and cloud connection brokers. Two observations explain the class of regressions seen in January:

• Deep coupling between security hardening and power/auth subsystems. Features like System Guard Secure Launch insert virtualization‑based boundaries early in the boot sequence to protect against boot‑level tampering. Those boundaries change assuization and shutdown sequences. Small servicing changes in the kernel or servicing stack can flip a corner case into a visible failure on certain firmware/hardware permutations. The Secure Launch shutdown regression is a classic example of an edge case created by a hardened early‑boot environment interacting with updated power‑transition logic.
• Cumulative, combined servicing increases regression surface. Microsoft’s practice of shipping cumulative rollups that touch servicing stacks, authentication libraries, and telemetry agents means one monthly change can cross many subsystem boundaries. Combining Servicing Stack Updates (SSUs) with LCUs in a single installer accelerates installation reliability but also makes rollback more complex and increases the blast radius of an unintended regressft.

Strengths and limitations of Microsoft’s response:

• Strength: Microsoft moved quickly to evaluate telemetry, reproduce the failures, and issue targeted OOB fixes within four days of Patch Tuesday — a rapid response that restored access for many customers and prevented extended downtime for Cloud PC and AVD scenarios.
• Risk: Rapid OOB releases test quality assurance and real‑world staging less than the monthly cadence, potentially exposing different corner cases. The inclusion of SSUs in OOB packages complicates rollback and increases the need for careful piloting.

Where independent reporting aligns: Major outlets documented both the symptoms and Microsoft’s OOB patches, corroborating the vendor’s timeline and effects. Coverage highlighted the dual reality of improved responsiveness and the rising prevalence of emergency fixes as Windows expands in complexity. Caution about unverified or overstated cletry and reporting gave rapid visibility into affected scenarios, but aggregated impact estimates vary by outlet and by telemetry source. Exact counts of affected devices are not publicly disclosed; therefore any claim about the propores impacted should be treated cautiously until Microsoft publishes telemetry summaries or official remediation metrics. This article flags those counts as unverified where they appear in community discussion.

---

Practical checklist for administrators and power users​

• Identify: Determine whether your environment uses Secure Launch and which builds received the January 13 update. Use msinntory affected machines.
• Pilot: Apply the appropriate OOB KB to a small pilot group that includes representative hardware/firmware permutations, especially laptops and devices that enforce Secure Launch.
• Deploy: Use Update rings and phased deployments (Windows Update for Business, WSUS, SCCM/ConfigMgr) to distribute the OOB fix to affected groups first, then widen deployment after monitoring.
• Mitigate: For immediate shutdown needs, use shutdown /s /t 0. For Remote Desktop workarounds, consider web client or classic RDP client fallbacks until modern Remote Desktop App behavior is validated.
• Backup & rollback planning: Ensure you have system backups and documented procedures to remove LCUs with DISM if a rollback becomes necessary; remember SSUs combined in the package are not removable with wusa.
• Monitor: Watch Microsoft’s Release Health and KB pages for known issues and follow updates from trusted industry outlets for additional diagnostics and community workarounds.

---

Broader implications and final analysis​

The January 2026 emergency fixes illuminate a tension at the heart of modern platform management: the need to patch rapidly for security and the growing integration that makes every servicing change a cross‑cutting event. For enterprises, the implication is clear: robust update governance — pilot rings, telemetry, and rollback plans — is no longer optional. For Microsoft, the repeated need for OOB fixes suggests a continued focus on expanding test coverage, particularly around hardening features like Secure Launch and cloud‑brokered authentication flows.
Strengths displayed in this episode include Microsoft’s quick triage and targeted remediation — the company moved from issue recognition to OOB deployment in a matter of days, restoring functionality for many users. The risk is that speed can sometimes trade off with breadth of validation; combined SSU+LCU packages and OOB cadence can complicate rollback and increase operational overhead for admins. The best defensive posture is a conservative rollout strategy accompanied by clear telemetry and rollback steps.
Administrators should treat the January 17 OOB packages as high priority only for affected systems; devices that have not exhibited the issues can be staged more deliberately. The episode also underscores the need for robust monitoring of remote‑access and power‑state behaviors immediately after monthly rollouts, and for contingency procedures when a single update affects broad operational surfaces.

---

y out‑of‑band patches on January 17, 2026 restored critical Remote Desktop authentication and fixed the Secure Launch shutdown/hibernate regression for affected builds, but they also highlighted the operational complexity of modern Windows servicing. Administrators and advanced users should verify their build and configuration, pilot the OOB packages where appropriate, and apply the documented mitigations to minimize disruption. Vigilant update governance, rapid telemetry analysis, and cautious deployment remain the best safeguards against future regression-driven outages.

---

Source: thewincentral.com Emergency Windows Fixes Released After January Update Breaks Core Features - WinCentral