Windows 11 25H2 Regressions: EVR DRM Playback and WUSA Install Issues

Windows 11’s 25H2 rollout landed with a familiar and unwelcome companion: early, narrowly scoped but consequential regressions that are already disrupting media playback workflows and manual update installs for a subset of users and organizations.

Background / Overview​

Windows 11, version 25H2 (the “Windows 11 2025 Update”) is being delivered primarily as an enablement package layered on top of the 24H2 servicing branch. That delivery model means the update flips on features already present in the codebase rather than replacing the entire OS image, producing a smaller, faster install for most devices. It also means any regressions introduced in recent servicing updates can carry forward into 25H2.
Microsoft’s Release Health page and multiple independent outlets confirmed the rollout and published a compact known‑issues list soon after availability. The two issues that are most relevant to end users and IT administrators are:

• A protected‑playback regression affecting some Blu‑ray, DVD and digital‑TV applications that use the legacy Enhanced Video Renderer (EVR) in combination with HDCP or platform DRM, producing copyright errors, freezes, black screens or interrupted playback.
• An installation quirk where the Windows Update Standalone Installer (WUSA) can fail with ERROR_BAD_PATHNAME when attempting to run a .msu package from a network share that contains multiple .msu files; the failure does not occur when the .msu file is copied locally or when only a single .msu file exists on the share.

Community reporting and forum analysis corroborate the incidents as reproducible in the field, and Microsoft has responded with targeted mitigations (a Release Preview remediation for the playback issue and Known Issue Rollback artifacts for some devices) while engineering works toward permanent fixes.

---

What Microsoft has officially confirmed​

The protected‑playback regression (EVR + HDCP / DRM)​

Microsoft lists the playback failure in its Windows 11, version 25H2 known issues and notes the problem is partially resolved. The company attributes many cases to changes introduced by the August 29, 2025 preview update (for example, KB5064081) and subsequent cumulative updates (for example, KB5065426). A targeted remediation addressing many EVR/HDCP scenarios shipped to the Release Preview channel in September (packaged as KB5065789 and later updates). Microsoft also warns that some applications using DRM for digital audio might continue to experience problems and that a permanent fix is still in progress.
Independent reporting confirms the same timeline and scope: affected apps are primarily legacy desktop players and hardware‑tethered TV or capture applications that still use EVR and DirectShow/Media Foundation pipelines. Modern streaming platforms and browser/UWP DRM flows are widely reported as not affected.

The WUSA / .msu network‑share failure (ERROR_BAD_PATHNAME)​

Microsoft documents a separate known issue where updates installed with WUSA may return ERROR_BAD_PATHNAME when the .msu is executed from a shared folder containing multiple .msu files. The company describes mitigations already staged (Known Issue Rollback for many consumer devices) and advises managed environments to apply the supplied Group Policy artifacts or to copy the .msu locally as a simple workaround until a permanent resolution is published. This problem was traced to servicing changes shipped across the May–September 2025 cadence and has been reported primarily in enterprise/offline deployment workflows.

---

Deep dive: the EVR / HDCP / DRM problem explained​

What breaks — specific symptoms​

Affected setups report one or more of the following:

• Copyright‑protection errors reported by the playback app or OS.
• Black screens or frozen frames where video should appear.
• Intermittent or persistent playback interruptions (stuttering/pauses).
• Whole‑system waits or app hangs in extreme cases.

These symptoms tend to appear only when playing protected content (Blu‑ray, DVD, or digital‑TV captures that require HDCP or platform DRM) under apps that still rely on the legacy Enhanced Video Renderer (EVR) or older DirectShow/Media Foundation paths. Streaming services that use modern app‑managed DRM do not appear to trigger the failure in the same way.

Why the platform “fails closed”​

Protected playback in Windows is an end‑to‑end handshake: app → platform DRM stack → renderer (EVR) → GPU driver → display (HDCP). The chain is purposely conservative: if any component cannot establish a trusted protected surface, the platform prevents playback to avoid content leakage. A servicing change that tighten checks or alters handshake semantics can therefore break legacy players that depend on earlier assumptions. In short: the platform enforces content protection by failing closed rather than risking unauthorized access. This is intended behavior for content licensing, but it produces an abrupt break for legacy software that still depends on older renderer semantics.

Which software and hardware are most likely to trip the bug​

• Desktop media players that implement DirectShow/EVR pipelines for physical media playback.
• Broadcast / tuner applications and capture‑card software that hand off protected frames through EVR.
• Kiosk/digital signage systems or classroom setups that play encrypted media via legacy renderers.
• Systems with out‑of‑date GPU drivers or devices where the driver does not expose the expected protected surfaces.

Conversely, web‑based streaming services and apps using modern Media Foundation pipelines are less likely to be affected because they use newer, app‑managed DRM flows.

---

Deep dive: the WUSA / .msu network install quirk​

What happens and when​

Administrators attempting to install an .msu using the Windows Update Standalone Installer (WUSA) from a network share that contains multiple .msu files may encounter ERROR_BAD_PATHNAME. The error reproduces when:

• The .msu is double‑clicked on a UNC path that points to a directory containing more than one .msu; or
• WUSA is invoked against a share with multiple .msu artifacts present.

The issue does not occur when only one .msu is on the share or when the target .msu is copied to a local disk and run from there. After installing and restarting, some devices may also show a brief UI quirk where Settings → Update History still indicates a reboot is required; Microsoft reports that this resolves automatically after a short interval.

Practical workaround and managed‑environment mitigations​

• Copy the .msu to a local drive (C:\Temp or similar) and run WUSA locally. This bypasses the path‑parsing bug entirely.
• For managed deployments, apply Microsoft’s Known Issue Rollback (KIR) artifacts via Group Policy or use WSUS/Intune channels instead of manual WUSA installs.
• For scripted offline deployments, prefer DISM or servicing stacks that work against mounted images rather than running WUSA from SMB shares.

---

Who is affected — scope and risk assessment​

The two regressions are narrow in scope but potentially high impact for affected users:

• Home theater PC (HTPC) owners, collectors who play physical Blu‑ray/DVD media, and operators of tuner/capture rigs are at the highest risk from the EVR/HDCP regression. For these users, the bug can render legitimately purchased or recorded media unplayable.
• IT administrators and small businesses that use manual .msu deployments from shared network repositories are prone to the WUSA ERROR_BAD_PATHNAME failure. This primarily affects offline or segmented environments that rely on manual installers rather than centralized Windows Update services.
• Most mainstream users who primarily consume streaming video, run modern UWP apps, or rely on automatic Windows Update channels are unlikely to see any impact. The issues are not platform‑wide regressions affecting everyday tasks for most consumers.

Risk grading (practical):

• High — specialized playback systems (EVR + protected content).
• Medium — enterprise/manual update workflows using WUSA from shared folders.
• Low — general consumer usage (streaming, modern apps).

---

Practical guidance: what to do now​

For home users and HTPC owners​

• If you rely on Blu‑ray, DVD or digital‑TV playback using legacy desktop players, delay upgrading to 25H2 or avoid installing the implicated 2025 servicing updates until Microsoft’s final fix is broadly available.
• If you’re already affected, check Windows Update → Release Preview channel for the targeted remediation (example packages delivered as KB5065789 and later). Install the latest updates and update GPU drivers from your hardware vendor.
• As a short‑term workaround, consider switching to a hardware Blu‑ray player or a different playback pipeline that does not use EVR where feasible.

For IT administrators and managed environments​

• Prioritize a pilot group before broad 25H2 deployment. Validate playback and update workflows across representative hardware and application stacks.
• For manual .msu deployments, copy .msu files locally before running WUSA, or stage updates via WSUS/Intune to avoid the network‑share parsing bug.
• Apply Microsoft’s Known Issue Rollback Group Policy if your fleet is experiencing WUSA failures and you require an organizational mitigation. Microsoft published KIR artifacts for affected branches.
• Update GPU and capture‑card drivers to the latest vendor releases; vendor driver updates frequently address handshake mismatch problems between OS and hardware. Test driver updates in a controlled environment before mass deployment.

A concrete, minimal test plan for administrators (numbered steps)​

• Identify a pilot sample of systems representative of the fleet (media machines, kiosks, imaging hosts).
• Snapshot or image those systems for rollback.
• Apply 24H2 + the desired servicing updates in the pilot; note pre‑ and post‑install behavior for protected playback and WUSA installs.
• If playback issues occur, attempt the Release Preview remediation package, update drivers, or revert to the snapshot.
• For WUSA, test the local‑copy workaround and deploy KIR if required.
• Document results and expand rollout only after confirmation.

---

Microsoft’s response and the strengths of their approach​

There are clear positives in Microsoft’s handling:

• Transparency: Microsoft promptly listed the known issues on its Release Health page and described mitigation steps, including a targeted Release Preview remediation for the EVR problem.
• Surgical mitigations: The use of Known Issue Rollback (KIR) and Release Preview staged fixes minimizes the blast radius and allows Microsoft to deliver corrective artifacts without forcing a full reversion.
• Actionable guidance: For administrators, Microsoft published concrete workarounds (local .msu execution, KIR Group Policy) that allow time for a proper fix while maintaining operational continuity.

These are exactly the kinds of pragmatic tools that enterprise IT teams need to stabilise large, heterogeneous fleets while engineering works on fixes.

---

Risks, weaknesses and longer‑term implications​

At the same time, the incident exposes systemic and practical vulnerabilities:

• Legacy subsystems are fragile. EVR and other long‑lived components remain in widespread use for niche but mission‑critical workflows (broadcast, archival playback). Service‑level tightening in the platform can inadvertently break those workflows. This is a structural risk as Microsoft continues to modernize Windows while retaining legacy APIs for backward compatibility.
• Staged rollouts can still surprise: Even with staged enablement and Release Health notices, the cadence of servicing updates means regressions introduced months earlier may only show up when the enablement package flips the feature or when other dependencies change. That lag complicates root‑cause analysis and increases the chance of user frustration.
• Operational complexity for small IT teams: The WUSA failure is emblematic of how small process changes (copying .msu locally) become necessary stopgaps. Organizations without robust patching infrastructure or with captive legacy devices pay the highest cost.
• Communications and expectations are uneven: Microsoft’s messaging correctly scoped the issue (limited scope, streaming unaffected) but some impacted users — especially hobbyist HTPC owners and small studios — have found the practical impact severe. Managing expectations across consumer, small business and enterprise audiences is challenging.

Finally, some broader claims circulating in social media and opinion pieces — for example, that the 25H2 rollout proves Microsoft’s decision to retire Windows 10 is an “ecological disaster” — are editorial and not verifiable technical conclusions. Those assertions mix sustainability arguments with product lifecycle and should be treated as opinion rather than demonstrated causation. Flagging such claims is important to keep technical reporting grounded in empirical facts.

---

Recommended checklist for a cautious 25H2 rollout​

• Verify which machines in your environment play protected media or use legacy capture drivers.
• Hold a pilot population and test EVR playback scenarios after each servicing update.
• Update GPU/capture drivers to vendor‑validated versions before enabling 25H2.
• Use Microsoft’s Release Health page to track remediation progress and install Release Preview fixes where appropriate.
• For manual .msu installs, copy packages locally or retain a single .msu file per share to avoid ERROR_BAD_PATHNAME.
• Maintain reliable rollback images and test restores as part of your deployment window.

---

Final analysis and bottom line​

The Windows 11 25H2 enablement package is a low‑friction delivery vehicle for most users, but it also demonstrates the inevitable tradeoffs of a servicing‑centric model: small, surgical regressions in rarely used subsystems can produce outsized disruption for niche but important workflows. Microsoft’s early transparency, targeted Release Preview remediation, and Known Issue Rollback artifacts reduce the operational impact, but they don’t eliminate it.
For most consumers the risk is low — streaming services continue to work, and routine productivity workflows are unaffected. For HTPC owners, broadcast/capture professionals, and administrators who run manual .msu deployments from network shares, the immediate best practice is caution: delay non‑essential upgrades, apply targeted remediations and vendor driver updates, and follow the local‑copy workaround for WUSA installs until Microsoft issues broader fixes.
The episode is a reminder that even conservative servicing changes can ripple through legacy chains in unexpected ways. The responsible course for both hobbyists and IT teams is to test, be conservative with rollout windows, and apply Microsoft and vendor mitigations as they become available.

---

Conclusion: 25H2 is functionally safe for most users, but not yet safe for every workflow. Prioritize pilot testing and use the simple local‑copy workaround for manual .msu installs while Microsoft finishes permanent fixes for EVR/HDCP and associated DRM scenarios.

---

Source: myhostnews.com Windows 11 25H2: the new update already plagued by bugs