WinRE USB Input Regression in Windows 11 KB5066835 (October 2025)

A Windows 11 security update released in mid‑October 2025 (KB5066835, OS build 26100.6899) has introduced a serious regression: USB keyboards and mice can become completely unresponsive inside the Windows Recovery Environment (WinRE), leaving users unable to navigate recovery menus when they need them most.

Background​

Microsoft shipped the October cumulative security update (KB5066835) on October 14, 2025. Within days, field reports and vendor advisories began to surface describing a consistent failure: affected machines display the normal WinRE tiles and menus at boot, but USB input devices – including USB‑A, USB‑C, and USB‑attached wireless receivers – do not register any input in that environment. Critically, the same input devices function normally once the full Windows session starts, isolating the fault to the WinRE / Safe OS execution context rather than to general driver or hardware failure.
Microsoft acknowledged the problem publicly and marked the issue as confirmed for Windows 11 versions 25H2 and 24H2, and for Windows Server 2025, stating that an out‑of‑band fix was being prepared. Until that fix arrives, Microsoft recommends creating external recovery media and exercising caution around deployment of KB5066835, especially in environments that rely on WinRE for offline repair and troubleshooting.

---

Why this matters: the role of WinRE​

WinRE is the default, pre‑boot rescue environment for Windows. It is the toolset used to:

• Repair startup failures using Startup Repair
• Access Safe Mode and advanced startup options
• Restore system images or apply system restores
• Run an offline Command Prompt for manual repairs
• Reset Windows while preserving or removing files

Because WinRE runs independently of the full Windows stack, it uses a minimal set of drivers called the Safe OS. That lean driver set is purposely restricted to reduce complexity and ensure the environment can boot even when the main OS cannot. The downside: any regression in the Safe OS image or its driver list can disable critical hardware that users assume will always be available for rescue.
The current bug effectively severs the primary phone line between the user and WinRE when USB devices are the only available input method. For modern laptops and desktops that ship without legacy PS/2 ports, that can mean locking the owner out of device recovery options entirely.

---

Scope and symptoms​

Platforms affected​

• Windows 11, version 25H2
• Windows 11, version 24H2
• Windows Server 2025

Typical user experience​

• The system boots to the WinRE tiles (Choose an option → Troubleshoot → Advanced options), but the cursor is invisible and keystrokes have no effect.
• USB keyboard and mouse work normally while Windows is running; the failure appears only inside WinRE.
• Systems with legacy PS/2 keyboard and mouse typically retain WinRE input functionality because PS/2 devices are handled by a different legacy stack that isn’t impacted by this regression.
• Systems that rely exclusively on USB‑C input (many modern thin laptops and mini‑PCs) are particularly vulnerable because they often lack any legacy fallback.

Common patterns observed​

• Reproducible immediately after installing KB5066835.
• Affects wide range of hardware (consumer laptops, OEM desktops, mini‑PCs).
• Field reports show consistent reproduction across different brands and chipsets, suggesting the problem resides in the WinRE image or Safe OS driver set deployed by the update rather than a single vendor driver.

---

Immediate risks and real‑world impact​

This is not a benign annoyance. The bug amplifies existing recovery risk in several ways:

• Loss of access to built‑in recovery tools: When WinRE is unresponsive, users cannot run Startup Repair, System Restore, Deploy Image Servicing and Management (DISM) offline fixes, or boot to Safe Mode via the recovery menus.
• Higher support burden for IT teams: Help desks and on‑site technicians now need alternate recovery workflows for impacted clients. That means longer downtime, more physical interventions, and more workarounds.
• Bricking potential for inexperienced users: Users who rely on WinRE to repair a non‑booting PC may be unable to recover without technical help; some may attempt risky fixes like reinstalling Windows or replacing partition images without adequate backups.
• Remote/managed repair is harder: Organizations that depend on unattended remote recovery workflows — or that send technicians with only USB‑connected tools — may face blocked recovery operations.
• Security vs recoverability trade‑off: Rolling back a security update to restore WinRE input reintroduces the original security exposure patch KB5066835 was meant to address. That trade‑off is painful for security‑sensitive environments.

---

What Microsoft has said and the current status​

Microsoft has publicly confirmed the issue and listed it in the Windows release health / known issues page. Their advisory acknowledges that the problem began after the October 14, 2025 update and that engineers were working on a fix. The company advised creating external recovery media as a mitigation and indicated that an out‑of‑band fix would be released in the coming days.
While Microsoft’s commitment to a prompt patch is reassuring, the window between patch release and field deployment can leave both home users and enterprise administrators exposed. Enterprises should monitor Windows Update channels closely for the out‑of‑band remediation and test it in a controlled environment before broad rollouts.

---

Practical workarounds and mitigations​

There are several mitigation paths of varying risk and complexity. Choose the option that best fits your technical comfort level and operational constraints.

1. Create external recovery media (strongly recommended)​

Creating a bootable Windows installation or recovery drive is the safest near‑term mitigation. External media boots its own WinRE image and is independent of the internal disk’s WinRE image, so USB device input is typically available from the installer/recovery environment.
Steps (high level):

• Use a healthy Windows PC to create a recovery or installation USB:
• Use the built‑in Create a recovery drive tool (Recovery → Create a recovery drive).
• Or use the Media Creation Tool / Windows installation ISO and Rufus to build a bootable USB installer.
• Boot the affected PC from the USB (use the vendor boot menu or change boot order in UEFI).
• Access repair options from the external media to run repairs or restore system state.

Why this helps:

• External media supplies a fresh WinRE/Safe OS image that is not modified by the problematic cumulative update on the internal disk.
• It provides a reliable path to offline repairs and command‑line tools.

Caveats:

• If your system can’t boot to USB due to firmware config, you may need to enable legacy/UEFI USB boot or change Secure Boot settings.
• Some vendors use proprietary recovery partitions or firmware; test the boot process before an emergency occurs.

2. Use PS/2 peripherals where available​

If your machine has legacy PS/2 keyboard or mouse ports, those devices remain functional inside WinRE for affected systems. This is a narrow workaround because most modern laptops and many mini‑PCs lack PS/2 support.

3. Roll back the update​

If KB5066835 is already installed and you need immediate WinRE access, uninstalling the update can restore the previous WinRE image. You can uninstall updates from within Windows (Settings → Windows Update → Update history → Uninstall updates) or use the command line (wusa /uninstall /kb:5066835).
Caveats:

• Rolling back a security update is a trade‑off: you restore recoverability but lose the security fixes that the update provided.
• Some managed environments block uninstall of certain mandatory updates; check policy and compliance requirements first.

4. Replace the WinRE image (advanced, risky)​

Technically skilled users and administrators can manually replace the internal WinRE image (winre.wim) with a safe copy from a prior Windows image or a Windows ISO. The process typically involves:

• Booting from external installation media.
• Mounting the system partition and locating the WinRE image (usually at \Windows\System32\Recovery\Winre.wim or on a separate recovery partition).
• Replacing the updated winre.wim with a known good copy extracted from a previous Windows ISO.
• Re‑enabling WinRE using reagentc /enable.

This restores a functioning WinRE but has risks:

• Mistakes can render the system unbootable.
• OEM customizations and recovery partitions may be overwritten.
• The process may violate corporate change controls.

Only advanced users or technicians should attempt this approach, and it should be tested before applying in production.

---

Step‑by‑step: Create a Windows recovery USB (detailed)​

• On a working Windows PC, insert a USB drive (8 GB minimum recommended).
• Search for Create a recovery drive in Windows and run it as an administrator.
• If prompted, choose to back up system files to the recovery drive (this option makes the drive larger but more capable).
• Select the correct USB drive and proceed with the creation process.
• When complete, safely eject the USB and test it by booting another machine (or the target PC) using the vendor boot key to ensure it boots to the recovery environment.

Alternative: Download the Windows installation ISO from Microsoft and use the Media Creation Tool to make a bootable installer. That installer also provides repair options when booted.
Testing your recovery media now — before you encounter a system fault — is essential. A tested external recovery drive eliminates most of the negative impact from the WinRE regression.

---

Guidance for IT administrators and managed environments​

• Pause or defer deployment of KB5066835 across sensitive endpoints if you have not yet deployed it to broad production. Evaluate the update in a controlled pilot group first.
• Prepare recovery media for all critical assets and consider distributing bootable USB sticks to field technicians and key users.
• Update support playbooks to include external media and alternate recovery procedures; train frontline staff on the manual replacement of winre.wim only if your team has the necessary expertise.
• Document rollback policies and identify windows where rollback of KB5066835 is acceptable from a security posture perspective.
• Monitor vendor and Microsoft channels for the out‑of‑band fix and schedule rapid testing and deployment once Microsoft releases the patch.
• Inventory devices that lack PS/2 fallback and prioritize those machines for manual intervention or conservative update scheduling.
• Communicate to users the risks and provide straightforward instructions for creating a recovery USB or contacting support for assistance.

---

Technical analysis: what likely went wrong​

The failure pattern isolates the issue to the Safe OS / WinRE environment. Several technical explanations are plausible:

• WinRE image update regression: The October servicing wave often includes companion updates for the WinRE image (the Safe OS). If that dynamic image update omitted or changed the USB input driver stack, USB devices may not be bound during WinRE init.
• Driver packaging/compatibility: WinRE uses a minimal driver set. A driver dependency or incorrectly packaged driver for USB host controllers could fail to load in Safe OS even though the full OS can initialize it.
• Enumeration timing or controller initialization: USB controllers on newer platforms (USB 3.1/USB‑C) sometimes require specific initialization sequences. If the Safe OS startup path changed timing or power sequencing, devices might not be enumerated.
• Secure Boot/driver signing interplay: Changes to the driver manifest or signing requirements for the WinRE image could theoretically block loading of certain drivers in the minimal environment, though this is less likely given the widespread hardware impact.

Without internal telemetry or a published root‑cause analysis from Microsoft, these remain well‑grounded technical hypotheses rather than confirmed facts. The presence of a Microsoft‑listed fix and the observed rapid reproduction across platforms suggest the regression was introduced in the WinRE/Safe OS image delivered alongside the cumulative update.

---

Risk assessment and longer‑term considerations​

This bug highlights a broader tension in modern OS maintenance: the balance between rapidly delivering security fixes and ensuring that the minimal recovery environment remains robust across the vast diversity of hardware drivers and firmware configurations.
Key longer‑term risks:

• Erosion of trust in automatic patching: Incidents that break recovery tools may encourage users and enterprises to delay or disable automatic updates — a behavior that increases exposure to unpatched vulnerabilities.
• Operational overhead: Repeated regressions require help desks to maintain ancillary recovery media and complex playbooks, increasing support costs.
• Supply chain complexity: As OEMs and Microsoft jointly ship firmware, drivers, and recovery images, pinpointing responsibility for regressions gets harder. Enterprises must increase validation of updates across real device fleets.

Recommended strategic actions:

• Prioritize creation and distribution of standardized recovery media across device fleets.
• Increase pre‑deployment testing on representative hardware images that mimic the variety of USB controller topologies in the field.
• Maintain a baseline WinRE image repository that can be used to restore devices that encounter Safe OS failures.

---

What to do right now — quick checklist​

• If KB5066835 is not yet installed on critical systems, consider delaying installation until Microsoft’s patch is available and tested.
• Immediately create external recovery media for all important PCs and servers.
• For currently impacted machines, attempt recovery with external installation media; if that’s not possible, evaluate rollback of the update from within Windows.
• Avoid risky manual edits to recovery partitions unless performed by experienced technicians and after backups.
• Keep users informed and provide clear instructions for contacting support if they encounter non‑booting systems.

---

Why this incident should change how you prepare​

Modern PCs increasingly rely on USB input and boot‑time subsystems that can be fragile when updates touch the minimal boot environment. This incident underscores why redundant recovery paths matter: an external installer USB, a documented rollback procedure, and trained support staff are not optional extras — they are essential components of a resilient patching strategy.
Proactive measures — recovery USB drives, tested rollback procedures, and a small library of known‑good WinRE images — will reduce downtime and avoid panicked emergency responses when a future update introduces an unforeseen regression.

---

Final analysis and outlook​

The Windows 11 KB5066835 WinRE regression is an important reminder that the recovery environment is as critical as the main OS itself. When tools meant to rescue a broken machine fail, the consequences ripple across individual users and enterprise operations alike.
Microsoft’s quick acknowledgement and pledge to release an out‑of‑band fix is the correct immediate response. However, organizations and power users should not rely solely on vendor timelines. Short‑term actions — creating recovery media, delaying non‑critical deployments, and preparing rollback plans — are practical and necessary.
This episode should also prompt a broader discussion about test coverage for minimal environments and firmware diversity testing in the deployment pipeline. Until update validation increases to match the complexity of modern hardware, prudent administrators must assume some updates will need contingency plans and prepare accordingly.
For now, the core message is simple and urgent: if you use Windows 11, make a recovery USB now and audit your update deployment plan. That single action will mitigate most of the current risk while Microsoft works to deliver the patch that restores reliable WinRE functionality.

---

Source: ProPakistani This Alarming Windows 11 Issue Stops Your Mouse and Keyboard from Working

 

[ChatGPT]

Microsoft’s October 14, 2025 cumulative update for Windows 11 (KB5066835) has introduced a high‑severity regression that renders the Windows Recovery Environment (WinRE) non‑interactive on a subset of systems — USB keyboards and mice stop working when the system boots into recovery, leaving users and administrators unable to access built‑in repair tools until Microsoft issues a fix.

---

Background / Overview​

Windows Recovery Environment (WinRE) is a small, self‑contained Safe OS image shipped with Windows that provides critical recovery features: Startup Repair, Safe Mode, System Restore, Command Prompt, Reset this PC and access to UEFI/firmware settings. Because WinRE runs outside the full desktop it deliberately contains a trimmed driver set and a reduced runtime footprint. That design keeps the image small and easier to maintain, but it also makes WinRE sensitive to driver and packaging changes — if WinRE’s bundled drivers don’t match the machine’s USB host controller variant, USB input can fail inside recovery even when it works normally under the main OS.
On October 14, 2025 Microsoft shipped the October monthly rollup for Windows 11 as KB5066835 (targeting OS builds 26100.6899 and 26200.6899). Within days multiple community reports showed that, after installing the update, invoking WinRE produced the recovery tiles but the UI would not accept keyboard or mouse input — no visible cursor and no response to key presses — while the same USB devices continued to function normally during a standard desktop session. Microsoft acknowledged the behavior on its Release Health / Known Issues dashboard and marked the defect as “Confirmed.”
This article synthesizes the facts, validates the timeline against Microsoft’s documentation and independent reporting, analyzes the technical root causes and operational risks, and provides practical guidance for both home users and enterprise IT teams until an official fix is delivered.

---

What happened — timeline and confirmed facts​

• October 14, 2025 — Microsoft publishes KB5066835 for Windows 11 as the October cumulative update.
• Within hours–days — Users across consumer and enterprise hardware report the same symptom: WinRE shows the recovery tiles but is non‑interactive; USB keyboards and mice do not work inside WinRE while they continue to work in the full Windows session.
• October 17–18, 2025 — Microsoft updates the Release Health dashboard and confirms the issue is under investigation and that remediation is planned. Independent outlets and support forums reproduce and document the failure.

These points are supported by Microsoft’s official update notes and public forum threads where users and engineers have replicated the failure.

---

Technical anatomy — why WinRE is fragile and why this breaks recovery​

WinRE vs. full Windows: a smaller runtime with fewer drivers​

WinRE is intentionally lightweight. It ships a compact driver set sufficient to access common storage, display, and input hardware, but it does not carry the full breadth of drivers that the main Windows desktop loads. That makes WinRE reliable in many scenarios, but also vulnerable if a dynamic update replaces or modifies WinRE’s driver set in a way that omits or misconfigures the USB host controller driver variant required for certain hardware. In short: a driver that exists and works in the full OS may be absent or incompatible inside WinRE.

Safe OS dynamic updates and packaging complexity​

Microsoft sometimes refreshes the WinRE / Safe OS image via Safe OS dynamic updates or bundles Safe OS changes with servicing packages. The October servicing wave delivered a combined Servicing Stack Update (SSU) plus the Latest Cumulative Update (LCU) in certain channels; when SSU and LCU are combined the package and rollback semantics change and can complicate remediation. In other words, uninstalling the cumulative update alone may not restore the prior WinRE image, which reduces the effectiveness of “just roll it back” for quickly undoing the regression. Microsoft’s documentation has repeatedly explained that combined SSU+LCU packages cannot be rolled back via the simple wusa /uninstall trick.

Likely technical cause​

Early technical assessments — corroborated by independent reproductions — indicate the update refreshed WinRE / Safe OS content with a driver set that fails to initialize certain USB host controller variants in that restricted environment. Because the full desktop loads a broader, richer driver set, USB input continues to work there; the failure is isolated to the pre‑boot Safe OS context. That pattern is consistent with community reproductions posted to Microsoft Q&A and technical forums.

---

Scope, impact and risk matrix​

Who is affected​

• Windows 11 devices on 24H2 and 25H2 that received KB5066835 (OS builds 26100.6899 / 26200.6899).
• Systems that rely exclusively on USB input (many modern laptops and mini‑PCs with no PS/2 fallback). Reports highlight devices with only USB‑C or USB‑3 ports as especially problematic.
• Home users who may rarely use WinRE but depend on it for recovery, and IT departments that rely on local recovery tools during incident response.

Operational impact​

• Blocked recovery: A non‑interactive WinRE prevents using built‑in tools like Startup Repair, System Restore, Reset this PC, or Command Prompt — forcing users to rely on external recovery media or full OS reinstallation in many scenarios.
• Enterprise risk: For managed fleets, inability to use local recovery paths increases mean time to repair (MTTR), may require physical media distribution, and complicates remote troubleshooting. Enterprises that use image‑based or on‑device recovery workflows are most affected.

Severity assessment​

This is a high‑severity servicing regression because it impairs the repair path rather than a single application. The OS remains functional in normal use, but the inability to reach recovery tools during boot failures or to perform offline repairs raises real data‑availability and operational continuity concerns.

---

What Microsoft has said and what to expect next​

Microsoft’s KB page for the October 14, 2025 update lists the package and its build numbers and the Release Health dashboard documents a confirmed issue and ongoing investigation. Microsoft has indicated an out‑of‑band (emergency) update or targeted Known Issue Rollback (KIR) will be used to remediate affected devices. Known Issue Rollback is Microsoft’s standard mechanism to disable a problematic change without removing the security content of updates, and it is commonly used in these scenarios to reduce disruption while preserving protection.

---

Practical guidance — immediate mitigations and conservative steps​

Until Microsoft publishes the fix, affected users should follow conservative, low‑risk steps. These steps are grouped for home users and for enterprise IT.

For home users and power users​

• Pause updates temporarily if you have not yet installed KB5066835. Use Settings > Windows Update > Pause updates to delay automatic installation until Microsoft confirms remediation.
• If you already installed KB5066835 and rely on WinRE (for example, you perform frequent offline repairs or dual‑boot scenarios), avoid intentionally booting into WinRE for tasks that require USB input until Microsoft’s fix is installed.
• If you must use recovery, prepare external recovery media: build a Windows 11 USB recovery drive or have a full Windows 11 ISO and use it to boot into WinPE / recovery tools. External media will bypass the on‑device WinRE image and provide the required input drivers in the recovery environment.

For IT teams and enterprise admins​

• Identify at‑risk devices in inventory (Windows 11 24H2 / 25H2, builds 26100.6899 / 26200.6899). Use management tools to query installed KBs and OS builds.
• Deploy Known Issue Rollback (KIR) where Microsoft provides a policy MSI or enable KIR via Windows Update (consumer devices will typically receive KIR automatically). Use Group Policy and enterprise management to apply KIR to managed fleets as described in Microsoft guidance.
• Prepare external recovery methods: ensure imaging servers, WinPE boot media, or Windows PE/USB recovery tools are available and validated. Update your runbooks to use external media for offline troubleshooting until the fix is confirmed.
• Avoid uninstalling the combined package using wusa.exe — combined SSU+LCU packages contain the Servicing Stack Update (SSU) and cannot be fully removed by the legacy uninstall method. If you must try to remove the LCU, use DISM /Remove‑Package to remove the LCU portion, and proceed only with validated test systems. Microsoft documents the caveat that SSU elements remain after uninstalling the combined package, complicating straightforward rollback.

---

Workarounds reported in the community — risk & complexity​

Several community workarounds appeared soon after the regression surfaced. These range from safe, recommended steps to complex manual manipulations that carry risk.

• Use external USB recovery media (recommended and low risk). Boot from a Windows 11 installation USB or WinPE stick to access a recovery shell that contains a broader driver set.
• Replace the winre.wim image manually with a previously known good image from an earlier Windows 11 ISO and re‑enable WinRE via reagentc. This is possible but advanced: it requires extracting a historic winre.wim from media, using reagentc /disable, copying the replacement image into the WinRE partition, and then reagentc /enable. Mistakes here can leave systems without a functioning recovery image or unbootable. This is a last‑resort action for experienced technicians and should be tested on non‑production devices first.

Caution: manual replacement of winre.wim or tinkering with WinRE partitions is not a safe step for casual users. If you must do this, ensure full disk backups and a validated recovery plan are in place. Community posts document both successful manual restores and cases where incorrect manipulation increased repair complexity.

---

Why rollback isn’t always a silver bullet​

Because the October cumulative bundled an updated servicing stack in some configurations, simply uninstalling the cumulative update via the Settings app or wusa.exe may not restore the prior Safe OS image. Microsoft’s update guidance repeatedly notes that when SSU is combined with an LCU, the SSU component cannot be removed using the legacy wusa /uninstall method; DISM may be required to remove the LCU package but SSU remains. That nuance is important for IT teams planning remediation: a straightforward “uninstall KB and reboot” may not recover WinRE behavior.

---

How this should change update discipline going forward​

• Re‑emphasize staged rollouts: This incident underlines why organizations should pilot cumulative patches on a representative test ring that includes devices with USB‑only input before deploying broadly.
• Expand WinRE testing in automation: Automated deployment pipelines and QA should validate not only the full desktop experience but also the WinRE / Safe OS environment across a matrix of USB host controllers and vendor platforms.
• Improve communications: Microsoft’s timely release health entry is appropriate; enterprises expect actionable KIR MSI files and clear rollback guidance for combined SSU scenarios.

---

What we verified and what remains unverified​

Verified facts (cross‑checked):

• The October 14, 2025 cumulative update is KB5066835 for Windows 11 and targets OS builds 26100.6899 (24H2) and 26200.6899 (25H2). This is documented on Microsoft’s update page.
• Multiple independent reproductions and community reports confirm USB input failure inside WinRE after the update; Microsoft listed the issue on Release Health as confirmed and under investigation.
• Known Issue Rollback (KIR) is the documented mechanism Microsoft uses to mitigate regressions without removing essential security updates; enterprises can deploy KIR via Group Policy.

Claims requiring caution:

• Reports naming specific companion Safe OS package IDs (for example, KB identifiers for Safe OS dynamic updates) have circulated in community threads. Those companion IDs are plausible but vary by device and channel; they are reported in community logs and technician writeups but should be treated as provisional until Microsoft publishes a specific Safe OS package KB in the official update notes. Treat such IDs as reported by users/technicians rather than vendor‑published facts unless confirmed in Microsoft’s KB.

---

Step‑by‑step checklist for admins (actionable)​

• Run an inventory query for machines with OS build 26100.6899 / 26200.6899 and with KB5066835 installed.
• Pause or defer automatic updates for at‑risk groups until a fix is released.
• Distribute validated Windows PE / recovery USB media across helpdesk teams. Verify media boots and that wired USB keyboards/mice function in the recovery environment.
• If Microsoft publishes a KIR, plan and deploy the KIR MSI via Group Policy for managed systems. Reboot devices after KIR application as documented.
• Avoid using wusa.exe to uninstall combined SSU+LCU packages; if rollback is required and tested, prefer DISM /Remove‑Package strategies executed only after testing on non‑production systems.

---

Final analysis — strengths, weaknesses and systemic risks​

Strengths

• Microsoft’s response was timely: the company updated its Release Health dashboard and signalled a remediation path quickly after substantial community reporting, which is the right operational posture for a servicing regression of this nature.
• The existence of Known Issue Rollback and enterprise KIR tooling provides a viable mitigation path that allows devices to remain patched for security while disabling the specific regression.

Weaknesses / Risks

• The root cause — a mismatched driver set inside WinRE — underscores a testing gap: Safe OS environments may not be tested thoroughly across the broad diversity of USB host controllers in the hardware ecosystem. That increases the risk that future servicing waves will produce similar regressions.
• Combined SSU+LCU packaging complicates rollback. For helpdesk teams used to “uninstall the KB” as a fix, the inability to fully remove the SSU via wusa.exe adds operational friction and potential for missteps.
• Users who rarely prepare external recovery media are exposed: when WinRE fails, lack of a bootable USB recovery drive can force a full OS reinstall or a time‑consuming device rebuild.

Systemic risk

• Regressions in recovery tools are fundamentally more dangerous than regressions in optional features because they impair the ability to repair systems in the field. Organizations should treat WinRE regressions as a higher escalation priority than a browser or UI glitch.

---

Conclusion​

The October 14, 2025 Windows 11 cumulative update, KB5066835, created a tangible and dangerous regression by preventing USB input inside the Windows Recovery Environment on certain machines. Microsoft has acknowledged the problem and the recommended mitigation path — Known Issue Rollback or an out‑of‑band update — is in motion. In the interim, the safest course for most users is to pause the update if it hasn’t been installed, prepare external recovery media, and for IT teams to apply KIR policies and verified recovery procedures. The incident is a reminder that servicing updates must be validated not just for the full desktop but also for the compact Safe OS images that devices depend on during recovery.

---

---

Source: htxt.co.za Windows 11 has a big problem caused by latest update - Hypertext

 

[ChatGPT]

Microsoft’s October cumulative for Windows 11 (KB5066835) has produced a high‑severity regression: after installing the update, many systems running Windows 11 (24H2 and 25H2) and Windows Server 2025 report that USB keyboards and mice stop working inside the Windows Recovery Environment (WinRE), leaving the recovery UI non‑interactive while the same USB devices continue to work normally in the full Windows session.

Background​

WinRE is the lightweight, separate “Safe OS” image Windows boots into when recovery or offline repair is required. It hosts tools such as Startup Repair, Safe Mode, Reset this PC, System Restore, and a command prompt. WinRE intentionally carries a reduced driver set and minimal services to maximize the chances it will boot when the full OS cannot. That design trade‑off is precisely why a small regression inside the Safe OS image can have outsized operational impact — if WinRE’s trimmed driver set lacks the correct USB host controller driver for a machine, USB peripherals that work in the main OS will appear dead in recovery mode.
Microsoft’s release‑health advisory confirms the problem: KB5066835 (published October 14, 2025) is associated with a WinRE input regression that Microsoft marked as Confirmed on October 17, 2025, and said engineers were working on a fix to be released “in the coming days.” The advisory lists affected platforms as Windows 11 versions 24H2 and 25H2 and Windows Server 2025.

---

What happened — concise timeline​

• October 14, 2025: Microsoft ships the October 2025 cumulative update for Windows 11 as KB5066835 (delivering OS builds such as 26100.6899 and 26200.6899 depending on branch).
• October 15–17, 2025: Multiple independent community reports and lab reproductions emerge: WinRE displays its normal recovery tiles but does not accept USB keyboard or mouse input — no cursor, no keystrokes — while those same peripherals function normally once Windows boots to the desktop.
• October 17, 2025: Microsoft adds the USB input problem to its Windows Release Health / Known Issues dashboard and marks the issue Confirmed, promising an imminent solution.

This timeline — update release, rapid community reproductions, vendor acknowledgement — is fast and typical for high‑visibility servicing regressions. The immediate operational effect is severe: built‑in recovery options can become unusable on many machines, particularly newer devices with only USB‑C or USB‑A input and no PS/2 fallback.

---

Why this matters: WinRE is the OS safety net​

WinRE is not a convenience; it is a last‑resort toolkit. When WinRE is non‑interactive:

• Users cannot access Safe Mode, Startup Repair, or Reset this PC from the local device.
• Firmware/UEFI entry paths that rely on USB keyboards may be unreachable on modern USB‑only devices.
• Enterprise helpdesks lose a rapid on‑device remediation path, increasing mean time to resolution and elevating the need for external media or full reimages.
• Home users without spare USB install media or second machines can be locked out of local recovery flows.

The regression therefore converts a routine security servicing cycle into a potentially availability‑critical incident. Community evidence and Microsoft’s advisory both point to a Safe OS/WinRE image change or driver mismatch as the proximate cause.

---

Technical anatomy — likely root causes (and what is not confirmed)​

WinRE runs from a compact WIM image (commonly winre.wim) with a minimal driver set. There are two non‑exclusive technical vectors consistent with the observed behavior:

• Safe OS image/driver mismatch: a WinRE or Safe OS package installed during the October servicing cycle may have been built without the correct USB host controller (xHCI) driver variants for some hardware. Because WinRE’s driver set is intentionally small, a missing or incorrect xHCI driver prevents device initialization in WinRE even when the full Windows session loads the desktop drivers successfully. Community recoveries that replaced winre.wim with an older known‑good copy often restored input, which supports this vector.
• Packaging and rollback semantics: Microsoft frequently deploys combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) packages. When Safe OS changes are applied as part of that cycle, rollback semantics can be complex — uninstalling the LCU may not reliably restore a previous Safe OS image on every device. That complicates fleet rollbacks and may slow remediation for administrated environments.

What is not yet confirmed: Microsoft has not (as of the last advisory update) published a single‑file root cause or named a vendor driver or OEM firmware as the trigger. Community tests strongly suggest a Safe OS image mismatch, but definitive attribution requires Microsoft’s post‑mortem or an OEM statement. Until Microsoft publishes the technical post‑mortem, any specific blame of a driver file or OEM firmware should be treated as speculative.

---

How the bug presents and real‑world impact​

Typical symptom pattern observed across community reports and lab reproductions:

• WinRE boots and displays the standard tile UI (Choose an option → Troubleshoot → Advanced options).
• The mouse cursor is invisible and keyboard input is ignored inside WinRE.
• The same USB keyboard/mouse work normally in the fully booted Windows desktop.
• Systems that still accept PS/2 input are not affected in WinRE because PS/2 uses the legacy stack.
• Devices that lack legacy input (many ultrabooks, tablets with keyboard docks, USB‑only desktop builds) lose their only method to interact with WinRE.

Real‑world consequences include inability to run on‑device resets, difficulty entering Safe Mode, and blocked firmware access flows. For enterprises with remote or deskless endpoints, the issue increases recovery time and may necessitate shipping replacement hardware or performing image restores using external boot media.

---

Immediate mitigations and safe workarounds​

Until Microsoft publishes and validates a fix, the following measures materially reduce operational risk. These are conservative, practical actions for both home users and IT teams.

• Create validated external recovery media now:
• Build a bootable Windows 11 installation USB or a WinPE/WinRE USB stick and verify it boots the target hardware and accepts USB input. This provides a reliable out‑of‑band recovery path if WinRE is non‑interactive.
• Inventory and back up winre.wim images:
• Extract the current winre.wim from the recovery partition and keep a checksummed copy per golden image/hardware profile. Having a known‑good winre.wim enables local restoration if Safe OS injection fails. Community reproductions show replacing an affected winre.wim with a known‑good one can restore WinRE input.
• Pause broad deployment:
• For production fleets or recovery‑critical endpoints, place a temporary hold on deploying KB5066835 broadly until Microsoft’s fix arrives and is validated in a pilot ring. Use phased rollouts to limit blast radius.
• Practice external recovery flows:
• Verify BitLocker keys are escrowed and accessible.
• Confirm external USB media boots and provides access to the system’s drive.
• Test reagentc /info and reagentc /enable on lab devices to confirm WinRE registration and location.
• If a device is already stuck in WinRE with no USB input:
• Use external install media to boot and run diagnostics or to replace winre.wim from a known‑good source inside the mounted Windows image. Community posts describe extracting winre.wim from an install.wim in a matching ISO as an effective recovery for affected machines.

Important safety note: replacing winre.wim or manipulating the recovery partition is an advanced operation. Administrators should follow documented procedures, back up existing files, and avoid ad‑hoc instructions to non‑technical users. Prefer vendor hotfixes or Microsoft’s Known Issue Rollback (KIR) where available.

---

Enterprise guidance: risk assessment and remediation playbook​

For IT operations and endpoint management teams, the event exposes process and tooling gaps. Recommended enterprise playbook:

• Pause automatic deployment of KB5066835 to rings that contain critical or remote endpoints.
• Create a pilot group that mirrors the production hardware mix (ensure USB‑only devices are included) and validate Microsoft's incoming fix before any broad rollout.
• Maintain checksummed, golden winre.wim images for each hardware profile and store them in the organization’s image repository.
• Update incident runbooks to include:
• Steps to boot WinPE/installation media.
• Commands to extract/replace winre.wim from install.wim.
• Procedures to recover BitLocker keys and re‑enable WinRE.
• Communicate clearly to helpdesk staff and frontline technicians: use external media, avoid risky local edits unless trained, and escalate to imaging teams for winre.wim replacement.
• Track Microsoft’s Release Health and Update Catalog for the out‑of‑band hotfix or a KIR announcement. Microsoft’s dashboard is the authoritative source for status changes and fixes.

The update also highlights the importance of explicit recovery testing in pre‑production validation matrices: recovery flows must be first‑class acceptance criteria for any servicing change that touches Safe OS or WinRE content.

---

Why this is not merely an annoyance — systemic implications​

This regression exposes three systemic risks that deserve attention:

• Fragility of minimal pre‑boot images: WinRE’s trimmed driver surface is a reliability optimization, but it increases the chance that a small packaging or driver mismatch will disable critical functionality.
• Packaging complexity and rollback difficulty: combined SSU+LCU packages and dynamic Safe OS updates complicate clean rollback paths. In some configurations, uninstalling an LCU does not revert an updated Safe OS image, leaving administrators with limited in‑place remediation options.
• Test coverage gaps: traditional update validation frequently focuses on desktop scenarios. This incident underscores the need to validate recovery scenarios — including WinRE interactivity across hardware permutations — as part of regular staging and pilot testing.

Taken together, these concerns argue for elevating recovery workflows to the same priority level as functional and security testing during update validation.

---

Historical context — déjà vu with USB support​

The symptom has an echo from the Windows 95 era: early OS support for USB often outpaced BIOS and firmware support, leaving users unable to access firmware menus or pre‑OS options without a legacy PS/2 keyboard. That historical comparison is apt: when the pre‑boot environment and firmware do not align with the OS’s device initialization, users can be left locked out of recovery paths. The difference today is scale and complexity — modern servicing pipelines can deliver Safe OS updates to millions of endpoints within days, and the reach of a regression is therefore far greater.

---

What to watch next​

• Microsoft Release Health / Known Issues dashboard: authoritative status updates on remediation and timing.
• Microsoft Update Catalog and any out‑of‑band hotfix packages or Known Issue Rollback (KIR) entries specific to KB5066835 or the associated Safe OS dynamic updates.
• OEM advisories that may provide vendor‑specific guidance if particular USB host controllers or firmware variants are implicated. Community reports indicate varied hardware impact, so OEM guidance may be important for some device families.

If Microsoft publishes a post‑mortem, it should be reviewed for the exact remediation path (a KIR vs. an out‑of‑band hotfix vs. a Safe OS package update) because each path carries different operational implications for validation and rollback in managed environments.

---

Final assessment — strengths, weaknesses, and practical advice​

Strengths:

• Microsoft acknowledged the issue quickly and recorded it on the Release Health dashboard, which reduces ambiguity for administrators and allows for coordinated remediation planning.
• Community troubleshooting produced pragmatic mitigations (external boot media, winre.wim replacement) that can rescue stuck devices without immediate vendor hotfixes — useful for advanced users and admins.

Weaknesses and risks:

• The bug removes the local recovery capability on many modern devices, increasing escalation to external media, image restores, or device replacement for non‑technical users.
• Complex rollback semantics when Safe OS content is updated alongside the LCU complicates fleet remediation and may prolong exposure for large estates.
• Until Microsoft publishes a definitive technical root cause, targeted mitigations (like replacing winre.wim) remain community‑driven, potentially inconsistent across hardware profiles.

Conservative practical advice:

• Create and validate external recovery media immediately.
• Pause broad deployment of KB5066835 for recovery‑critical endpoints and test any Microsoft hotfix in a pilot ring that matches the hardware mix of production.
• Maintain known‑good winre.wim images and document winre replacement and recovery runbooks for frontline technicians.
• Treat recovery testing as mandatory in update validation cycles going forward.

---

Closing summary​

A routine October security rollup (KB5066835) inadvertently disabled USB input inside the Windows Recovery Environment on a wide set of Windows 11 (24H2/25H2) and Windows Server 2025 devices. Microsoft confirmed the issue and said engineers were working on a fix; community and enterprise members have cataloged practical mitigations — from validated external USB media to winre.wim restoration — while warning that rollback semantics are non‑trivial for many deployments. The incident is a clarion call: recovery paths must be validated as rigorously as the desktop itself, and organizations should bake pre‑boot and recovery checks into their update staging and acceptance criteria to avoid being surprised the next time a Safe OS update touches a critical driver set.

---

Source: theregister.com Windows 11 update takes out USB ports in recovery mode

 

[ChatGPT]

Microsoft’s October Patch Tuesday cumulative update (KB5066835) introduced a serious regression that can render the Windows Recovery Environment (WinRE) unusable on many machines by making USB keyboards and mice unresponsive — a problem Microsoft has acknowledged and is working to fix, while pragmatic workarounds (external recovery media, PS/2 peripherals, or replacing the local winre.wim) let most users and administrators regain recoverability in the short term.

Background​

What went wrong in plain terms​

The October 14, 2025 cumulative update for Windows 11 — published as KB5066835 — shipped with changes that, on some devices, left the Windows Recovery Environment unable to accept input from USB keyboards and mice. The desktop session continues to work normally, but when a machine boots into WinRE (Advanced Startup), the recovery UI appears yet does not respond to USB input. Microsoft added this symptom to its Release Health / Known Issues page and marked the problem as confirmed while engineers prepared a remediation.

Why WinRE matters​

WinRE is a compact “Safe OS” image (winre.wim) that runs outside the full Windows desktop to provide critical repair tools: Safe Mode, Startup Repair, Reset this PC, Command Prompt, and firmware/UEFI access. Because WinRE intentionally contains a drastically reduced driver and service set to maximize reliability, it’s sensitive to driver set mismatches. If the WinRE image lacks a compatible USB host‑controller/xHCI driver for a machine, USB devices that work in the full OS may fail to initialize inside WinRE — exactly the symptom observed after KB5066835.

---

Timeline and scope​

Key dates and build information​

• October 14, 2025 — Microsoft released the October cumulative update for Windows 11 as KB5066835.
• October 17, 2025 — Microsoft updated its Release Health page to list the WinRE USB‑input issue as a confirmed problem and stated engineers were working on a fix to be released “in the coming days.”

Affected OS branches include Windows 11 versions 24H2 and 25H2 (reported build numbers include 26100.6899 and 26200.6899), and some Windows Server 2025 SKUs were implicated in community reports. The problem has been reproduced across a range of consumer and enterprise hardware profiles, with the most severe user impact on machines that use USB‑only input (modern laptops and mini‑PCs with no PS/2 fallback).

How widespread is the problem?​

Community threads and independent technical outlets showed consistent reproductions across vendors and hardware. While the exact percentage of affected devices is unknown (Microsoft has not published a breakdown), the issue is broad enough that Microsoft issued a public acknowledgement and began distributing targeted mitigations. Enterprises and IT teams reported heightened helpdesk activity and increased mean time to repair (MTTR) in the days after deployment.

---

Symptoms and immediate user impact​

• When an affected PC boots into WinRE, the recovery tiles and options display normally, but USB keyboard and mouse input is ignored — no cursor movement, no keystrokes. The same peripherals continue to work inside the fully booted Windows session.
• Built‑in recovery operations (Safe Mode, Reset this PC, Startup Repair) become inaccessible without a functional input device in WinRE. For USB‑only devices this effectively eliminates the on‑device repair path.
• Some developers and IT professionals also reported unrelated regressions tied to the same update wave — notably an HTTP.sys regression that affected local HTTP/2 (localhost) connections and assorted File Explorer preview pane errors — increasing the overall servicing‑wave risk profile.

---

Official response and Microsoft’s remediation path​

Microsoft confirmed the issue on its Release Health / Known Issues dashboard and stated that engineers were preparing a fix. The company indicated a hotfix or a targeted Known Issue Rollback (KIR) would be used to remediate affected machines, and recommended that users check Windows Update for any out‑of‑band patches and reboot to complete installation when they appear.
Known Issue Rollback is Microsoft’s standard mechanism to neutralize a problematic change without removing the security content of updates, making it an ideal remediation path for regressions that must be disabled quickly across a broad installed base. Microsoft historically uses KIRs and targeted hotfix rollouts to reduce disruption while preserving protections.

---

Workarounds and mitigations — practical, step‑by‑step​

Microsoft’s acknowledgement means the safest long‑term fix is to install the vendor’s remediation when it ships, but there are practical, risk‑graded workarounds administrators and advanced users can employ now.

Low‑risk and recommended (first choices)​

• Check Windows Update and apply Microsoft’s hotfix or KIR when available. This is the cleanest option and preserves security posture.
• Use external recovery media (recommended immediate workaround). Build a bootable Windows 11 installation USB (or a WinPE stick) from a known‑good ISO on a working machine, boot the affected device from that media, then choose Repair your computer → Troubleshoot → Advanced options. The installer’s WinPE environment typically contains a richer driver set and will accept USB input.

Intermediate (requires caution)​

• Use a PS/2 keyboard or mouse if the PC has a PS/2 port. The bug affects USB devices inside WinRE; PS/2 peripherals will continue to work when present. This is the simplest on‑device fix for machines that expose legacy ports.
• Uninstall KB5066835 from the running OS (only if you can boot normally). Navigate to Settings → Windows Update → Update history → Uninstall updates, find KB5066835 and remove it, then reboot. Caveat: the update may have been deployed as a combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) in some environments; SSU components cannot be removed via the Settings UI, and uninstalling the LCU alone may not always restore prior WinRE content. Test this in a lab first.

Advanced and high‑risk (for experienced technicians)​

• Replace the local winre.wim with a known‑good image extracted from a matching Windows ISO. High‑level steps:
• On a working PC, mount a Windows 11 ISO that matches the affected device’s build and extract the winre.wim.
• On the affected PC, open an elevated command prompt and run reagentc /disable to unregister the current WinRE image.
• Back up C:\Windows\System32\Recovery\Winre.wim, replace it with the known‑good copy, then run reagentc /enable and reagentc /info to verify.
• Reboot and test Advanced Startup.
  This method has restored WinRE input for many users, but it is inherently risky: a mistaken replacement can leave the device without a valid recovery image. Back up the original winre.wim and keep external recovery media on hand before proceeding.
• For enterprise fleets, apply Microsoft’s Known Issue Rollback (KIR) or targeted policy MSI when Microsoft publishes it; do not attempt large‑scale manual winre.wim replacements or uninstall operations across production devices without lab validation.

---

Step‑by‑step checklist for IT teams (recommended sequence)​

• Inventory and prioritize: identify recovery‑critical endpoints (kiosks, in‑store devices, PCs without external recovery options) and mark them for a pause in broad KB5066835 deployment until a fix is validated.
• Prepare external recovery media now: create a bootable Windows 11 USB or WinPE stick for each site and validate that it boots and accepts USB input. Test Reset/Startup Repair flows on representative hardware.
• Capture WinRE metadata: run reagentc /info, collect winre.wim version strings, and keep checksummed copies of known‑good winre.wim files per hardware profile.
• Pilot and validate: when Microsoft publishes a hotfix or KIR, apply it to a pilot ring with USB‑only hardware to confirm WinRE input is restored before rolling out broadly.
• Update runbooks: add explicit WinRE/WinPE verification steps to monthly servicing playbooks and require recovery‑flow acceptance criteria in preproduction testing.

---

Technical anatomy — plausible causes and what’s still unknown​

Community analysis and practical troubleshooting strongly suggest a Safe OS / WinRE image change or a mispackaged driver variant is responsible — specifically, the minimal WinRE driver set likely lacked a compatible USB host‑controller driver variant for some hardware profiles after the update. Replacing the local winre.wim with a known‑good copy commonly restored input, which points at an image mismatch rather than a hardware failure. However, Microsoft has not yet published a formal root‑cause analysis, so any specific claim about which driver or file caused the regression should be treated as speculative until Microsoft releases technical detail.

---

Broader implications and critical analysis​

What Microsoft did well​

• Microsoft moved relatively quickly to mark the issue as confirmed on Release Health and to communicate that engineering was preparing a fix, which helped focus community mitigation and avoid ad hoc risky workarounds. Public acknowledgement reduced the time admins spent chasing false leads.

Where the process fell short​

• The incident exposed a testing gap: Safe OS/WinRE images were not validated broadly enough across the diversity of USB host controllers in the hardware ecosystem. An update that “works” in the running desktop but breaks WinRE is a high‑impact regression because it undermines the system’s fallback.
• Combined SSU+LCU packaging complicates rollback semantics. Administrators accustomed to “uninstall the KB” as a fix may find that removing the LCU alone does not restore WinRE to a previous state, complicating recovery at scale.

Operational lessons for organizations​

• Treat WinRE / Safe OS updates as first‑class citizens in QA and pilot testing. Recovery flows (Advanced Startup, Reset this PC, BitLocker unlock in WinRE) must be explicit acceptance criteria before wide deployment.
• Maintain known‑good winre.wim images for each golden image and hardware profile. Keep checksums and offline copies so you can restore a validated recovery image if needed.
• Keep external WinPE or Windows installation media readily available, and ensure frontline technicians are trained to use them. The presence of validated external media is the single most effective immediate mitigation for a broken on‑device WinRE.

---

Risk warnings and unverified claims​

• Several community posts alleged permanent hardware damage (for example, SSD failures) after the update. These claims remain unverified and should be treated with caution; there is no publicly confirmed evidence that KB5066835 physically damaged hardware. Do not assume hardware failure without reproducible diagnostics and vendor logs.
• Any advice to perform deep registry surgery, install unsigned drivers, or apply unvetted scripts pulled from discussion forums carries real risk and can leave a system unbootable. Prefer Microsoft’s official hotfix/KIR or validated winre.wim replacement procedures over ad hoc hacks.

---

Recommendations for home users and enthusiasts​

• Pause automatic installation of the October cumulative (KB5066835) if your device is recovery‑critical and you have not installed it yet. Use Settings → Windows Update → Pause updates.
• Create a bootable Windows 11 installation USB now and store BitLocker recovery keys in a safe location. If WinRE becomes unresponsive, you will need external media to recover the device.
• If your device has a PS/2 port and you’re comfortable using legacy peripherals, plug in a PS/2 keyboard or mouse to operate WinRE until Microsoft’s fix arrives. This is an immediate, low‑effort workaround where applicable.
• If you can boot normally and are comfortable with risk, you can uninstall KB5066835; but understand the security tradeoffs and the complexity introduced by SSU+LCU packaging — test before widespread rollback.

---

Long‑term policy and engineering implications​

This incident is a vivid reminder that recovery tooling is not optional: a regression that compromises recovery pathways compounds the operational cost of maintaining secure systems. To reduce this class of risk, vendors and organizations should:

• Expand update validation matrices to include WinRE/WinPE testing across representative hardware, with special attention to USB‑only devices and newer host‑controller variants.
• Provide clearer rollback mechanisms specifically for Safe OS updates or avoid bundling Safe OS changes in combined SSU+LCU packages where rollback would be nontrivial.
• Publish clear guidance for enterprise-scale winre.wim management and recovery media distribution, including deterministic checksums and automation-friendly tooling for safe restoration.

---

Conclusion​

The October Patch Tuesday cumulative for Windows 11 (KB5066835) produced a high‑impact regression by preventing USB input inside WinRE on a subset of machines, turning the on‑device recovery pathway into a potentially non‑interactive screen. Microsoft has acknowledged the issue and indicated a fix is coming; in the meantime, the safest immediate steps are conservative and practical: check Windows Update for Microsoft’s hotfix, prepare validated external recovery media, and pause broad deployment of KB5066835 on recovery‑critical endpoints. Enterprises should inventory WinRE images, preserve known‑good winre.wim copies, and require WinRE validation as part of any servicing pilot. The event underscores a systemic truth: recovery flows must be tested and treated as first‑class components of any update cycle — because security is only useful if you can recover when something goes wrong.

---

Source: ZDNET Windows 11's October update causes a serious recovery mode glitch - but there's a workaround

 

[ChatGPT]

Microsoft has acknowledged a serious regression in its October cumulative update for Windows 11 — the security patch released as KB5066835 on October 14, 2025 — after reports that USB keyboards and mice stop responding inside the Windows Recovery Environment (WinRE), effectively blocking access to built‑in recovery tools on affected machines.

Background​

The Windows Recovery Environment (WinRE) is a trimmed‑down runtime that loads when Windows cannot boot normally or when users intentionally invoke advanced startup options. It provides critical troubleshooting tools such as Startup Repair, System Restore, Safe Mode, and an emergency Command Prompt. For administrators, technicians, and everyday users alike, WinRE is a first‑line defense against unbootable systems.
On October 14, 2025 Microsoft shipped a mandatory security update identified as KB5066835 for Windows 11 (and matching builds for supported Server SKUs). Within days, numerous users reported that when their systems entered WinRE the screen showed the expected recovery tiles but USB keyboards and mice would not respond. The devices continued to work normally in the full Windows desktop, but once the system booted into WinRE there was no mouse cursor, keystrokes did not register, and recovery menus could not be navigated.
Microsoft updated its release‑health documentation to confirm the symptom and the originating update and stated that an out‑of‑band fix was in development. The company opened a known‑issues entry and advised that a solution would be released “in the coming days.” Community reports, Microsoft Q&A threads, and multiple independent outlets corroborated the behavior and offered interim workarounds for affected systems.

---

What happened (technical overview)​

How WinRE is different from the running OS​

WinRE is built from a smaller, minimal image — typically a WinRE.wim file stored in a hidden recovery partition or embedded in system imagery. Because it uses a limited driver set and a smaller kernel/user stack, it only loads drivers needed to perform basic recovery tasks. That lean footprint is why some hardware that works perfectly in the full OS can fail to initialise in WinRE if the needed driver or USB stack component is missing, disabled, or incompatible.

The regression introduced by KB5066835​

After installing KB5066835 (OS build numbers recorded in affected installations included builds such as 26100.6899 and 26200.6899 depending on the branch), users reported that the WinRE image no longer correctly initialised USB input. The symptom set is consistent with the WinRE session failing to load the USB host controller drivers or the USB stack being disabled when SafeOS/WinRE launches. The OS desktop remains unaffected because the full Windows boot path loads the broader set of drivers and services.
Multiple independent reports indicated the issue appears most frequently on systems that rely solely on USB‑C or USB‑3 ports (for which PS/2 alternatives do not exist), though users with wireless dongles and various USB peripherals also reported failures. Anecdotal reporting from technicians suggested that older PS/2 keyboards and mice — where those ports remain available — were not affected because PS/2 input is handled by legacy drivers loaded earlier during hardware initialisation and does not depend on the USB stack.

Why this matters​

If WinRE is unreachable due to input devices being unusable, the user cannot:

• Enter Safe Mode from the Advanced Startup menu.
• Run Startup Repair, System Restore, or access the Command Prompt.
• Rebuild or repair system images via the built‑in recovery options.
• Access firmware/UEFI settings via the recovery UI on some OEM platforms.

For systems that fail booting into Windows — for example after disk errors, driver corruption, or malware remediation sequences — losing the ability to interact with WinRE significantly raises the chance of a recovery requiring external media, professional repair, or a full re‑install. For IT operations teams, the bug complicates remote remediation and escalates incident response.

---

Scope and affected platforms​

• Affected client builds include Windows 11 version 25H2 and version 24H2 on x64 platforms where the October 14, 2025 cumulative update was applied.
• Server editions were also reported to be affected where corresponding cumulative updates were installed.
• The problem was reproducible across various OEMs and custom builds, indicating the issue emerges from the update’s handling of the SafeOS/WinRE stack rather than being limited to a single device vendor.

The issue is widespread enough that Microsoft listed it in its product health dashboard as a confirmed problem with the originating update and opened a support notice advising that a fix was in progress.

---

Microsoft’s response and timeline​

Microsoft formally acknowledged the WinRE input fault in its support documentation and flagged KB5066835 as the originating package. The company stated that it was “working to release a solution in the coming days.” Historically, a short delay followed by an out‑of‑band (emergency) update is Microsoft’s typical approach when a security update has introduced a regression that disrupts core functionality.
Key published facts:

• The update in question was released on October 14, 2025.
• Microsoft’s support documentation was revised to note the USB keyboard and mouse malfunction inside WinRE.
• Microsoft told administrators and users that a fix would be forthcoming, but no precise ETA was provided at initial disclosure.

Given the critical nature of WinRE, Microsoft prioritised an out‑of‑band remedy rather than waiting for the monthly patch cycle; this has been the favoured approach in similar recent incidents where boot or recovery functionality is impacted.

---

Verifying other claims and contextual items — what’s accurate and what needs caution​

• It is accurate that the October cumulative update produced a WinRE input regression and that Microsoft confirmed the problem in its release‑health documentation.
• It is accurate that Microsoft offered an Extended Security Updates (ESU) path for Windows 10 users after that platform reached end‑of‑support; enrollment options and prices for consumer ESU varied by region and the specific mechanism (free option via cloud backup/OneDrive in some regions vs. a small paid one‑time enrolment elsewhere).
• Some press reports and social posts speculated that the update also broke localhost networking and additional features; those secondary regressions were reported by developers and in community threads but vary by configuration and are not uniformly reproducible across all environments. Treat non‑WinRE claims as possible but environment‑dependent until confirmed by Microsoft or reproduced consistently across multiple lab configurations.

Cautionary note: various outlets quoted specific monetary figures for Windows 10 ESU fees and UK pricing points in GBP — those numbers differed across publications and Microsoft’s consumer ESU program details. Any financial figure should be checked against local Microsoft announcements or the user’s Microsoft account enrolment screen; regional pricing and eligibility can differ.

---

Practical guidance — immediate steps for users and administrators​

For users and admins facing this problem there are three broad options: avoid invoking WinRE while the issue persists, use external recovery media, or reverse the update where feasible. Each choice carries trade‑offs.

Immediate, low‑risk options​

• Avoid using Advanced Startup / WinRE until Microsoft publishes the hotfix. If Windows boots normally, do not trigger recovery menus unless absolutely necessary.
• Create bootable Windows 11 recovery media now (recommended for all users) so you have a fallback that loads drivers independent of the local WinRE image. This ensures keyboard and mouse work during rescue operations.

How to create a bootable Windows 11 recovery USB (short checklist):

• On a working Windows PC, download the official Media Creation Tool or official ISO for Windows 11 from Microsoft.
• Use the Media Creation Tool or a reliable image‑burning utility to write the ISO to a USB drive (8GB or larger).
• Boot target PC from the USB drive by selecting it in the firmware/UEFI boot menu and choose the “Repair your computer” option to access recovery tools.
• Use these tools to run Startup Repair, Command Prompt, or to reinstall Windows while keeping files (when applicable).

This USB approach bypasses the local WinRE.wim image and typically includes broader driver support, giving access to recovery tools even when the internal recovery image is broken.

Rolling back the update​

If a device is already affected and you prefer to restore local WinRE functionality without waiting:

• Open Settings > Windows Update > Update history > Uninstall updates.
• Locate the October 14, 2025 cumulative update entry (KB5066835) and choose to uninstall it.
• Reboot and test WinRE functionality.

Caveats:

• Uninstalling may not restore WinRE in all cases if the local WinRE.wim was replaced or corrupted; some users reported needing to rebuild or replace the winre.wim file.
• Uninstalling security updates temporarily reduces protection for any newly patched vulnerabilities; weigh this against the need for recovery functionality.

Advanced: replacing or rebuilding the WinRE image​

Technically proficient users or administrators can consider restoring a known‑good WinRE.wim:

• Obtain a matching Windows 11 ISO for your version and extract the WinRE.wim from the ISO (usually under the sources or a recovery image folder).
• Mount or access the recovery partition and replace the existing \Recovery\WindowsRE\winre.wim with the extracted image.
• Run reagentc /disable then reagentc /enable to re‑register WinRE.
• Reboot and test.

This approach can restore input functionality because it swaps the minimal recovery image with a known‑good copy. However, it is not risk‑free:

• Mistakes in partition handling, file replacement, or reagentc use can render a system unbootable until repaired with external media.
• The WinRE image must precisely match the installed build/edition to avoid version mismatches.

Only perform these steps if you are comfortable using DISM, mounting wim files, and manipulating hidden partitions; otherwise rely on bootable USB recovery or wait for Microsoft’s update.

---

What system administrators should do now​

• Prioritise creating and testing bootable recovery media for all critical systems. Confirm USB input works on those media on representative hardware.
• If you manage many endpoints, consider temporarily pausing automatic installation of the October 14 cumulative update via your update management tooling (WSUS, Intune, SCCM, or third‑party patch management) until Microsoft issues the fix and it has been validated in a test ring.
• Prepare a rollback plan and include guidance for replacing WinRE images if rollback cannot be performed centrally.
• Communicate to support teams and end users that they should avoid invoking advanced startup unless they have external recovery USBs available.
• Monitor Microsoft’s release health updates and the official hotfix, and stage testing in a controlled environment before wide deployment.

---

Risks and potential downstream impacts​

• For home users without technical backups or recovery USBs, an unbootable machine could require professional repair or full operating system reinstallation.
• IT service desks may face higher incident volumes as users who previously relied on WinRE call for assistance.
• Any premature mass rollback of a security update increases exposure to vulnerabilities the update was intended to mitigate. Organisations must weigh the immediate operational risk against the security risk and deploy compensating controls (network segmentation, endpoint protection policies) if rollback is necessary.
• Some users reported ancillary regressions — such as local HTTP loopback failures and device‑specific peripheral regressions — that may affect developer workflows or hardware utility software. These are environment dependent and should be validated in each enterprise’s test environment.

---

How to evaluate Microsoft’s fix when it arrives​

When Microsoft releases an out‑of‑band patch, validate the fix before broad deployment:

• Test the hotfix on a representative set of hardware platforms, including devices with only USB‑C, devices with legacy PS/2 ports, and machines using wireless dongles.
• Confirm WinRE input works for each test machine using Advanced Startup → Troubleshoot → Advanced Options.
• Verify that no new regressions are introduced by the hotfix — run basic desktop application smoke tests, network tests (including localhost loopback if your environment uses local development tooling), and check device utilities that interact with input devices.
• If all tests pass in the pilot group, schedule phased rollouts and monitor telemetry and helpdesk tickets closely during the initial days.

---

Longer‑term considerations for users who haven't upgraded to Windows 11​

The WinRE regression is a reminder of two longer‑term realities:

• Older platforms, including Windows 10 (which reached end‑of‑support windows in mid‑October 2025), will increasingly rely on Extended Security Updates or third‑party mitigations. While ESU programs exist, their enrolment terms and costs vary by region and by consumer vs enterprise offerings.
• Upgrading to the latest OS can bring new features and security gains but also introduces the risk of platform changes and new regressions. Organisations should maintain rigorous testing and patch‑management processes rather than assume newer platforms are immune from rollout faults.

Users who cannot or will not upgrade should maintain reliable recovery media, immutable backups, and a tested restoration plan because vendor updates can sometimes disrupt recovery paths unexpectedly.

---

Final analysis — strengths, failures, and lessons​

KB5066835 demonstrates both the strengths and fragilities of modern patch delivery at scale. On the positive side, Microsoft’s transparent acknowledgement and the rapid opening of a support notice reflect a responsive support posture: the company documented the issue and committed to an out‑of‑band update. That responsiveness, combined with the ability to push hotfixes outside the regular monthly cadence, reduces long‑term risk.
On the downside, the incident exposes weak links in the test matrix for SafeOS/WinRE scenarios. WinRE is a critical emergency tool and should be treated as such in pre‑release validation — it must be tested across broad hardware permutations (USB‑C only systems, wireless dongles, diverse USB host controllers, and modern dock ecosystems). The outage also underscores how a security update, while necessary, can have outsized operational impact if it touches low‑level boot or recovery components.
Key lessons:

• Organisations must keep a tested, offline recovery process and maintain bootable media for emergency use.
• Patch rollout should be phased with canary/pilot groups and validated against recovery paths, not just mainline desktop scenarios.
• Vendors and OEMs should expand test coverage for WinRE/SafeOS permutations reflecting modern port and driver configurations.

---

Recommendations — what every user should do now​

• Create a bootable Windows 11 recovery USB right away and keep it somewhere safe.
• Backup critical files to an external drive or cloud service before applying updates.
• If you manage devices centrally, put the October 14, 2025 update into a test ring before wider deployment.
• If you are non‑technical and rely on a support contract or local repair shop, inform them that recovery media may be required if there are boot problems.
• Wait for the official hotfix if you can — but have fallback recovery media prepared.

---

The WinRE input regression caused by KB5066835 has proven disruptive for users who rely on Windows’ built‑in recovery capabilities. Microsoft has acknowledged the issue and is developing a fix, but in the interim the best defence is preparation: create and test external recovery media, consider controlled rollback only when necessary, and give priority to phased testing for critical systems. This incident is a reminder that while automatic updates are crucial for security, they also require robust rollback and recovery plans to protect availability and reduce downtime when regressions occur.

---

Source: GB News Microsoft working on emergency fix for Windows 11 users after latest update causes chaos