Windows 11 KB5063878 0x80240069: WSUS/SCCM Failure and KIR Workaround

Microsoft has confirmed that the August 12, 2025 cumulative update for Windows 11 (KB5063878, OS Build 26100.4946) is failing to install on managed endpoints delivered through WSUS and SCCM, producing the download/install error code 0x80240069; the company is offering a temporary Known Issue Rollback (KIR) via Group Policy as a workaround while it prepares a permanent servicing fix. (support.microsoft.com, neowin.net)

Background / Overview​

KB5063878 is the August 2025 cumulative update for Windows 11 (version 24H2) and ships as a combined Servicing Stack Update (SSU) + Latest Cumulative Update (LCU). The release bundles security fixes, quality improvements and some AI‑component updates for Copilot‑eligible hardware. Microsoft documents the release and its build number (26100.4946) on its KB pages and advises administrators to test before broad deployment. (support.microsoft.com)
On the surface this looked routine, but soon after distribution a subset of enterprise customers reported repeated WSUS/SCCM delivery failures: downloads stuck or aborting in Software Center/WSUS with Event Viewer records pointing to an unexpected HRESULT and the error code 0x80240069. Microsoft has acknowledged the delivery failure pattern for managed deployments and published a KIR policy definition administrators can deploy while the permanent fix is developed. (windowslatest.com, neowin.net)

---

What KB5063878 contains (brief technical summary)​

• It is a combined SSU + LCU package for Windows 11, version 24H2 (OS Build 26100.4946), published on August 12, 2025. The SSU included is KB5065381 (26100.4933). (support.microsoft.com)
• The LCU commits a series of security and quality fixes (authentication, Start/Taskbar fixes, file‑system issues, and others) and updates several AI components (Image Search, Content Extraction, Semantic Analysis, Settings Model at version 1.2507.793.0). (support.microsoft.com)

This is a standard delivery model Microsoft has used for some time: combining SSU and LCU reduces a common class of dependencies and simplifies installation order, but it also means a failing LCU can interact with the servicing stack in ways that complicate remediation. (support.microsoft.com)

---

Symptoms: what admins are seeing​

Administrators and community troubleshooters have reported a consistent symptom set in WSUS/SCCM-managed rings:

• Installation aborts or “Download error” states inside Software Center or WSUS, with an associated Event log entry showing 0x80240069 and the message “Unexpected HRESULT while download in progress: 0x80240069 WUAHandler.” (windowslatest.com)
• Crash of the Windows Update host process: svchost.exe_wuauserv terminating unexpectedly; faulting module often ntdll.dll; exception codes such as 0xc0000005 appear in crash dumps. (windowslatest.com)
• Additional anecdotal reports (not universally reproducible) of other install errors (0x80240031, 0x800f0922), downloads stalling at low percentages (4–6%), or the update reaching 100% then rolling back with “Something went wrong — reversing changes”. (windowslatest.com)
• Affected behavior is environment dependent: many consumer or direct Microsoft Update clients install the same package successfully, while WSUS/SCCM clients fail. This split points to a delivery/negotiation code path difference between managed and direct‑to‑Microsoft Update flows.

Microsoft’s initial public KB pages for the update did not list any known issues, but the company subsequently acknowledged the delivery problem for managed environments and published guidance and a KIR package for enterprise deployment. (support.microsoft.com, neowin.net)

---

What’s causing the failure (technical analysis)​

Investigations by Microsoft support and independent troubleshooters point at a feature‑management / variant payload selection logic path in the Windows Update agent. In short:

• The Windows Update Agent (wuauserv) contains a code path that evaluates whether the LCU or feature payload should be delivered as a variant for a particular device (this supports targeted payloads and staged feature rollouts). Under certain unexpected payload metadata or variant structures, the agent can enter the variant logic and encounter a bug that causes the host service to crash. When that happens during WSUS‑mediated downloads, the download flow aborts and the client reports 0x80240069.

Why WSUS/SCCM behaves differently: WSUS and SCCM introduce additional approval, metadata and negotiation steps not present when a device talks directly to Microsoft Update. Those differences exercise the variant/feature selection logic in a way consumer update paths may not, so a bug in the variant handling disproportionately impacts managed deployments. This pattern previously produced a similar 0x80240069 problem earlier in 2025 and was solved via a KIR + corrected servicing update—Microsoft’s prior remediation model suggests the same two‑step approach will be used now.
Caveat: while the community and Microsoft support telemetry line up on the variant logic hypothesis, root cause assignment for complex servicing interactions is always provisional until Microsoft publishes a formal post‑mortem or the servicing patch that fixes the bug. Treat the variant logic explanation as the leading working theory backed by logs and reproductions, not as a final, exhaustive root cause report.

---

Microsoft’s response: Known Issue Rollback (KIR) and guidance​

Microsoft has issued a Known Issue Rollback (KIR) policy definition for administrators to deploy via Group Policy (or Intune ADMX ingestion) that neutralizes the offending change on enterprise endpoints until a corrected update is available. The KIR is distributed as a policy MSI and its ADMX/ADML definitions are applied to the Administrative Templates area of Group Policy. Microsoft’s guidance for KIR deployment is explicit: install the KIR MSI on the domain management machine, configure the corresponding Group Policy object (GPO) or Intune ingestion entry, target affected devices, and require a restart for the policy to take effect. (learn.microsoft.com, video2.skills-academy.com)
Neowin reported the Group Policy artifact by name and location (the downloadable KIR MSI titled for Windows 11 24H2 and KB5063878), and Microsoft’s Windows Health dashboard lists the incident and the KIR activation details for affected versions. The company states that once a servicing fix ships, administrators should remove the KIR policy definitions to allow the normal update logic to resume. (neowin.net, learn.microsoft.com)
Key operational points from Microsoft’s KIR model:

• KIRs are intended as temporary mitigations. They disable a specific change rather than uninstalling the whole update, so other non‑problematic fixes remain applied. (learn.microsoft.com)
• Enterprise customers receive a policy MSI; non‑enterprise devices receive automatic KIR application where Microsoft controls the update flow. (learn.microsoft.com)
• After applying KIR, a restart is required and the specific change is disabled until Microsoft publishes an LCU that addresses the defect, at which point the KIR should be removed. (video2.skills-academy.com)

---

Practical mitigation options for administrators (step‑by‑step)​

The tradeoffs are simple: either mitigate the delivery failure so you can keep patching on schedule, or pause KB5063878 approvals in WSUS/SCCM while you wait for Microsoft’s corrected servicing update. The recommended operational playbook below reflects community‑validated workarounds, Microsoft’s KIR option, and cautious testing practices.

Option A — Deploy Microsoft’s KIR via Group Policy (recommended for many enterprises)​

• Download the KIR policy definition MSI that Microsoft published for KB5063878 (the MSI installs ADMX/ADML templates into Administrative Templates). (neowin.net, learn.microsoft.com)
• Run the MSI on the Group Policy management machine (or extract ADMX for Intune ingestion). (video2.skills-academy.com)
• Create or edit a GPO: Computer Configuration -> Administrative Templates -> KB5063878 Issue XXX Rollback -> Windows 11, version 24H2 (policy naming follows the pattern in the ADMX). Configure the policy as instructed by the ADMX (typically Enabled/Disabled depending on the ADMX semantics) and target the GPO with a WMI filter if needed. (video2.skills-academy.com)
• Force policy update on a pilot device (gpupdate /force) and reboot the device to validate the KIR applies and the update can then download/install without triggering 0x80240069. (video2.skills-academy.com)

Notes: KIR deployment is the safest enterprise approach because it is the sanctioned containment measure from Microsoft and avoids local system registry editing.

Option B — Registry override (fast, targeted, but riskier)​

Multiple community troubleshooters and Microsoft support staff have shared a registry override that bypasses the variant selection logic for the specific feature‑ID implicated in the failure. This is a blunt instrument and must be tested in a pilot ring before wide deployment.
Registry contents (REG file snippet):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\8\3000950414]
"EnabledState"=dword:00000001
"EnabledStateOptions"=dword:00000000
"Variant"=dword:00000000
"VariantPayload"=dword:00000000
PowerShell equivalent (suitable for scripted rollouts):
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\8" -Name "3000950414" -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\8\3000950414" -Name "EnabledState" -PropertyType DWord -Value 1 -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\8\3000950414" -Name "EnabledStateOptions" -PropertyType DWord -Value 0 -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\8\3000950414" -Name "Variant" -PropertyType DWord -Value 0 -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\8\3000950414" -Name "VariantPayload" -PropertyType DWord -Value 0 -Force | Out-Null
After applying the change, reboot and re‑run Software Center or the Windows Update scan to validate the install path is no longer hitting the variant logic bug. BornCity and WindowsLatest documented this override and attribute it to a Microsoft support workaround used during an earlier 0x80240069 incident. (windowslatest.com)
Risks for the registry approach:

• It intentionally bypasses variant selection logic; if legitimate feature variants were meant for specific devices, those variants could be blocked by the override. Test thoroughly.
• Registry edits are harder to audit and roll back across an estate than a GPO/MSI deployment. Keep clear runbooks and removal scripts.

Option C — Manual install from Microsoft Update Catalog (stopgap)​

For a small set of critical machines, downloading the KB5063878 MSU/CAB from the Microsoft Update Catalog and installing it manually (or applying with DISM) may succeed because it avoids the failing WSUS negotiation path. This is labour‑intensive and impractical at scale but can protect high‑value hosts while you deploy a KIR or test the registry override.

---

Diagnostic checklist for triage​

• Confirm affected builds: run winver or check OS build against KB5063878 (26100.4946). (support.microsoft.com)
• Collect Event Viewer logs from failing clients: look for “Unexpected HRESULT while download in progress: 0x80240069 WUAHandler”, svchost.exe_wuauserv crash traces, and any related ntdll.dll faulting module entries. (windowslatest.com)
• Verify update source: confirm whether failing clients are served by WSUS/SCCM or are getting updates directly from Microsoft Update; a difference in behavior is a key clue.
• Test the KIR on one or two pilot machines before wider rollout. Use GPO or Intune ADMX ingestion per Microsoft’s KIR documentation. (learn.microsoft.com)
• If using the registry override, test reversion steps and audit the change carefully: record exact registry keys, push with signed scripts where possible, and plan to remove the override once Microsoft issues the corrected LCU.

---

Risk analysis: strengths and potential drawbacks of Microsoft’s approach​

Strengths

• KIR is targeted: Microsoft’s Known Issue Rollback model disables only the problematic change and keeps the rest of the update installed. This reduces attack surface introduced by leaving an update uninstalled and minimizes operational disruption. (learn.microsoft.com)
• Enterprise‑ready deployment: KIR MSI + ADMX allows centralized Group Policy or Intune management in typical AD/Intune environments, which is far superior to ad‑hoc registry editing at scale. (video2.skills-academy.com)
• Fast containment possible: Enterprises can neutralize the regression quickly, minimizing failed installs and alert storms in their monitoring systems.

Potential drawbacks / risks

• Policy lifecycle management: KIRs are temporary and must be removed after Microsoft ships a corrected update. Failure to remove the policy could result in the variant logic remaining disabled longer than necessary, which might prevent intended variant deliveries. Organizations must track KIR lifecycles and remove policies promptly. (learn.microsoft.com)
• Operational complexity: Large estates will need to test ADMX ingestion, WMI filters, and applicability rules to target the KIR precisely. Misconfiguration could leave some devices unprotected or unnecessarily blocked. (video2.skills-academy.com)
• Registry override tradeoffs: While faster to roll out via script, the registry override is less transparent, more error‑prone, and can have unintended side effects for legitimate variant payloads. It’s a blunt instrument compared to KIR.

---

Shortcase: What the community learned from earlier incidents​

This problem echoes a near‑identical operational incident in April 2025 where the same 0x80240069 syndrome affected WSUS deliveries for Windows 11 24H2; Microsoft used a KIR followed by a corrected servicing update to fully resolve that issue. The repeat occurrence underlines two practical truths for administrators:

• Servicing logic and feature‑variant delivery create environment‑dependent failure modes; consumer testing does not always catch managed‑deployment regressions.
• Admin playbooks should include KIR testing and a validated process for applying and removing policy MSIs via GPO/Intune. The tools exist—using them early reduces the need for riskier interventions later. (learn.microsoft.com)

Community threads and troubleshooting logs collected in recent hours show the exact same diagnostics: WUAHandler unexpected HRESULT and a crashing wuauserv process. Those reproducible artifacts strengthen confidence that the variant logic path is the correct place to focus remediation.

---

Recommended action plan for IT operations (concise)​

• Immediately check your WSUS/SCCM pilot ring for 0x80240069 symptoms. Collect event logs and note build numbers. (windowslatest.com)
• If you see failures at scale, pause automatic WSUS approvals for KB5063878 in non‑critical rings and move critical machines to manual install or to a ring that can be updated directly from Microsoft Update.
• Prefer Microsoft’s KIR MSI + GPO route for enterprise remediation: download the MSI from Microsoft, install in your Group Policy management environment, configure the GPO and target with WMI rules to affected OS builds, then test and roll out. (video2.skills-academy.com)
• If you require an immediate short‑term fix and accept the risk, deploy the registry override to a small pilot and validate success; document rollback steps. Use signed scripts and rigorous change control. (windowslatest.com)
• Monitor Microsoft’s Windows Release Health dashboard and the KB article for an updated status and the eventual corrected LCU; remove KIRs and overrides once the permanent fix is available. (support.microsoft.com, neowin.net)

---

Longer‑term implications and takeaways​

• Servicing complexity is increasing. The combination of SSU + LCU and variant‑aware feature delivery improves staged rollouts and reliability in many cases, but it also magnifies the effect of corner‑case metadata or negotiation regressions in managed environments. Enterprises must maintain test rings that mirror production‑grade WSUS/SCCM flows to catch these environment‑specific failures.
• KIR as a toolchain is maturing into a reliable containment mechanism. Microsoft’s continued use of KIR + corrected LCU is operationally sensible—the temporary disablement of a specific change avoids uninstalling a broad security patch while preserving the ability to apply the permanent fix. However, KIR lifecycles add policy hygiene obligations. (learn.microsoft.com)
• Visibility and observability matter: collecting event logs, process crash dumps, and precise telemetry for wuauserv and Software Center is essential to a fast root cause diagnosis and timely remediation. Community reporting and vendor support channels proved their worth in this incident.

---

Conclusion​

The KB5063878 failure wave demonstrates how modern update ecosystems can produce environment‑specific regressions that disproportionately affect enterprise deployment paths. Microsoft’s response—publishing a KIR and guidance for Group Policy deployment while preparing a corrected servicing update—is the appropriate operational pattern: contain quickly, then remediate permanently.
For administrators: act swiftly but cautiously. Validate the issue in a representative pilot, prefer Microsoft’s KIR for broad remediation, and only use registry overrides as a last‑resort stopgap with documented rollback plans. Keep timelines and policy definitions under active management; KIRs are temporary and must be removed when Microsoft ships the corrected update. Monitoring the Windows Release Health dashboard and your event logs will be essential in the coming days as Microsoft issues the final servicing fix. (support.microsoft.com, learn.microsoft.com, windowslatest.com)

---

---

Source: Neowin Microsoft confirms Windows 11 KB5063878 can't install with 0x80240069 error, issues fix