MediaElement/MediaPlayer cannot open any Internet-zone http(s) source on 10.0.11, and reports it as a pack-URI error

### Description

10.0.11 stops `MediaElement` and `MediaPlayer` from opening **any** Internet-zone `http://` or `https://` source. Every remote stream fails instantly with:

```
System.InvalidOperationException: Only site-of-origin pack URIs are supported for media.
```

Local `file://` sources still work. 10.0.10 and 10.0.9 play the same URLs normally.

This is not an accident - the code is in `MediaPlayerState.OpenMedia`, added in the 10.0.11 servicing release:

```csharp
// Default-credentials zone policy gate for the native media
// pipeline. Unlike the managed WpfWebRequestHelper path, the
// native media layer fetches the URI with system credentials
// by default and we cannot selectively suppress credentials
// from the managed side. To ensure default credentials are not
// sent to Internet/Untrusted-zone hosts, block those HTTP(S)
// URIs from reaching the native pipeline. ...
if (!CoreAppContextSwitches.DoNotApplyZoneCheckForDefaultCredentials
&& (uriToOpen.Scheme == Uri.UriSchemeHttp || uriToOpen.Scheme == Uri.UriSchemeHttps)
&& !MS.Internal.AppModel.DefaultCredentialsZonePolicy.ShouldSendDefaultCredentials(uriToOpen))
{
_mediaEventsHelper.RaiseMediaFailed(
new InvalidOperationException(SR.Format(SR.Media_PackURIsAreNotSupported, null)));
return;
}
```

The goal is reasonable. Three things about how it shipped are not, and each is a separate ask.

**1. The diagnostic points at the wrong thing.** `SR.Media_PackURIsAreNotSupported` is "Only site-of-origin pack URIs are supported for media." Reusing it for a zone-policy block tells a developer their **pack URI** is wrong when they passed an ordinary `https://` URL and no pack URI exists anywhere in the application. Nothing in the message, the `HResult` (`0x80131509`, the generic `InvalidOperationException` value) or the stack trace (`null`) mentions zones, credentials, security or a switch. It is not searchable either: at the time of writing, `Switch.System.Windows.Net.DoNotApplyZoneCheckForDefaultCredentials` returns zero hits across GitHub issues and `dotnet/docs`. A dedicated message naming the policy and the switch would turn a multi-hour bisect into one web search.

**2. Blocking the fetch is broader than suppressing the credentials.** The comment says default credentials cannot be selectively suppressed from the managed side, so the URI is blocked instead. But the overwhelming majority of WPF media playback - internet radio, podcasts, public video, RTSP - needs no credentials at all and never wanted them attached. Those scenarios pay the full cost of a protection they do not need, and the only available answer is a global escape hatch that turns the protection off for everything, including the cases that genuinely benefit. A per-`MediaElement`/`MediaPlayer` opt-out ("fetch this source anonymously"), or an anonymous fetch as the default for Internet-zone media with credentials attached only for Local/Intranet/Trusted, would serve the stated goal without ending remote media playback.

**3. It shipped undocumented, in a security release.** [CVE-2026-62897](https://github.com/dotnet/announcements/issues/434) is CWE-190, an integer overflow, and the advisory says nothing about media, zones or credentials. There is no breaking-change entry for this, and the switch that restores the previous behaviour is not documented anywhere I can find. Applying a security patch and silently losing all remote media playback is a bad shape for a servicing update, independently of whether the block itself is right.

### Reproduction Steps

Two files, no XAML, no packages.

`MediaRepro.csproj`:

```xml

WinExe
net10.0-windows
true
MediaRepro

```

`Program.cs`:

```csharp
using System;
using System.IO;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;

internal static class Program
{
[STAThread]
private static void Main(string[] args)
{
var url = args[0];
var log = new StreamWriter("repro.log") { AutoFlush = true };

var app = new Application { ShutdownMode = ShutdownMode.OnExplicitShutdown };

var element = new MediaElement
{
LoadedBehavior = MediaState.Manual,
UnloadedBehavior = MediaState.Manual,
Source = new Uri(url)
};
element.MediaOpened += (_, _) => log.WriteLine("MediaElement = MediaOpened");
element.MediaFailed += (_, e) => log.WriteLine("MediaElement = MediaFailed | " + e.ErrorException);

var player = new MediaPlayer();
player.MediaOpened += (_, _) => log.WriteLine("MediaPlayer = MediaOpened");
player.MediaFailed += (_, e) => log.WriteLine("MediaPlayer = MediaFailed | " + e.ErrorException);

new Window { Width = 200, Height = 100, Content = element }.Show();
element.Play();
player.Open(new Uri(url));
player.Play();

app.Run();
}
}
```

```
dotnet publish -c Release -r win-x64 --self-contained true -o out
out\MediaRepro.exe https://0n-60s.radionetz.de/0n-60s.mp3
```

To compare against 10.0.10, add a `Directory.Build.targets` beside the project and publish again. Note that neither the global `RuntimeFrameworkVersion` property nor `RuntimeFrameworkVersion` metadata on a `FrameworkReference` works for this - the first fails restore with `NU1102`, the second is silently ignored and ships 10.0.11 anyway:

```xml

```

Measured, same source, same machine, same minute:

| runtime | `PresentationCore.dll` | `https://` | `http://` | `file://` |
| --- | --- | --- | --- | --- |
| 10.0.11 | 10.0.1126.37416 | **MediaFailed** | **MediaFailed** | MediaOpened |
| 10.0.11 + switch | 10.0.1126.37416 | MediaOpened | MediaOpened | MediaOpened |
| 10.0.10 | 10.0.1026.32716 | MediaOpened | MediaOpened | MediaOpened |
| 10.0.9 | 10.0.926.27113 | MediaOpened | MediaOpened | MediaOpened |

`MediaElement` and `MediaPlayer` behave identically in every row. Self-contained and framework-dependent publishes behave identically. Two unrelated stream hosts behave identically. The 10.0.9 and 10.0.10 rows were also produced a second way, by overlaying only the WindowsDesktop runtime assemblies onto one already-published, otherwise byte-identical application, so the difference is the runtime alone.

### Expected behavior

A remote `http://` or `https://` media source opens and plays, as on 10.0.10 and earlier. If the fetch must not carry default credentials, it should be made anonymously rather than refused.

Failing that, the failure should say what actually happened and name the switch that changes it.

### Actual behavior

`MediaFailed` fires immediately with `InvalidOperationException: Only site-of-origin pack URIs are supported for media.`, `HResult 0x80131509`, `StackTrace` null. No pack URI is involved anywhere.

The URI never reaches Media Foundation. Loaded MF modules, same application and URL:

```
10.0.11: MFPlat.DLL
10.0.11 + switch: MF.dll, mfasfsrcsnk.dll, MFCORE.DLL, mfnetcore.dll, MFPlat.DLL,
mfps.dll, mfsrcsnk.dll, MFTranscode.DLL
10.0.10: MF.dll, mfasfsrcsnk.dll, MFCORE.DLL, mfnetcore.dll, MFPlat.DLL,
mfps.dll, mfsrcsnk.dll, MFTranscode.DLL
```

`mfnetcore.dll` is the Media Foundation network source; on 10.0.11 it is never loaded.

### Regression?

Yes, in 10.0.11 (2026-08-11) exactly. 10.0.10 and 10.0.9 both work.

### Known Workarounds

```xml

```

Verified: this restores playback on 10.0.11 with the full MF chain loaded.

It is a blunt instrument, though - source documents it as restoring "the previous behavior where every outgoing `HttpWebRequest` unconditionally has `UseDefaultCredentials = true`", so an application that wants remote media has to disable the credential protection for its non-media web requests too.

Pinning the runtime back to 10.0.10 also works and is what we shipped first, but it means declining CVE-2026-62897, which is worse. We are moving to the switch.

### Impact

Any WPF application that plays network audio or video stops playing anything on 10.0.11. The failure is total, not intermittent, and silent from the user's side: the application starts, its UI works, and no media ever plays.

It is invisible to ordinary build gates. Our full test suite stayed green throughout, because nothing in the application was wrong - the defect arrived with a runtime patch and only surfaces if something actually opens a remote stream during verification. We published a release carrying it before noticing.

Self-contained deployments make it worse: the runtime is baked into the artifact, so an already-shipped build cannot be repaired by patching the machine.

### Configuration

- .NET SDK 10.0.400; `Microsoft.WindowsDesktop.App` 10.0.11 (broken) against 10.0.10 and 10.0.9 (working)
- Windows 11 Pro 10.0.26200 build 26200, x64
- Reproduced self-contained and framework-dependent

### Other information

- Throw site: `src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/MediaPlayerState.cs`, in `OpenMedia`
- Reused string: `Media_PackURIsAreNotSupported` in `PresentationCore/Resources/ExceptionStringTable.txt`
- Switch: `Switch.System.Windows.Net.DoNotApplyZoneCheckForDefaultCredentials` in `PresentationCore/MS/internal/CoreAppContextSwitches.cs`
- Policy: `MS/Internal/AppModel/DefaultCredentialsZonePolicy.cs`

If only one of the three asks is actionable, the first is the cheapest and helps everyone who hits this next: a distinct message naming the zone policy and the switch, instead of the pack-URI string.

Start at src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/MediaPlayerState.cs, in OpenMedia, and reproduce with the supplied MediaRepro.csproj and Program.cs. Read PresentationCore/Resources/ExceptionStringTable.txt, CoreAppContextSwitches.cs, and DefaultCredentialsZonePolicy.cs. The narrowest completion is a distinct failure message naming the zone policy and switch; the per-player behavior and documentation asks require broader design decisions.

Written by the indexing model from the issue text.