WSAEDESTADDRREQ 0X00002737: Missing socket address fix

What's actually happening here

WSAEDESTADDRREQ (0x00002737) is Winsock's way of telling you: "You tried to send data, but I have no idea where to send it." This isn't a network problem — it's a programming bug. The socket exists, it's open, but you never told it the remote address. On Windows 10 and 11 (and Windows Server 2012+), this error appears reliably when you call send(), WSASend(), or sendto() with a null or empty destination address structure.

The trigger is almost always the same: you mixed up connected vs connectionless socket semantics. TCP sockets require connect() before send(). UDP sockets require a valid address in sendto() — not send(). Get this wrong and Winsock returns 0x2737. The fix is simple once you understand which path you're on.

Cause 1: Calling send() on a UDP socket without connect()

This is the most common mistake. You create a UDP socket (SOCK_DGRAM), skip connect(), and then call plain send(). send() assumes a connected socket — it has no way to know the destination. Winsock doesn't guess; it throws WSAEDESTADDRREQ.

The real fix: Use sendto() instead. That function takes a destination address parameter. Or call connect() first — even on UDP — then you can use send() because the kernel remembers the address.

// Wrong — UDP with send() and no connect()
SOCKET s = socket(AF_INET, SOCK_DGRAM, 0);
send(s, buf, len, 0);  // WSAEDESTADDRREQ

// Fix 1 — use sendto() with the address
struct sockaddr_in dest;
dest.sin_family = AF_INET;
dest.sin_port = htons(12345);
inet_pton(AF_INET, "192.168.1.100", &dest.sin_addr);

sendto(s, buf, len, 0, (struct sockaddr*)&dest, sizeof(dest));

// Fix 2 — connect() first, then send()
connect(s, (struct sockaddr*)&dest, sizeof(dest));
send(s, buf, len, 0);  // Now works

Why does connect() work on UDP? Because it sets a default destination address on the socket. The kernel stores it internally. send() then uses that stored address. Handy if you only talk to one peer.

Cause 2: Connecting a TCP socket, but not waiting for the handshake

Less common, but I've seen it. You call connect() on a TCP socket and then immediately call send() before the three-way handshake completes. connect() returns immediately in non-blocking mode (or in some edge cases with SO_SNDBUF tricks). The socket isn't fully connected yet. Winsock sees a socket that hasn't finished connecting and rejects the send.

The fix: Use blocking mode, or check completion with select() / poll() / WSAEventSelect(). On Windows, connect() on a blocking TCP socket won't return until the handshake finishes — that's the safe path.

// Non-blocking connect — need to wait
SOCKET s = socket(AF_INET, SOCK_STREAM, 0);
u_long mode = 1;

ioctlsocket(s, FIONBIO, &mode);

connect(s, ...);  // Returns immediately, might not be done

// Don't send yet — wait for FD_CONNECT event
// Use select() or WSAEventSelect() to detect completion
// Then send() works

I'd argue you should start with blocking sockets unless you absolutely need async. They're simpler and sidestep this whole issue.

Cause 3: Using WSASend() with an invalid or null lpSendBuffers

If you're using the Winsock2 WSASend() function, there's a snag. You must supply a valid WSABUF structure array — not just a buffer pointer. If lpSendBuffers is NULL or dwBufferCount is 0, the function returns WSAEDESTADDRREQ even though the real mistake is parameter validation, not addressing.

I hit this once in a legacy codebase. The developer passed an empty buffer count. The fix was trivial: ensure at least one buffer is provided, with a non-null buf pointer and len > 0.

// Wrong — no actual buffers
WSABUF bufs;
bufs.buf = NULL;
bufs.len = 0;
DWORD sent;
WSASend(s, &bufs, 1, &sent, 0, NULL, NULL);  // WSAEDESTADDRREQ

// Correct
char data[] = "hello";
bufs.buf = data;
bufs.len = 5;
WSASend(s, &bufs, 1, &sent, 0, NULL, NULL);  // Works

This one's easy to miss because the error code doesn't scream "bad parameter." But Winsock's validation checks destination availability after buffer validity. If you trip the first check, you get this error.

Quick reference

Bottom line: 95% of WSAEDESTADDRREQ cases are case 1. If you're writing new code, always use sendto() for UDP sockets — it makes the address explicit. Save send() for TCP connections where the kernel's already holding the destination.