Navigation section

October Windows Update Regressions: WinRE Input, IIS Localhost, and Smart Card Breakage

  • Thread Author
Microsoft’s October servicing wave has produced a trio of high‑impact regressions that are already disrupting developer workflows, blocking on‑device recovery options, and interfering with smart‑card authentication — and administrators must balance the imperative to patch critical vulnerabilities against the immediate operational risk these side effects create. Microsoft has acknowledged the issues on its Windows Release Health pages, deployed temporary Known Issue Rollbacks (KIRs) in some cases, and published mitigation guidance; nevertheless, the incident exposes testing and packaging gaps that IT teams should treat as an urgent wake‑up call.

A person sits at a computer in a Windows Recovery Environment, focused on a glowing 'DisableCapiOverrideForRSA' prompt.Background​

Windows updates delivered on Patch Tuesday often touch multiple layers of the platform: the running OS, kernel components, user‑mode services, and — critically — the compact “Safe OS” image used for recovery (WinRE). That breadth of scope is usually a strength for security and correctness, but it multiplies risk when changes ripple into pre‑boot images or kernel subsystems that many applications depend on.
Three problems have been reported and confirmed by Microsoft after the mid‑October servicing wave:
  • WinRE input failure: USB keyboards and mice stop working inside the Windows Recovery Environment (WinRE), preventing users from selecting recovery options. This is tied to the October cumulative update (KB5066835) for Windows 11 builds referenced by Microsoft.
  • Localhost / IIS failures: Local IIS and IIS Express web sites — and other server‑side apps that rely on HTTP.sys — can fail with connection resets or HTTP/2 protocol errors when accessed via loopback (localhost). Community reproductions and Microsoft forum answers point to a kernel‑mode HTTP stack regression introduced or exposed by the update.
  • Smart‑card authentication breakage: A security hardening that prefers the Key Storage Provider (KSP) over legacy CryptoAPI (CSP) for RSA‑based smart‑card certificates led to failures in 32‑bit applications and some signing/auth flows. Microsoft documents event log indicators (Event ID 624) and suggests a registry workaround until a permanent fix is available.
Each of these impacts different operational roles — desktop users and technicians for WinRE, developers and server operators for IIS/HTTP.sys, and secure‑auth/PKI administrators for smart cards — but together they underscore a single lesson: updates that touch pre‑boot images or kernel networking components must be validated against a broader, hardware‑diverse test matrix.

WinRE: When the recovery environment becomes unusable​

What’s happening now​

After installing the October 14, 2025 cumulative update (KB5066835) on affected Windows 11 builds, many systems boot into the Windows Recovery Environment but fail to accept USB keyboard or mouse input. The WinRE UI appears visually, but there is no visible cursor and keystrokes are ignored; the same USB devices continue to function normally once the full OS boots. Microsoft lists this as a Confirmed issue for Windows 11 versions 24H2 and 25H2 (and related Server servicing) and says engineers are working on a fix.

Why WinRE is fragile​

WinRE is a deliberately minimal Safe OS (typically deployed as winre.wim) with a greatly reduced driver set. That limited footprint is the reason WinRE boots reliably in many failure cases, but it also means:
  • Missing or incompatible USB host controller drivers in the WinRE image will prevent USB peripherals from initializing there, even if they work in the full OS.
  • Dynamic Safe OS updates or packaged servicing that replace the winre.wim can inadvertently ship an image that lacks the precise driver variants required for certain hardware, especially USB‑C / USB‑3‑only systems. Community reproductions that restored an earlier winre.wim frequently recovered WinRE input, strongly implicating an updated Safe OS image as the proximate vector.

Scope and immediate impact​

  • Affected platforms: Windows 11 25H2 and 24H2 (client), and Windows Server 2025 (server variants reported). Microsoft’s Release Health entry lists the originating KB and the status as Confirmed.
  • Real‑world effect: Users cannot access built‑in recovery options (Safe Mode, Automatic Repair, Reset this PC, Command Prompt) from Advanced Startup if those options require keyboard or mouse input. Systems that rely exclusively on USB ports for input (modern thin laptops, mini‑PCs, USB‑only docking scenarios) are particularly at risk.

What Microsoft has done (and what admins should expect)​

  • Microsoft has posted the issue on the Windows Release Health dashboard and stated that a solution is in development. Where possible, Microsoft uses Known Issue Rollbacks (KIRs) or targeted out‑of‑band fixes; administrators should monitor Release Health and Windows Update for an immediate remediation package.
  • A temporary community mitigation is to restore a previously known‑good winre.wim extracted from an earlier ISO, or to boot external WinPE/installation media for recovery tasks. These are advanced operations and carry risk; they should only be performed by experienced personnel and after full backups.

IIS and localhost: HTTP.sys regressions break local web workloads​

Symptom set​

Developers and sysadmins have reported that loopback connections to IIS and IIS Express sites fail after the update, with browser errors such as:
  • ERR_CONNECTION_RESET
  • ERR_HTTP2_PROTOCOL_ERROR
Visual Studio debugging that depends on IIS Express or HttpListener fails to start, and some enterprise products that use local IIS for management or inter‑process communication stop responding. These reports are collated across Microsoft’s Q&A threads and independent technical forums.

Under the hood: why HTTP.sys matters​

HTTP.sys is the kernel‑mode HTTP listener that accepts TCP connections and handles initial protocol negotiation before user‑mode worker processes see traffic. A kernel‑level regression in HTTP.sys — particularly during HTTP/2 or TLS post‑handshake negotiation — can cause immediate session termination and make a perfectly healthy user‑mode web process unreachable from the same host.
That kernel‑level placement explains why the failures often look like “IIS is down” even when the worker processes are running: the listener is dropping or resetting connections before work is dispatched.

Mitigations that have worked in the field​

  • Microsoft engineers and community responders have suggested workarounds including:
  • Installing the Microsoft Defender Security Intelligence update (which resolved symptoms for some users).
  • Disabling HTTP/2 at the OS HTTP stack or IIS level (a configuration change that reduces protocol functionality but can restore compatibility).
  • Uninstalling the offending KB in controlled scenarios or awaiting a KIR.
Each option has trade‑offs: rolling back a cumulative may not always restore the Safe OS image or be feasible in large fleets, and disabling HTTP/2 reduces modern protocol performance/features.

Smart‑card authentication: KSP vs CSP, and the temporary registry fix​

The change and its effect​

October security updates include a security improvement that prefers Key Storage Provider (KSP) over legacy Cryptographic Service Provider (CSP) for RSA‑based smart‑card certificates. That change hardens cryptography handling but breaks applications that depend on CSP semantics — notably some 32‑bit apps and signing workflows. Symptom examples include:
  • “Invalid provider type specified”
  • “CryptAcquireCertificatePrivateKey error”
  • Smart cards not recognized as CSP providers in 32‑bit processes
  • Failure to sign documents or authenticate in apps relying on certificate‑based auth
Microsoft’s guidance ties the issue to the security improvement and lists Event ID 624 entries in the System log as a pre‑deployment indicator that a smart card may be impacted.

Registered workaround​

Microsoft documents a registry workaround that re‑establishes the legacy behavior by creating or editing the following key:
  • Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais
  • Value name: DisableCapiOverrideForRSA
  • Type: DWORD (32‑bit) — set to 0
  • Action: Reboot the device after setting the value
Microsoft’s documentation does not explicitly name the registry type, but a DWORD is the conventional and tested type for similar flags; the vendor’s published instructions and community reproductions assume DWORD semantics. Use this workaround only as a temporary measure: it restores legacy CSP behavior but partially undoes the security improvement that prompted the change.

Long‑term remediation​

  • Contact middleware and smart‑card vendor(s) to confirm KSP compatibility and request updated drivers or middleware that support the newer model.
  • Test 32‑bit legacy applications under a lab image using the updated behavior and plan application updates or mitigations where required.
  • Maintain strict change records: toggling the registry flag should be treated as a temporary exception with a date to revert once vendor fixes are available.

Known Issue Rollbacks (KIR) and the packaging problem​

Microsoft’s Known Issue Rollback mechanism allows the vendor to revert specific behavioral changes by flagging update metadata or rolling back a particular change server‑side; KIRs can be faster and less disruptive than issuing a whole cumulative patch. Microsoft has used KIRs and small out‑of‑band fixes in this incident for some symptoms, but the presence of combined SSU+LCU packages complicates rollback semantics.
When an SSU (Servicing Stack Update) and LCU (Latest Cumulative Update) are packaged together, conventional uninstall semantics do not always restore previous Safe OS (WinRE) images or driver sets. That means uninstalling the LCU alone may leave a system with a modified Safe OS image, requiring more invasive remediation. Administrators should therefore:
  • Prefer vendor‑issued KIRs or out‑of‑band updates over local attempts at aggressive rollback.
  • Validate remediation on a pilot ring before broad rollout.
  • Preserve known‑good winre.wim images and documented image restoration runbooks.

Practical, prioritized checklist for administrators​

  • Check Microsoft’s Windows Release Health dashboard for your OS builds and the specific Known Issue entries (WinRE, smart‑card, IIS) and follow any vendor remediation steps published there.
  • Immediately verify whether you have received a KIR or out‑of‑band patch; if a fix has been published, apply it in a test ring and reboot devices. Microsoft sometimes requires a manual reboot even when the update appears not to change state.
  • Inventory and prioritize systems that are recovery‑critical or have USB‑only input (thin clients, USB‑C laptops, kiosks). Hold broad automated deployments for those endpoints until remediation is proven.
  • Create verified external recovery media (Windows installation USB / WinPE) and ensure BitLocker recovery keys and image backups are accessible before performing any invasive remediation on production devices.
  • For smart‑card‑reliant stations: check Event Viewer for Event ID 624 to detect potential incompatibility prior to the update, and if needed apply the registry workaround (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\DisableCapiOverrideForRSA = 0, DWORD) as a temporary fix. Document and track each exception.
  • For developers and servers impacted by localhost/IIS failures: test whether installing the latest Microsoft Defender Security Intelligence update resolves the issue for your configuration; otherwise consider disabling HTTP/2 at the OS/IIS level as a temporary mitigation while awaiting a KIR or patch. Perform these changes in test first and monitor for regression.
  • Maintain a controlled rollback plan and golden image library (versioned winre.wim files) so that an older Safe OS image can be restored in a controlled manner on affected devices if required. Restoring winre.wim is an advanced operation; follow validated runbooks.
  • Communicate: alert helpdesk and frontline engineers with clear scripts — do not instruct inexperienced users to edit the registry or replace winre.wim without supervised support.

Critical analysis: strengths, weaknesses, and systemic risks​

Strengths​

  • Microsoft’s public acknowledgment and the Release Health dashboard provide a single authoritative channel for status and mitigation guidance, which speeds enterprise triage and reduces noisy speculation.
  • The KIR mechanism gives Microsoft a tool to revert problematic behavioral changes without forcing administrators through remote manual uninstalls or risky local workarounds.

Weaknesses and risks​

  • Testing gaps for WinRE / Safe OS: WinRE’s minimal driver set makes it vulnerable to regressions introduced by Safe OS image updates. This incident demonstrates that update test matrices must explicitly include recovery flows on diverse hardware profiles, particularly USB‑only input configurations. Community reproductions suggesting winre.wim replacement restored input point to mispackaged Safe OS artifacts as a likely root cause.
  • Rollback complexity: Combined SSU+LCU packages complicate rollback semantics and can leave pre‑boot images in an inconsistent state after an attempted uninstall. The result is that simple uninstalls are not always a reliable remediation path at scale.
  • Security vs. compatibility trade‑offs: The smart‑card change that favors KSP over CSP is a bona fide security improvement, but toggling the registry to restore CSP semantics weakens the intended hardening. Each temporary workaround increases attack surface or reduces crypto guarantees and must be tracked as a controlled risk.

Broader operational lessons​

  • Treat recovery images as first‑class citizens in update validation. Include WinRE/WinPE tests in CI pipelines and hardware labs with USB‑only devices.
  • Maintain staged deployments with real‑hardware pilot rings that mirror production diversity rather than simple VM‑only tests.
  • Keep clearly documented runbooks for emergency actions: external media boots, winre.wim restore steps, BitLocker recovery retrieval, and vendor escalation paths.

Final verdict and recommendation​

The October servicing regressions illustrate the non‑trivial operational risk of platform‑level changes that touch Safe OS images and kernel subsystems. While security updates remain vital — the October rollup closed hundreds of vulnerabilities including multiple critical CVEs — administrators cannot adopt a “blind install” posture. Balanced action is required:
  • Continue to prioritize security updates (do not skip patching wholesale), but use staged deployments and keep recovery paths tested and available.
  • Follow Microsoft’s Release Health advisories and apply vendor KIRs or patches as soon as they are validated in a representative pilot ring.
  • Use documented, conservative mitigations (registry workaround for smart cards, temporary HTTP/2 disablement) only when absolutely necessary and with clear plans to remove the workaround after a vendor fix is available.
  • Institutionalize the lessons from this incident: make Safe OS and pre‑boot validation part of the standard update acceptance criteria, preserve golden winre.wim images, and build runbooks that reduce the blast radius when a servicing regression occurs.
Microsoft’s public confirmations, the KIR mechanism, and the active community triage are positive signals, but they do not substitute for disciplined update governance. Administrators should act promptly to inventory affected endpoints, secure recovery tools, and apply vendor‑approved remediations in a controlled manner — prioritizing recoverability as highly as patch cadence.
Every paragraph above is drawn from vendor advisories and field reporting: consult Microsoft’s Windows Release Health pages for the authoritative status on WinRE and smart‑card issues, review Microsoft Q&A threads and Defender security intelligence bulletins for IIS/HTTP.sys guidance, and validate community mitigation steps in a staging environment before applying them in production.
Source: heise online Windows Updates: Problems after Patch Day
 

Click to expand...
You must log in or register to reply here.
Back
Top