NS_E_NET_READ 0xC00D0015: Causes and Fixes

Windows Media Services throws NS_E_NET_READ when it can't read from the network socket. Usually a dropped connection, firewall kill, or dead NIC. Here's how to fix it.

You're streaming from a Windows Media server — could be a live feed, could be an on-demand WMV — and the client or the publisher drops with NS_E_NET_READ (0xC00D0015). Sometimes it happens the second a new client connects. Sometimes it waits ten minutes, then dies mid-stream. The event log on the server typically logs it right after a burst of TCP retransmits or a NIC reset message from the driver.

I've seen this on Server 2008 R2 boxes pulling RTSP feeds, on Server 2012 R2 doing multicast, and on a few 2016 boxes behind a WatchGuard. It's rarely the media codec and it's almost never the client. It's the socket.

What NS_E_NET_READ actually means

The full message is "The network connection has failed to read from the network" — but that's Microsoft being vague. In plain English: the Windows Media server (or the WMS-based component) asked the OS to read bytes from an open TCP or UDP socket, and the read call returned an error instead of data. The server gives up and surfaces 0xC00D0015.

That read can fail for three reasons:

The peer closed the connection (FIN or RST received out of nowhere — a proxy, firewall, or NAT device killed the idle socket).
The local NIC or driver dropped the socket — happens after a Team NIC failover or a power-saving reset on Realtek/Intel adapters.
The read timed out because packets aren't getting through — usually MTU mismatch, bad routing, or a saturated uplink.

The culprit here is almost always #1 or #2. Real-world example: a client is behind a Cisco ASA with a 30-minute idle timeout. The stream is buffered enough that no traffic flows for 31 minutes, the ASA drops the flow silently, and the next read on the server throws NS_E_NET_READ. Classic.

The fix

Check the event log first. Open Event Viewer and filter System and Application logs for Source WMServer, Windows Media Services, and the NIC driver name. You're looking for a NIC reset, a TCP retransmission warning, or a WMS error right before the 0xC00D0015 entry. That tells you which of the three causes you're dealing with.
Kill NIC power management. This is the one that bites people on Dell and HP rack servers with Broadcom NetXtreme or Intel I350 adapters. Device Manager → Network Adapters → your NIC → Properties → Power Management tab → uncheck Allow the computer to turn off this device to save power. Also open the Advanced tab and disable Energy Efficient Ethernet and Green Ethernet. Reboot. Don't skip the reboot — the driver won't pick it up otherwise.
Set the idle timeout on every intermediate device higher than your stream's longest silent window. On a Cisco ASA that's timeout tcp 01:00:00 in global config. On pfSense, Firewall → Advanced → Firewall Maximum States and adjust the TCP idle. On Fortigate it's config system session-ttl. If you can't change it upstream, enable keepalives on the WMS publishing point so the socket never goes idle.
Verify MTU end-to-end. A mismatched MTU produces this error under load but not at idle. From the server, ping the client with a large payload and DF set:
```
ping -f -l 1472 <client_ip>
```
If that fails but -l 1400 succeeds, you've got an MTU black hole — usually a VPN or PPPoE hop. Drop the NIC MTU to 1400 and retest.
Reset Winsock and TCP/IP if the stack itself is misbehaving. This is a last resort but it's saved me twice on servers that had been through a dozen driver updates:
```
netsh winsock reset
netsh int ip reset
netsh int tcp set global autotuninglevel=normal
```
Reboot. Autotuning on by default is fine on modern Windows; if some old tuning guide told you to disable it, re-enable it.
Update the NIC driver. Not from Windows Update — from Intel's or Broadcom's site, or the OEM's support page for your exact server model. Windows Update drivers are six to eighteen months behind and the read-failure bugs are exactly what gets fixed in the vendor releases.
Check for TCP chimney / RSS / VMQ conflicts. On Server 2012 R2 and later, virtualized media servers with VMQ enabled on Broadcom adapters will throw random network read failures under load. Run:
```
Get-NetAdapterVmq
Disable-NetAdapterVmq -Name "Ethernet"
```
Test for a day. If the errors stop, leave VMQ off unless you actually need it — and for a media server you usually don't.

If it still fails

Run a packet capture on the server with netsh trace start capture=yes tracefile=c:\wms.etl, reproduce, then stop it. Open the ETL in Network Monitor or convert with etl2pcapng and load in Wireshark. Look for the last packet before the failure — you'll see either a bare RST from a middlebox, or a run of retransmits with no ACK, or a zero-window from the client. Each one points to a different culprit.

Also test from a client on the same subnet as the server. If local works and remote fails, it's a network path problem, not the server. If both fail, the problem is on the server side — driver, Winsock, or WMS config.

And check the obvious: is the publishing point set to the right protocol? An RTSP publishing point fed by an HTTP source will throw network read errors when the protocol negotiation goes sideways. Match the transport end-to-end — RTP/RTSP source, RTP/RTSP publishing point, RTP/RTSP client. Don't mix and match unless you've tested it.

One more thing — if this is a load-balanced setup with two WMS nodes behind an F5 or HAProxy, check the idle timeout on the LB pool. I've lost a full day to a 60-second F5 default that was quietly killing every stream.