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

  • Thread Author
Microsoft has acknowledged multiple early regressions tied to the September servicing cycle even as Windows 11 version 25H2 begins rolling out, with two confirmed, actionable issues: a DRM/HDCP playback regression that can break Blu‑ray/DVD and some digital‑TV applications, and a separate WUSA (.msu) installation bug that can fail when installing updates from a network share containing multiple .msu files.

Illustration of Windows 11 25H2 regressions, featuring bugs and release notes.Background / Overview​

Windows 11 version 25H2 is being distributed as an enablement package layered on top of the 24H2 servicing stream rather than a ground‑up kernel release. That means many of the binaries are already present in 24H2 and the September servicing cadence (including preview updates published late August and September) carried changes that produced two narrow but painful regressions for specific scenarios. Microsoft has documented the protected‑playback problem in its Release Health / Microsoft Support notes and marked it as a known issue; a targeted remediation was staged to the Release Preview channel. Microsoft also described the WUSA/.msu network‑share failure and offered mitigations for managed environments while rolling out a fix via Known Issue Rollback for many devices.
Why this matters: for most everyday users who consume streaming video or use modern UWP/browser DRM paths, the regressions are invisible. For specific user groups—home‑theater PC owners, Blu‑ray collectors, broadcast/tuner users, kiosk/digital‑signage systems, and some IT deployment workflows—the impact can be directly service‑affecting. Community reporting and support threads show the same symptoms repeated across multiple environments, which is why Microsoft promoted a fix through Release Preview rather than a full rollback.

What Microsoft confirmed (the facts)​

  • Problem 1 — Protected playback failure in some Blu‑ray/DVD/Digital TV applications: Microsoft confirmed that after installing the August 29, 2025 preview update (KB5064081) or the September 9, 2025 cumulative update (KB5065426, OS Build 26100.6584), some applications that rely on the legacy Enhanced Video Renderer (EVR) with HDCP enforcement or platform DRM for digital audio may fail to play protected content. Symptoms include copyright‑protection errors, frequent interruptions, freezing, or black screens. Microsoft says streaming services using modern DRM pipelines were not broadly affected. Microsoft has staged a remediation to Release Preview (small preview update, KB5065789) and lists the issue on its known‑issues page.
  • Problem 2 — WUSA (.msu) installation failures from network shares: Microsoft also confirmed an issue where the Windows Update Standalone Installer (WUSA) may return ERROR_BAD_PATHNAME when attempting to install .msu packages from a network share that contains multiple .msu files. The behavior was traced to updates released on or after May 28, 2025 (beginning with KB5058499). Microsoft mitigated the problem for many consumer and non‑managed business devices using Known Issue Rollback (KIR) and advised managed environments to apply the KIR Group Policy or copy .msu files locally as a workaround. Independent reporting and community threads corroborate this guidance.
These are Microsoft’s official positions; timeline and KB identifiers are verified in Microsoft Support/Release notes and public Q&A entries.

Technical nuts and bolts: why these specific failures occurred​

EVR, HDCP, DRM — a brittle chain​

Protected playback in Windows historically relies on an end‑to‑end chain that includes the application, the platform DRM stack, the renderer (EVR in many legacy apps), GPU drivers, and the display (HDCP). This chain is intentionally conservative: if the platform cannot establish a trusted protected path, playback is designed to “fail closed” to satisfy content licensing rules. A servicing change that hardened or altered parts of this handshake can therefore break otherwise‑functional players if the legacy EVR path or a vendor driver does not match the tightened expectations. That exact interaction is what Microsoft cites as the cause of the playback regressions, and independent explainers in community forums and trade outlets echo that technical diagnosis.

WUSA and .msu handling​

WUSA uses the Windows Update Agent API to extract and install update packages (.msu). The reported ERROR_BAD_PATHNAME behavior only appears when an administrator runs WUSA or double‑clicks an .msu from a network share that contains multiple .msu files in the same directory. The presence of several .msu files apparently confused the installer’s path resolution or validation checks introduced or altered by the May/June servicing changes, producing the error. Microsoft’s short‑term recommendation for those who rely on WUSA is to copy .msu files to a local path before installing or use the Known Issue Rollback policy for managed devices.

Who is affected — scope and impact​

  • Affected (high‑impact, narrow population)
  • HTPC users who play physical Blu‑ray/DVD discs in legacy desktop players using EVR.
  • Digital TV/tuner capture apps and broadcast ingest tools that rely on the OS protected rendering paths.
  • Kiosks, digital signage, and lecture‑capture systems tied to legacy protected pipelines.
  • IT shops that deploy .msu files via WUSA from network shares containing multiple .msu files.
  • Not broadly affected
  • Consumers who primarily use streaming services and modern browser/UWP applications: these generally use their own DRM stacks or modern renderers (IMFMediaEngine/SVR) and were not widely reported as impacted.
  • Typical home users who receive automatic cumulative updates via Windows Update (many of whom were protected by Microsoft’s staging and KIR mechanisms).
Community forums and aggregated thread archives document multiple real‑world reproductions of the symptoms—black frames, copyright errors, and WUSA path errors—so this is not an isolated anecdote.

Mitigations and workarounds (practical, step‑by‑step)​

If you rely on affected playback or you manage update deployments, here are prioritized, practical mitigations.

For consumers and HTPC users (Blu‑ray/DVD/tuner playback)​

  • Pause installing the optional preview updates (KB5064081) and defer the September cumulative update if you use EVR‑based players for protected playback. Test before broad deployment.
  • If you have already installed the implicated updates and see playback failures:
  • Install the Release Preview remediation (the small preview fix Microsoft staged, KB5065789) in a test environment first to validate your specific player. Microsoft reports the fix has been staged to Release Preview; the official Support entry shows the playback problem is partially addressed in that build.
  • Try alternate playback software that uses modern Media Foundation APIs or browser‑based players that manage DRM internally.
  • Use a standalone hardware Blu‑ray player or an unaffected device as a short‑term fallback.
  • Keep GPU and display drivers up to date. Vendor drivers are a common weak link in the protected playback chain; coordinate with GPU/OEM support pages for validated driver versions.

For IT admins and enterprise deployments (WUSA / .msu)​

  • If you deploy .msu files from network shares, copy the .msu packages to a local folder on the target machine before running WUSA; this bypasses the network‑share path parsing issue.
  • Apply Microsoft’s Known Issue Rollback Group Policy if you manage environments where KIR is required to mitigate the behavior centrally; Microsoft has released guidance for managed devices.
  • Consider using alternative deployment methods for servicing offline or air‑gapped systems: extract the .msu and deploy the contained .cab via DISM or use your favored patch‑management tooling.
  • Monitor the Windows Release Health page and OEM advisories; Microsoft stages fixes to Release Preview for validation prior to broad rollout.

Timeline and confirmations (what we validated)​

  • May 28, 2025 — Microsoft published preview update KB5058499 (OS Build 26100.4202). Issues stemming from updates released on or after this flight were later implicated in the WUSA/.msu problem.
  • August 29, 2025 — Non‑security preview update KB5064081 was published and community testers first reported DRM playback regressions after this preview.
  • September 9, 2025 — Cumulative update KB5065426 (OS Build 26100.6584) consolidated the servicing changes and reproduced the playback problems in production environments.
  • Mid–late September 2025 — Microsoft acknowledged the EVR/DRM regression publicly on Windows Q&A and the Release Health/Support pages and staged a targeted fix to Release Preview (KB5065789). Microsoft’s Release Preview and support notes list the protected‑playback issue and indicate a partial resolution in the preview fix.
  • Microsoft also documented the WUSA ERROR_BAD_PATHNAME symptom and advised the workaround of copying files locally; mitigations for many consumer devices were rolled out via KIR, while managed customers were given a KIR Group Policy option.
Where dates, KB numbers, and build numbers are quoted above, they have been cross‑checked against Microsoft Support pages and the Release Preview blog posts.

Critical analysis — what this episode reveals about Windows servicing​

Strengths: staged rollout and surgical fixes​

Microsoft’s layered servicing model—preview builds, Release Preview validation, and Known Issue Rollback—worked as intended to limit broad damage. Rather than rolling back large security hardenings, Microsoft prepared a surgical remediation (KB5065789) and validated it in Release Preview first. For the WUSA problem, KIR allowed Microsoft to mitigate many consumer cases automatically without forcing enterprises through emergency patches. These are risk‑mitigation patterns that reduce blast radius compared with a full rollback of security updates.

Weaknesses: backward compatibility cost and test surface fragmentation​

However, the recurrence of regressions in legacy media paths underscores a persistent fragility: decades‑old APIs and renderers like EVR remain in real use and are easy to break when the platform tightens security or adjusts initialization sequencing. That fragility is compounded by a fragmented driver and middleware ecosystem (GPU drivers, audio middleware, tuner vendors), making complete pre‑release validation extremely challenging. The practical result is a trade‑off between improving security and preserving long‑tail compatibility; here, the security‑first changes produced legitimate user pain.

Risks to watch​

  • Residual breakage even after the Release Preview repair: because the protected path touches GPU drivers and firmware, mismatched driver versions could leave some users still blocked until vendor drivers are updated or validated.
  • Enterprise operational impact: organizations that depend on protected playback (training, compliance, broadcast ingest) may face downtime if they adopt updates without pilot testing.
  • Perception and trust: blocking playback of legitimately purchased content creates outsized frustration for affected households and hobbyists, and can drive heavy support demand.
Where Microsoft has not published full, low‑level root‑cause technical detail, vendors and admins must rely on staged fixes and hands‑on validation. Until a public post‑mortem appears, some environmental specifics remain necessarily partially unverifiable—treat those details cautiously and validate in your own lab before mass deployment.

Recommendations — short and long term​

For home users and hobbyists​

  • If you use a third‑party Blu‑ray/DVD player, HTPC, or TV tuner app: pause optional/unnecessary updates for a week or two until Microsoft confirms the fix has reached the general channel for your device. Test playback after any update.
  • Keep drivers current: check GPU and display firmware pages from the OEM, and install driver updates after you validate they are compatible with the patched OS build.
  • Use a hardware Blu‑ray player or alternate device if you need guaranteed playback immediately.

For IT admins and enterprises​

  • Expand your pre‑deployment test matrix to include legacy workflows: physical‑media playback, tuner/capture pipelines, EVR/DirectShow paths, and NetBIOS/SMBv1 fallbacks.
  • Apply the Known Issue Rollback policy where guided by Microsoft for managed devices and monitor Release Health telemetry before mass deployment.
  • For .msu deployments, change the default process: stage .msu files on a local share or local folder on target machines or use DISM to deploy the extracted .cab packages.
  • Run a small pilot that mimics production hardware (GPU, video capture, tuner cards) before broad rollouts and maintain tested rollback plans.

What remains uncertain (and what to watch next)​

  • Exact timeline for broad availability of the EVR playback fix in the general channel: Microsoft staged KB5065789 to Release Preview and described it as a partial resolution; the date for full inclusion in cumulative updates depends on validation telemetry and vendor coordination. Administrators and consumers should watch the official Windows Release Health and Support pages for the general‑channel release notice.
  • Comprehensive vendor responses: although Microsoft’s repair addresses the platform component, some GPU and capture drivers may still require updates. Confirm with OEM and capture‑card vendors whether they’ve validated the Release Preview fix against their drivers.
Any claims about complete resolution across all hardware configurations would be premature until the fix propagates widely and vendors confirm compatibility; treat such statements with caution and validate in your environment before wide deployment.

Conclusion​

Windows 11 version 25H2’s initial rollout highlights two important realities of modern OS servicing: improvements and security hardenings often ripple through decades of legacy APIs, and staged fixes (Release Preview, KIR) are Microsoft’s preferred mitigation strategy to limit mass disruption. For most users the regressions are contained and avoidable, but for AV‑heavy households, HTPC enthusiasts, broadcast operators, and admins who deploy .msu packages from network shares, these issues are material and require immediate mitigation steps—either by delaying the implicated updates, applying Microsoft’s staged fixes in a pilot, or using the practical workarounds described above. Microsoft’s public notes and staged fixes confirm the problem and the path to remediation, but until the fixes land broadly and vendors validate drivers, cautious testing remains the best practice.


Source: Windows Central Windows 11 version 25H2 has only just launched, but there's already issues to be aware of
 

Windows 11’s first public rollout of the 25H2 enablement package has landed with a familiar companion: early regressions that break specific workflows rather than the platform wholesale. Within days of the release, Microsoft confirmed two distinct, reproducible problems — a protected‑playback regression that can stop some Blu‑ray/DVD and digital‑TV applications from playing, and an update‑installation quirk where WUSA (.msu) installs from network shares can fail with ERROR_BAD_PATHNAME. Both are narrow in scope but high in impact for the affected users, and Microsoft has already staged targeted repairs and mitigations while advising cautious deployment for content‑critical systems.

Windows 11 25H2 Release Preview showing an “Error: Bad Pathname” alert.Background / Overview​

Windows 11 version 25H2 is being distributed as an enablement package layered on top of the 24H2 servicing branch rather than as a ground‑up feature release. That means most binaries and servicing behavior are inherited from the 24H2 branch and its recent cumulative updates. In late August and early September 2025 Microsoft shipped a preview servicing update (KB5064081) and a September cumulative (KB5065426) that folded the preview changes into the mainstream channel. Community signals — from feedback hubs, vendor forums, and media outlets — soon revealed a pair of regressions traced to that servicing sequence. Microsoft documented the problems on its Release Health / Support pages and began staging surgical fixes via the Release Preview channel while rolling out Known Issue Rollback (KIR) for many consumer devices.
The two confirmed problem areas are:
  • Protected‑content playback failures in some Blu‑ray/DVD and digital‑TV applications that use the legacy Enhanced Video Renderer (EVR) with HDCP enforcement or platform DRM for digital audio. Symptoms include copyright errors, freezes, black screens, or repeated interruptions. Streaming services and modern app‑managed DRM pipelines were widely reported as unaffected.
  • Installation failures when running .msu packages from a network share that contains multiple .msu files, where WUSA (Windows Update Standalone Installer) reports ERROR_BAD_PATHNAME. The failure does not occur if the .msu file is copied locally or the share contains only a single .msu. Microsoft provided KIR and Group Policy guidance for managed environments while advising the local‑copy workaround for administrators.

What Microsoft officially confirmed​

Microsoft’s Support notes and Release Preview release details make three concrete claims that shape the remediation path:
  • The protected‑playback problem started after the August 29, 2025 preview (KB5064081) and was carried into later cumulative builds, including the September 9, 2025 rollup (KB5065426). Microsoft lists the behavior in the known‑issues section and reports that streaming services are not affected.
  • A targeted remediation that partially resolves the EVR/HDCP playback regression has been staged to the Release Preview channel as a small preview update (packaged in builds like KB5065789). Microsoft explicitly documents that the Release Preview update addresses playback failures for some Blu‑ray/DVD and digital‑TV apps that enforce HDCP via EVR. The notes also caution that some audio DRM scenarios may still be impacted and that Microsoft is pursuing a long‑term fix.
  • The WUSA/.msu installation failure from network shares (ERROR_BAD_PATHNAME) affects devices that installed updates beginning with KB5058499 and later. Microsoft mitigated the issue for many non‑managed customers via KIR and published guidance for IT to deploy a KIR Group Policy or use the local‑copy workaround.
These confirmations are important because they reflect Microsoft’s triage pattern: preserve broad security hardening while delivering surgical repairs that restore legacy behavior where necessary. The decision to ship fixes through Release Preview and KIR instead of rolling back the underlying security changes indicates Microsoft judged the regressions narrow and the security changes material.

Technical deep dive: EVR, HDCP, DRM — where things broke​

To understand the playback regression, it helps to unpack the components involved and why a servicing update can cause a platform to “fail closed.”

What EVR does and why legacy players still use it​

The Enhanced Video Renderer (EVR) is a legacy compositor used by DirectShow and some older Media Foundation paths to present video frames on a trusted Direct3D surface. EVR historically supported a protected pipeline where decrypted video frames are rendered to secure surfaces that prevent copies or screen capture. Many third‑party Blu‑ray/DVD players and tuner/capture applications — particularly those developed before modern Media Foundation workflows became ubiquitous — still rely on EVR to meet DRM and HDCP requirements.

HDCP and platform DRM: a brittle, end‑to‑end chain​

HDCP is negotiated end‑to‑end between source (PC/GPU) and sink (display or capture device). Platform DRM (PlayReady, AACS, or proprietary audio DRM paths) coordinates with EVR and the GPU driver to ensure decrypted frames are never exposed to ordinary memory. This chain is deliberately conservative: if the OS can’t prove a secure path, it must fail closed to comply with licensing and content provider demands. A servicing change that alters initialization ordering, permissioning, or handshake semantics anywhere in that chain can break the path, causing legacy apps to receive “content protection” errors or simply display a black screen. That is precisely the pattern Microsoft identified.

Why streaming apps were spared​

Modern streaming clients and UWP/browser DRM flows typically use app‑managed DRM paths and newer rendering pipelines (Simple Video Renderer, MediaPlayer/IMFMediaEngine) rather than EVR. Because those flows bypass the legacy EVR secure surface semantics, they were widely reported as unaffected by this regression — a crucial detail that narrows both the root cause and the impacted population.

The WUSA / .msu network‑share failure explained​

WUSA uses the Windows Update Agent APIs to extract and apply .msu packages. Microsoft’s diagnostics show a parsing or path resolution regression that appears when multiple .msu files coexist in a network share. The runtime path parsing error manifests as ERROR_BAD_PATHNAME and — confusingly — can leave Update History reporting a pending restart even after the machine reboots (the UI state should correct itself after a short period). The issue traces to updates shipped on or after May 28, 2025 (KB5058499), and Microsoft has mitigated many consumer cases via KIR while providing KIR Group Policy guidance for managed environments. As an immediate workaround, administrators should copy .msu files to local storage before running WUSA, or deploy the contained CAB files via DISM/endpoint management tooling.

Who is affected — scope and real‑world impact​

The population impacted by these bugs is relatively small compared with the full Windows install base, but the pain is concentrated and acute for particular user profiles:
  • Affected (high impact, narrow group)
  • Home Theater PC (HTPC) owners who play physical Blu‑ray/DVD discs using legacy players built on DirectShow/EVR.
  • Users of digital TV tuner applications and broadcast capture software that rely on OS‑level HDCP enforcement for premium channels.
  • Kiosk, digital signage, lecture capture, and broadcast ingest scenarios that still use legacy protected rendering paths.
  • IT admins who deploy updates with WUSA from network shares, especially where bulk .msu repositories include multiple update files.
  • Not affected (or less likely)
  • Consumers who primarily stream video through modern apps or web browsers (Netflix, Disney+, Prime, etc.), since those clients use modern DRM and rendering pipelines.
  • Devices that don’t rely on WUSA network‑share installs or that apply updates via enterprise patch management systems that extract and apply packages differently.
Although the overall fraction of Windows users in the affected categories is small, the outcomes are real: inability to play legitimately purchased media, interrupted broadcast workflows, and deployment delays for enterprises that rely on scripted .msu installs.

Practical mitigations and step‑by‑step recommendations​

The short‑term response differs for home users, power users/HTPC owners, and administrators. Below are practical, prioritized steps.

For HTPC owners, home users and anyone who plays physical media​

  • Pause installing preview or September cumulative updates (KB5064081, KB5065426) on devices where protected playback matters. Use Windows Update deferral or block updates until Microsoft distributes the repair in the public channel.
  • If you've already installed the implicated updates and encounter failures, try the Release Preview remediation (KB5065789) in a controlled test or wait for the public cumulative that carries the fix. Microsoft staged the fix to Release Preview for validation; proceed cautiously if you enroll devices in Insider channels.
  • Use an alternate playback method (hardware Blu‑ray player, another machine without the update, or a modern player that uses Media Foundation/SVR) as an interim fallback.

For IT administrators and managed environments​

  • If you deploy .msu files from network shares, copy each .msu to local disk before running WUSA or use DISM to apply CABs extracted from the .msu. This bypasses the network‑share path parsing regression.
  • For broad remediation, ensure Known Issue Rollback (KIR) policy is applied where Microsoft has provided a KIR Group Policy; KIR can automatically mitigate many consumer and non‑managed device cases. Microsoft published guidance and the KIR mechanism has been used in prior servicing rollouts.
  • Pilot the Release Preview fix on a small representative ring before wide deployment. Validate protected playback and capture telemetry/logging before approving the fix for production.

Diagnostic checklist (quick)​

  • Confirm installed updates: Settings → Windows Update → Update history.
  • Reproduce the failure with the target application and capture Event Viewer logs.
  • If WUSA fails with ERROR_BAD_PATHNAME, copy .msu to local storage and rerun; wait 15 minutes post‑restart for Update History to refresh.

Timeline — how the regression surfaced and Microsoft’s response​

  • August 29, 2025 — Microsoft publishes an optional non‑security preview update (KB5064081). Early community testers later report playback failures tied to this preview.
  • September 9, 2025 — Microsoft ships the cumulative update KB5065426 (OS Build 26100.6584) via Patch Tuesday; the prior behavior is rolled forward and issues appear in production settings.
  • Mid‑September 2025 — Microsoft adds the EVR/HDCP playback failure to its Release Health known‑issues list and engages in targeted remediation planning.
  • September 17–29, 2025 — Microsoft stages a remediation to the Release Preview channel (packaged as KB5065789 and associated builds such as 26100.6718/26100.6725) to validate the repair before broader distribution.
  • Concurrently, Microsoft mitigates WUSA/.msu network‑share failures via Known Issue Rollback for many consumer devices and publishes guidance for managed deployments to use local copies or KIR Group Policy.
This staged approach allowed Microsoft to preserve the security and servicing improvements in the late‑summer updates while addressing narrow compatibility failures with surgical patches and rollback mechanisms.

Critical analysis — strengths, weaknesses, and risks​

Notable strengths in Microsoft’s handling​

  • Faster triage and transparency: Microsoft documented the issue publicly via Release Health and support pages rather than leaving customers in the dark, which helps administrators make informed decisions quickly.
  • Targeted remediation approach: Staging a focused fix to Release Preview and using Known Issue Rollback minimizes broad rollback risk while enabling controlled validation before pushing changes to all users. This preserves important security hardening while fixing the compatibility gap.

Notable weaknesses and operational risks​

  • Legacy surface fragility: The EVR/HDCP regression highlights how legacy APIs and protected rendering paths remain brittle. Vendor‑supplied players and long‑lived HTPC software are costly to rewrite, and servicing changes that tighten security can inadvertently break these paths. This is a structural risk for an ecosystem that still relies on older media stacks.
  • Poor optics for small but critical user groups: Although the affected population is small, the impact (inability to access paid media or run broadcast workflows) is immediate and tangible. Customers who rely on physical media or tuner capture are more likely to escalate, and enterprises running kiosks or signage face operational outages.
  • Patch distribution complexity: Using Release Preview and KIR is efficient, but it places an additional validation burden on admins who must pilot and test patches across specialized hardware and workflows. Organizations with constrained validation windows may face downtime or delayed rollouts.

Unverifiable or evolving claims — cautionary notes​

  • Some early reports on third‑party blogs and forums suggested additional, unrelated regressions (for example, broad SMB or Login failures) tied to the same servicing cycle. While Microsoft documented specific SMBv1 and PSDirect edge cases and provided mitigations, other anecdotes across forums vary in reproducibility and configuration. Administrators should treat anecdotal reports with caution and rely on controlled reproduction and Microsoft’s Release Health guidance.

Longer‑term takeaways for vendors, developers and power users​

  • Developers of media playback and capture software that still depend on EVR should prioritize migration to modern Media Foundation APIs (IMFMediaEngine, Simple Video Renderer) and app‑managed DRM flows. Those migrations reduce coupling to OS servicing changes and make apps more resilient to platform hardening.
  • OEMs, GPU driver vendors, and capture hardware manufacturers should update validation matrices to include hit‑list servicing scenarios and protected‑path tests. A servicing update that touches the DRM or display stacks must pass secure‑path test harnesses to avoid regressions that “fail closed.”
  • IT organizations must maintain robust pre‑production testing rings for content‑critical endpoints. Legacy workflows — HTPC, lecture capture, kiosks — need special consideration in Windows servicing plans.

Clear, actionable guidance (quick checklist)​

  • If protected playback is mission‑critical, defer installing the late‑August/September servicing updates until the Release Preview fix has been validated in your environment.
  • Copy .msu files locally before running WUSA; for enterprise deployments, use DISM or modern deployment tooling rather than clicking .msu files across network shares.
  • Monitor Windows Release Health and Microsoft Support updates for confirmation that KB5065789 or subsequent cumulative updates have been broadly released and validated.

Conclusion​

Windows servicing is a balancing act between hardening the platform and maintaining compatibility with a sprawling legacy ecosystem. The 25H2 rollout — delivered as an enablement package atop 24H2 — exposed two narrow but painful regressions: a protected‑playback failure that hits EVR/HDCP/DRM paths and an installation quirk that affects WUSA installs from network shares with multiple .msu files. Microsoft’s response has been orthodox: acknowledge, stage a surgical repair into Release Preview (KB5065789), and mitigate via Known Issue Rollback while advising practical workarounds for administrators. Those steps reduce the immediate pain but underline a recurring truth for Windows managers and developers: legacy subsystems like EVR are fragile in the face of servicing changes, and cautious testing remains essential for content‑critical systems. For users and IT teams who depend on Blu‑ray, tuner capture, or network .msu deployment workflows, the safest route today is conservative patching, local installation of update packages, and targeted pilot testing of Microsoft’s staged remediation before broad rollout.

Source: XDA Windows 11 25H2 has only just been released, and it's already causing issues
 

Back
Top