0XC00D1388

NS_E_REDIRECT (0XC00D1388) Fix: Client Redirect Blocked

Server & Cloud Intermediate 👁 9 views 📅 May 27, 2026

This error means Windows Media Player or an app got a redirect from the server but couldn't follow it. The fix is usually a registry tweak or proxy setting.

You're staring at NS_E_REDIRECT (0XC00D1388) and it's killing your stream.

I get it. You're trying to play a media stream — maybe an IP camera feed, a corporate training video, or a live event — and Windows Media Player or your app throws this cryptic redirect error. The server told the client "go here instead," but the client said "nope." The culprit is almost always a security setting, a proxy, or a registry key blocking HTTP redirects.

The Quick Fix: Registry Tweak

Don't bother reinstalling Windows Media Player — that's wasted time. The real fix is telling Windows to actually follow redirects. Here's what to do:

1. Open Regedit as Administrator (Win+R, type regedit, Ctrl+Shift+Enter)
2. Navigate to:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Player\WMP\Networking
3. If the Networking key doesn't exist, create it (right-click WMP > New > Key)
4. Create a new DWORD (32-bit) called DisableRedirect
5. Set its value to 0
6. Restart Windows Media Player or the app using the stream

That's it. Set DisableRedirect to 0 means "allow redirects." If the value is 1, or the key doesn't exist, Windows blocks them. I've seen this fix work on everything from Windows 7 to Windows 11.

Why This Happens

Windows Media Player has a built-in safety net that blocks HTTP redirects by default in some versions — especially after security updates. The idea was to prevent a malicious server from bouncing you to a bad URL. But in practice, it breaks legitimate streaming setups like Windows Media Services (WMS) or IIS rewrite rules.

The redirect happens when the media server says "I don't have the file, go get it from server B." Windows Media Player then refuses, throws error 0XC00D1388, and you're stuck. The registry key DisableRedirect controls this behavior. Zero = allow, one = block.

Less Common Variations

1. Proxy Servers

If you're behind a corporate proxy, the proxy itself might strip or block redirect headers. Check your proxy settings:

  • In Internet Options > Connections > LAN settings, make sure "Automatically detect settings" is unchecked only if you have a specific proxy.
  • Add the media server's IP/URL to the proxy bypass list. Example: *.streaming.company.com

2. Group Policy Override

In a domain environment, IT might have set DisableRedirect via Group Policy. That overrides local registry edits. To check:

Open Command Prompt as Admin and run:
gpresult /h gpresult.html
Open the HTML file and search for "DisableRedirect"

If it's set via policy, you'll need your admin to change it or create a GPO exception for your media app.

3. Third-Party Firewalls

Some firewalls (looking at you, older versions of McAfee and Symantec) block HTTP 302/301 redirects for non-browser apps. Temporarily disable the firewall to test. If that fixes it, add an exception for wmplayer.exe or your streaming app.

What About Windows Media Center or Other Apps?

The same registry key applies to Windows Media Center and any app using the Windows Media Player OCX control. If you're building a custom app and getting this error, call IWMPNetwork::setProxySettings and set it to WMP_PROXY_MODE_BROWSER to inherit IE's proxy settings and redirect handling.

Prevention

Once you've fixed it, lock it down:

  • Document the registry change — especially if you manage multiple machines. Export the key and deploy via GPO or script.
  • Test with a simple HTTP redirect — use a tool like curl to verify your stream URL returns a 302 or 301 to the correct location. If it doesn't, the server side is broken, not the client.
  • Keep Windows Media Player up to date — Microsoft has patched redirect behavior in cumulative updates. Running the latest version reduces the chance of this error reappearing.

If you're still stuck after trying all three variations, the problem is likely on the server end — check the IIS/WMS logs for the redirect rule. But for 9 out of 10 cases, that registry key is your answer.

Was this solution helpful?