Fix NS_E_BAD_CONTROL_DATA 0xC00D0032 Windows Media

This error means the server rejected malformed control data from the Windows Media Services client. Fix it by disabling UDP-based control or updating the client.

You're trying to stream from a Windows Media Services box and Windows Media Player spits out NS_E_BAD_CONTROL_DATA (0xC00D0032) — annoying, but it's a fixable protocol negotiation problem.

The Fix

In almost every case, the client is sending control commands over UDP when the server expects them over TCP. The Windows Media control protocol has a nasty habit of defaulting to UDP because it's cheaper, but plenty of WMS servers and firewalls silently mangle those packets.

On the client machine, open Windows Media Player.
Press Alt to bring up the menu bar, then go to Tools > Options.
Click the Network tab.
Under Streaming protocols, uncheck UDP.
Check TCP and HTTP. Leave Multicast off unless you actually run a multicast network.
Click OK, close WMP completely, and reopen the stream.

If you're using a WMS server running on Windows Server 2012 R2 or 2016 (the last versions that shipped WMS as a role), do the same thing on the server side: Server Manager > Windows Media Services > Properties > Control protocol, and untick Allow UDP control. The server will then insist on TCP for RTSP SETUP, PLAY, and TEARDOWN commands.

For a quick test from the command line, try forcing TCP with a client that respects RTSP transport:

curl -v --rtsp-request "SETUP" rtsp://media.example.com/stream.isml/Video"

You'll see the Transport header. If it says RTP/AVP/UDP and the server replies with 4xx, that confirms UDP is the culprit.

Why This Works

What's actually happening here is a mismatch at the RTSP layer. Windows Media Services uses RTSP for control (SETUP, PLAY, PAUSE, TEARDOWN), and that control channel can run over UDP or TCP. When a client fires off a SETUP with a UDP transport header, the server opens a random high port for the return path. Firewalls, NAT devices, and load balancers often rewrite or drop those packets because the port wasn't part of an established session. The server then receives something that doesn't parse as valid control data — corrupted header, truncated payload, wrong sequence number — and returns NS_E_BAD_CONTROL_DATA.

Switching to TCP fixes this because the control connection is now a single, stateful TCP session on a known port (usually 554 for RTSP). Firewalls track TCP state; they see the SYN, the handshake, and every control packet inside the same flow. Nothing gets rewritten, nothing gets dropped. The server parses clean control data, and the stream starts.

The reason step 3 through 5 in the client matter is that Windows Media Player's UDP preference is sticky per-user. Changing the registry key HKCU\Software\Microsoft\MediaPlayer\Preferences\Network\UDP to 0 does the same thing programmatically, but the UI is less error-prone.

Skip reinstalling WMP or resetting the network stack. Those almost never fix NS_E_BAD_CONTROL_DATA because the problem isn't local — it's the transport negotiation.

Less Common Variations

1. Proxy or reverse proxy in the path

An HTTP proxy that claims to support RTSP but doesn't actually parse it will pass garbage to the server. In WMP, go to Tools > Options > Network > Configure under HTTP and uncheck Use proxy for RTSP. Then retry.

2. Firewall doing deep packet inspection

Some enterprise firewalls (Palo Alto, Fortinet) inspect RTSP and rewrite the Transport header. You'll see the SETUP succeed but the PLAY fail with 0xC00D0032. Whitelist TCP/554 and TCP/1755 from the client subnet to the WMS server, and disable RTSP ALG on the firewall.

3. IPv6-only path with an IPv4-only WMS server

WMS never liked IPv6. If the client resolves the server to an AAAA record, control packets go over IPv6, and the server drops them. Force IPv4 on the client by adding a hosts entry or by disabling IPv6 on the NIC that talks to the media server.

4. SMB-style autodiscovery on the same NIC

On Windows 10 and 11, the Function Discovery Resource Publication service can interfere with the control port. If you see this error only after a reboot, stop and disable that service temporarily to confirm.

Prevention

Don't leave UDP control enabled on WMS if you're behind any NAT or firewall. The savings in latency aren't worth the debugging headache, and the error is silent on the server side — Windows Event Viewer logs it under Windows Media Services as event ID 3210, which most admins never check.

If you're still running WMS in 2025, plan a migration. Microsoft deprecated the role after Windows Server 2016 and hasn't shipped security patches in years. Move to IIS Media Services, Wowza, or an nginx-rtmp setup if you need to stay on Windows. Until then, harden the client defaults with a Group Policy preference that sets UDP=0 under the WMP Network key, so users can't re-enable the broken path.

And document it. The next person who sees 0xC00D0032 will spend an hour on network captures if you don't leave a note in the runbook. One line — "UDP off, TCP on, RTSP ALG off on firewall" — saves that hour.