0X000002C4: Expedited Receive Error on Windows Network Stacks

What's Actually Happening with 0X000002C4

You're seeing ERROR_RECEIVE_EXPEDITED (0X000002C4) — that's decimal 708 in the Winsock error table. It means a program tried to call recv() with the MSG_OOB flag (out-of-band data, also called expedited or urgent data) but the underlying socket couldn't deliver it.

TCP urgent data is rarely used today. Most apps that trigger this error are either legacy (pre-2005), poorly written, or misbehaving due to a corrupted network stack. The error signals that the receive buffer for urgent data is empty, invalid, or the connection state doesn't allow expedited reception.

You'll typically see this when running older games (like original Diablo II, Quake 3 era), certain financial trading apps, or industrial control software that uses Telnet or RSH with urgent data. On Windows 10/11, it's almost always a driver or app compatibility issue — not a hardware fault.

Cause #1: The App Is Asking for Urgent Data That Doesn't Exist

This is the most common cause. The application called recv(MSG_OOB) when the remote peer didn't send any urgent data, or sent it but it was already consumed by a previous call. TCP only allows one byte of urgent data in flight. If the app calls recv twice for the same urgent byte, the second call fails with 0X000002C4.

How to Fix It

1. Update or patch the application. Check the developer's website for a compatibility fix. For example, Diablo II's 1.14d patch removed the MSG_OOB calls entirely. If you're running an old game, look for a community wrapper like D2DX or CnCNet that strips out urgent data usage.
2. If the app is yours, fix the code. Don't call recv(MSG_OOB) unless you're sure urgent data is pending. Use ioctlsocket(FIONREAD) with SIOCATMARK first to check if the next byte is urgent. Or better — avoid urgent data entirely. Use a separate control connection or mark data with a byte-stuffing protocol instead.
3. For legacy apps you can't patch, try running them in Windows XP compatibility mode. Right-click the EXE, go to Properties > Compatibility, check "Run this program in compatibility mode for" and select Windows XP (Service Pack 3). This changes some internal Winsock behavior that may let the app behave.

// C++ snippet: proper check before MSG_OOB recv
// Returns 0 if at mark, SOCKET_ERROR otherwise
int CheckUrgentMarker(SOCKET s) {
    u_long atMark = 0;
    if (ioctlsocket(s, SIOCATMARK, &atMark) == SOCKET_ERROR)
        return -1;
    return (int)atMark;  // 1 = we're at the urgent data byte
}

If CheckUrgentMarker returns 0, don't call recv(MSG_OOB) — you'll get 0X000002C4. This isn't a Windows bug; it's the app not respecting TCP's urgent data semantics.

Cause #2: Corrupted or Mismatched Network Driver

Your network driver's Winsock provider might be mangling the TCP urgent pointer handling. This happens after a Windows update that replaced the driver, or after installing VPN software that injected a Layered Service Provider (LSP). On Windows 10 1903 and later, Microsoft deprecated LSPs, but some VPNs still install Winsock base service providers that can corrupt the stack.

How to Fix It

1. Reset Winsock to defaults. Open Command Prompt as Administrator and run:

   netsh winsock reset catalog
   netsh int ip reset reset.log
   

   Then reboot. This wipes out any third-party Winsock providers. You'll need to reinstall VPN software afterward — do that only after you've confirmed the error is gone.
2. Update your network driver directly from the chipset vendor, not through Windows Update. For Realtek, go to realtek.com. For Intel, use intel.com. For Killer/E2100, use the manufacturer's site. The driver Windows Update picks is often a generic Microsoft version that lacks bug fixes for urgent data handling.
3. If the error started after installing a VPN, uninstall the VPN, reset Winsock (step 1), then install the latest version of the VPN that supports Windows 11's Wintun driver instead of LSPs.

Why step 1 works: netsh winsock reset removes all custom Winsock providers (including those installed by VPNs, firewalls, and parental control software). The default provider (mswsock.dll) handles urgent data correctly. After reset, the app's MSG_OOB call talks directly to the TCP/IP stack without any intermediary that might corrupt the urgent pointer.

Cause #3: Remote Peer Doesn't Support Urgent Data

This is rarer but I've seen it in custom server implementations. Your app calls recv(MSG_OOB), but the remote server is actually sending data with the TCP PSH flag instead of URG flag, or the server's TCP stack ignores the urgent pointer. Some embedded devices (IoT, PLCs) strip the URG flag in their network stack.

How to Fix It

1. Capture traffic with Wireshark. Filter for tcp.urgent_pointer > 0. If you see zero urgent pointers in the TCP headers, the remote peer isn't sending urgent data, and your app is waiting for something that'll never arrive.
2. Configuration workaround on the client side: If you control the server, ensure it sets the URG flag and a non-zero urgent pointer. The typical pattern is: send one urgent byte (often 255) with the URG flag set, then follow with normal data.
3. If you can't change the server, you'll need to modify the client to not use MSG_OOB. Switch to regular recv() and handle the urgent semantics yourself using a byte marker protocol (like sending 0xFF followed by the actual data).

// Wireshark display filter to catch urgent data
// This shows only packets where the TCP urgent pointer is set
tcp.flags.urg == 1

Quick-Reference Summary

Most people hit Cause #1. Before tearing your hair out, check whether the application actually needs urgent data, or if it's just using it because some old SDK sample did. In 2024, there's almost no legitimate reason for a new app to use TCP urgent data — the semantics are broken by design (single byte, data boundary issues). If you're writing new code, use WebSockets or a simple control channel instead.