Fix WUSA ERROR_BAD_PATHNAME in May 2025 Windows Updates

Microsoft confirmed that a change introduced in updates released on May 28, 2025 (starting with KB5058499) can cause the Windows Update Standalone Installer (WUSA) to fail with ERROR_BAD_PATHNAME when installing .msu packages from a network share containing multiple .msu files — and that Microsoft is mitigating the problem using Known Issue Rollback (KIR) while providing a Group Policy-based workaround for managed environments.

Background​

Windows servicing in 2024–2025 continued Microsoft’s shared-servicing model, where feature code is staged in monthly cumulative updates and an enablement package or small KB flips feature flags for a versioned release. That same update pipeline is the environment in which the WUSA installation regression appeared: the Windows Update Standalone Installer (wusa.exe) is commonly used to install offline MSU packages and remains a widely used tool in enterprise maintenance, WSUS, and some helpdesk scenarios.
Microsoft published a formal notice in its Windows release health / update history pages that describes the symptom set, affected packages, recommended workarounds, and the availability of a KIR activation for non-managed devices and a Group Policy/KIR MSI for managed environments. The initial trigger was traced to updates released on May 28, 2025 (KB5058499) and later, per the Microsoft KB and subsequent reporting.

---

What’s happening (Symptoms summary)​

• WUSA (wusa.exe) may fail with error ERROR_BAD_PATHNAME when you double-click an .msu or run WUSA against an .msu located on a network share that contains more than one .msu file.
• The problem does not occur if:
• Only a single .msu file exists on the network share, or
• The .msu is stored and installed from a local path on the device.
• After installing an .msu with WUSA and restarting, Settings → Windows Update → Update history can temporarily indicate that a restart is still required; this is a display artifact and typically clears itself after a short wait (Microsoft specifically recommends waiting at least 15 minutes).

These symptoms were documented by Microsoft and echoed in independent reporting and community threads, which also captured reproductions and practical workarounds.

---

Why this matters​

Although WUSA is not the default update path for most home users (Windows Update cloud paths handle automatic updates), WUSA is still extensively used in:

• Enterprise offline maintenance and servicing workflows that rely on MSU files,
• WSUS and SCCM/ConfigMgr distribution scenarios where MSUs are stored on network shares,
• Administrative troubleshooting and manual patching of isolated/air‑gapped systems.

When installers fail midstream because WUSA cannot address an .msu on a share containing multiple packages, operational headaches appear: manual copy/transfer of files, helpdesk escalations, and possibly missed or delayed patching windows. For large fleets, even a seemingly small manual workaround multiplies into meaningful labour and compliance risk. Community and admin guidance therefore focused on rapid containment and enterprise-scale remediation.

---

Technical analysis: probable root causes and evidence​

Microsoft has not published a line-by-line root-cause breakdown in public KB text, but the available information — Microsoft’s KB notice plus community telemetry and forum analyses — points to the failure occurring in code paths used by WUSA when processing package lists and file paths on SMB shares. The error reported (ERROR_BAD_PATHNAME) indicates that WUSA or the Windows Update Agent API encountered an unexpected or malformed path value while enumerating or locking multiple MSU files on a network share. Community investigators observed the issue mainly where multiple MSU files existed in the same share — a reliable repro vector — and verified that copying the MSU locally avoided the error.
Further supporting evidence:

• Microsoft’s KIR activation (the standard mitigation for nonsecurity regressions that affect many consumer and non-managed business devices) and the fact Microsoft published a KIR MSI for Group Policy deployment point to an identified regression in an update component rather than corrupted MSU payloads. KIR is used to flip back a problematic behavioral change in the update stack while preserving the original update binary.
• Independent reporting from security/patch-news outlets reproduced the symptom and reiterated the Microsoft guidance to install MSUs from a local path or ensure only a single MSU exists on the network share.

Caveat: Microsoft’s public update history and KIR documentation describe the symptom and mitigations but stop short of a fully detailed engineering post-mortem at the time of the public notice; if deeper technical indicators (trace logs, stack dumps) are needed for forensic analysis, administrators should gather Windows Update logs (WindowsUpdate.log, CBS logs, and Event Viewer entries) and open a support case for direct Microsoft telemetry correlation. Where Microsoft later publishes a hotfix or postmortem, administrators should cross-check those artifacts against their logs.

---

Immediate workarounds and mitigation steps​

Microsoft’s guidance is explicit and pragmatic — implement the following to avoid encountering the ERROR_BAD_PATHNAME fault in the short term:

• Preferred local workaround (simple and reliable)
• Copy the .msu file(s) to the local drive of the target device and run the installer from a local path (double‑click or wusa.exe C:\path\to\file.msu). This reliably avoids the network-share path handling that triggers the error.
• Alternate temporary fix for Update History display artifact
• After installing an .msu and rebooting, wait at least 15 minutes before checking Update History in Settings; the page may otherwise show a stale “restart required” indicator. This is a UI timing/display issue and should self-correct.
• Managed environments — Group Policy KIR activation
• For domain-joined or otherwise managed devices that cannot rely on automatic KIR propagation via Windows Update, IT administrators can download and deploy the KIR policy definition MSI that Microsoft provided. After the MSI is installed into your PolicyDefinitions, you configure and enable the KIR activation in Group Policy and force a GP update so that devices apply the rollback. Microsoft documents the detailed Group Policy deployment flow (MSI install → Administrative Templates → enable/disable the KIR policy → gpupdate /force → restart).
• WSUS/ConfigMgr administrators
• If WSUS or on-prem distribution is in use, re‑sync WSUS metadata after Microsoft re-releases corrected packages (if Microsoft reissued the affected LCU). For critical systems, administrators can bypass WSUS and install an MSU manually (after copying locally) until the enterprise catalog is refreshed. Community reporting and Microsoft guidance both recommend local install bypass as a short-term operational approach.

---

Step-by-step: deploying the Group Policy KIR (practical)​

• Download the KIR MSI identified by Microsoft for the affected OS and KB (the published MSI name in Microsoft’s guidance references KB5062660 for the KIR ADMX artifact).
• On a Group Policy management host, run msiexec /i <KIR-MSI>.msi to extract and install the ADMX into C:\Windows\PolicyDefinitions (or use the TARGETDIR option to extract to a temporary folder for ingestion).
• Open Group Policy Management Console (GPMC) and create a GPO or edit an existing GPO targeted to the OU containing affected machines.
• Navigate to Computer Configuration → Administrative Templates → the specific KB KIR policy node and set the policy to apply the rollback as directed (the KIR policy typically provides a single enabled/disabled setting to flip the affected change).
• On client devices, run gpupdate /force or allow the policy to propagate (default policy refresh cycles can take 90–120 minutes). Restart the device to ensure the KIR takes effect.

Notes:

• Test the KIR in a pilot OU before full-rollout; KIR artifacts are reversible but are intended to be temporary until Microsoft publishes a corrective update.
• The KIR MSI names and the policy node labels include the KB number and issue identifier; follow Microsoft’s naming precisely when applying ADMX into centralized policy stores.

---

Impact analysis: home users vs enterprises​

Home users and personal devices

• Most non-managed devices will receive the KIR activation automatically via Windows Update; Microsoft uses KIR to protect consumer and non‑domain devices without administrator intervention.
• For individuals, the recommended action is minimal: copy MSUs locally before installing or allow the automatic KIR to resolve the problem. The majority of home users will see the issue resolved automatically in their update flow after Microsoft deploys the KIR.

Small businesses and unmanaged devices

• If devices are not domain-managed and the administrator lacks centralized patch control, rely on the automatic KIR propagation or use the local workaround (copy .msu to machine) for any manual installs. Keep an eye on Windows Update notifications indicating the KIR has been applied.

Large enterprises and managed fleets

• Enterprises cannot rely solely on automatic KIR distribution if they manage updates through WSUS, ConfigMgr, or third‑party patch management. These environments must:
• Deploy the KIR ADMX/MSI via Group Policy (or ingest the ADMX into Intune if using ADMX ingestion), and
• Re-sync WSUS catalogs and re-approve corrected packages when Microsoft reissues them.
• Operational impacts include rework to established offline patching pipelines, update-server synchronization, and possible helpdesk load for devices whose local copy/install workflows were affected. The guidance to copy .msu to local storage remains the simplest operational workaround for massed manual installs in scripted deployment workflows.

---

Practical recommendations for sysadmins and patch teams​

• Short-term triage
• If you run manual installs, always copy the MSU locally before executing WUSA. This is low-effort and avoids the problematic network-share code path.
• For any scripted deployment that mounts a share containing multiple MSUs, alter workflows to stage the specific MSU locally on the target before invoking wusa.exe or DISM.
• Deployment hygiene
• Re-synchronize WSUS catalogs after Microsoft publishes corrected packages and validate the WSUS package metadata. Approve the reissued update into your rings only after pilot validation.
• For ConfigMgr or other management tools that distribute MSUs from network shares, update packages to stage the files into the client cache or use content distribution mechanisms that avoid running WUSA directly against a network share.
• Monitoring and runbooks
• Collect WindowsUpdate.log, Event Viewer Application/System events related to wuauserv, and the CBS logs from impacted clients to detect and trace ERROR_BAD_PATHNAME or related 0x8024xxxx codes.
• Maintain a runbook that includes:
• Local copy + wusa install commands,
• KIR MSI install and Group Policy steps,
• DISM /Remove-Package guidance (only if the LCU removal is required) and system snapshot/rollback procedures.
• Document and track devices that have applied KIR to ensure reversion or reassessment after Microsoft releases a permanent fix.
• Test before wide rollout
• Always validate KIR policy application and reissued update behavior in a small pilot group (1–5%) before rolling out broadly. KIRs are designed to be temporary and safe, but every enterprise ecosystem includes peculiarities that can cause side effects.

---

What Microsoft did and the timeline for resolution​

• Microsoft published an advisory on the Windows release health / update history pages describing the symptom set and the temporary display issue; it confirmed the start of the incident affecting updates released May 28, 2025 (KB5058499) and later.
• To protect consumer and unmanaged business devices, Microsoft used Known Issue Rollback (KIR) to automatically mitigate the problem for most home users and non-managed business devices. For managed environments, Microsoft provided a KIR policy definition MSI and Group Policy guidance so admins could explicitly apply the rollback.
• Microsoft’s public messaging indicated the issue was under investigation and that additional information would be shared as it became available. Administrators were told to either wait for KIR to propagate, apply the GPO-based KIR, or use the local copy workaround while awaiting a full remedial update.

Note: while KIR is effective to roll back behavior for the vast majority of devices, it is a temporary mitigation. Microsoft usually follows KIR with a corrected cumulative update or servicing-stack change that removes the need for the rollback. After Microsoft publishes a full fix, the KIR activation is typically removed or becomes obsolete.

---

Risks, limitations, and unresolved questions​

• Limited public root-cause detail: Microsoft’s KB described the symptoms, the workaround, and the KIR mitigation but did not publish a detailed engineering root-cause analysis in the public KB text. That leaves some forensic questions unanswered until Microsoft releases a post‑mortem or updated KB entry with technical detail. Administrators needing deeper diagnostics should capture logs and engage Microsoft Support for telemetry-level correlation.
• WSUS/managed delivery complexity: on-prem delivery chains (WSUS, ConfigMgr) complicate automatic KIR propagation; enterprises must adopt the published Group Policy KIR workflow or manually stage corrected packages — both steps introduce procedural risk if not tested and documented.
• KIR coverage is not permanent: KIR is temporary and only appropriate for nonsecurity updates; enterprises must plan for eventual permanent fix rollout and KIR removal/reassessment. Failure to remove or re-evaluate KIR settings after a corrected update could mask residual issues or complicate future troubleshooting.
• Command-line caveats: combined SSU+LCU packaging is common in modern MSU files. Once an SSU is installed it is often permanent; trying to uninstall combined packages with WUSA /uninstall will not remove SSUs — removal for the LCU portion requires DISM /Remove-Package. Maintain rollback images and understand the SSU permanence characteristics when performing large-scale manual installs.

---

Bottom line and practical checklist (quick reference)​

• For single one-off installs: copy the MSU locally and run wusa.exe C:\path\to\update.msu; avoid double-clicking or running WUSA directly from a network share that contains multiple MSUs.
• For administrators managing fleets:
• Download and deploy Microsoft’s KIR MSI into Group Policy if your devices are managed (follow Microsoft’s Group Policy KIR guidance).
• Re-sync WSUS and validate reissued packages in a pilot ring before broad approval.
• Update automation and deployment scripts to stage updates locally prior to invoking WUSA or use image-based/distribution content to avoid direct network-share installs.
• Collect Windows Update logs and build a runbook for emergency manual remediation and rollback steps.
• Monitor Microsoft’s release-health pages and the KB for updates to the advisory and any subsequent permanent fixes that render the KIR unnecessary.

---

Conclusion​

The WUSA ERROR_BAD_PATHNAME issue is a practical, high-friction regression for administrative and enterprise patching workflows: it’s not a silent security hole, but it is a reliability problem that affects how offline and managed updates are applied. Microsoft’s decision to mitigate via Known Issue Rollback for consumers and provide Group Policy/KIR artifacts for managed environments reflects the company’s standard incident response for nonsecurity regressions in the servicing pipeline. Until a permanent corrected update is published, the documented mitigations — staging MSUs locally, deploying the KIR policy for managed fleets, and re-syncing WSUS — are the most reliable ways to restore normal update operations at scale. Administrators should treat this as a reminder to test update delivery channels (including WSUS/ConfigMgr metadata paths) and to keep runbooks that anticipate transient servicing regressions.

---

Source: Microsoft Support Windows 11, version 25H2 update history - Microsoft Support