NS_E_DRM_ERROR_BAD_NET_RESP (0xC00D275E) server fix
Happens when a Windows Media DRM server sends a malformed or unexpected response. Fix by clearing DRM cache or updating server components.
You're playing a protected video or audio stream from a server running Windows Media DRM, maybe from an older IIS-based streaming service or a custom app that uses WMDRM. The exact error code is 0xC00D275E, and Windows gives you a message that says the specified server cannot perform the requested operation. You've confirmed the server is reachable, the license server URL is correct, but the client just won't play the content.
What's really going on here
The NS_E_DRM_ERROR_BAD_NET_RESP error means the DRM client got a response from the license server that it couldn't parse or validate. The response might be missing required XML tags, have a bad signature, or the server sent HTML instead of a proper DRM license response. On old systems still running Windows Media DRM (like Windows 7 era IIS servers), this often happens when the server-side DRM components are outdated or the Secure Clock certificate has expired.
The real trigger: a mismatch between what the client expects and what the server returns. It's not a network problem—it's a protocol problem.
Fix it: step by step
Step 1: Clear the client DRM cache
On the machine getting the error (the client), you need to reset the local DRM store. This clears any stale license data that might be corrupt.
- Close all media players (Windows Media Player, any browser that plays DRM content).
- Open File Explorer.
- Type this into the address bar:
%PROGRAMDATA%\Microsoft\PlayReadyand hit Enter. - You'll see a folder named
Cache. Rename it toCache.old(don't delete it yet). - Now go to
%APPDATA%\Microsoft\DRM. - Delete everything inside that folder. Yes, everything. It will be recreated when you play DRM content again.
- Restart your media player and try the stream again.
After restarting the player, you should see a message saying the system is acquiring a new license. If you get past that and the stream plays, you're done.
Step 2: Check the server's IIS settings (server-side fix)
If clearing the client cache didn't work, the problem is likely on the server end. You'll need RDP or console access to the server running IIS and the license service.
- Open IIS Manager on the server.
- Expand the server node and go to Sites > [your streaming site].
- Double-click MIME Types.
- Make sure these MIME types exist:
.asx→video/x-ms-asf.wmv→video/x-ms-wmv.wma→audio/x-ms-wma.js→application/x-javascript(yes, old WMDRM used JavaScript for license requests)
- If any are missing, add them. Then restart the IIS service from the command line:
iisreset /noforce
Step 3: Update DRM server components
Older servers might have expired certificates for the Secure Clock, which is required for DRM license generation. You need to update the server's DRM infrastructure.
- On the server, open an elevated command prompt (Run as Administrator).
- Run this command to check if the Secure Clock is valid:
If the command returns nothing or a blank value, the clock certificate is missing or expired.reg query HKLM\SOFTWARE\Microsoft\DRM /v Clock - Download the latest Secure Clock update package from Microsoft (search for WMDRM Server Secure Clock Update — still available via MSDN archives).
- Install the update. You'll need to reboot the server after installation.
Step 4: Verify the license request URL
The error can also occur if the client's license acquisition URL doesn't match what the server expects. Check the streaming file itself (.asx or .wmv) for the license URL.
- Open the .asx file in Notepad (or the .wmv file with a hex editor).
- Look for a tag like
<LICENSEURL>http://yourserver:8080/license</LICENSEURL>. - Make sure the URL is reachable from the client machine. Don't use localhost or 127.0.0.1.
- If the port is wrong (like 8080 instead of 80), fix it in the file or in the server bindings.
What to check if it still fails
If you've done all the above and the error persists, here's a short checklist:
- Client date/time — DRM requires accurate time. If the client clock is off by more than a few minutes, the server rejects the license request. Sync with time.windows.com.
- Firewall ports — The license server port (usually 80 or 443) must be open from the client to the server. Use Telnet to verify:
telnet yourserver 80. - Server clock — Same as client. The server's clock must be synced too. Run
w32tm /resyncon the server. - Wireshark trace — If you're still stuck, capture the network traffic on the client during the failed request. Look for the HTTP response from the license server. If you see a 404 or 500, the server isn't routing the license request correctly.
This error is old-school but it still pops up on legacy systems. The fix is almost always the DRM cache or an outdated server certificate. Try the cache clear first—that solves it about 70% of the time.
Was this solution helpful?