Fix WSAEINTR (0X00002714) Blocking Call Interrupted Error

That WSAEINTR error is a pain — your app just stops dead during a network call, and there's no obvious reason why. Let's cut straight to what works.

The Quick Fix

The most common cause is your code calling WSACancelBlockingCall() while another blocking operation (like recv() or send()) is running. Windows throws WSAEINTR to say “hey, you interrupted me.”

Solution: Remove or guard any WSACancelBlockingCall() calls. If you must cancel, use non-blocking sockets and handle the shutdown yourself. Here's a minimal example:

// Instead of WSACancelBlockingCall, set a flag and close the socket
volatile bool cancelRequested = false;
// In the worker thread:
while (!cancelRequested) {
    int result = recv(sock, buffer, size, 0);
    if (result == SOCKET_ERROR) {
        if (WSAGetLastError() == WSAEINTR) {
            // Cancelled — exit gracefully
            break;
        }
        // Handle other errors
    }
}

Why This Works

The WSACancelBlockingCall() API is old and basically broken in modern Windows. It cancels the current blocking call but leaves the socket in an inconsistent state. Later calls can fail with WSAEINTR or even hang. Microsoft themselves recommend avoiding it since Windows 2000 — just use non-blocking I/O with select() or overlapped sockets instead.

I had a client last month whose entire print queue server kept crashing because a third-party library called WSACancelBlockingCall() inside a timer callback. Swapping to non-blocking sockets and a simple event loop fixed it overnight.

Less Common Variations

WSAEINTR can also pop up when:

• Message loop interference: If your main thread calls WSACancelBlockingCall() indirectly via SendMessage or PostMessage while a worker thread is doing a blocking socket call. Check for any cross-thread window messages that might trigger it.
• Antivirus or firewall hooks: Some security software injects a call to WSACancelBlockingCall() as part of their packet inspection. Disable the AV temporarily to test. If the error disappears, switch to using setsockopt() with SO_RCVTIMEO and SO_SNDTIMEO so blocking calls time out naturally.
• Third-party DLL hijacking: A buggy DLL loaded into your process might call WSACancelBlockingCall() accidentally. Use Process Monitor to find which module calls it — I've seen video drivers and old VPN clients cause this.

Prevention

Once you've fixed it, prevent recurrence:

1. Never use WSACancelBlockingCall(). Period. If you need cancelable I/O, use non-blocking sockets with select() or WSAEventSelect. Or use overlapped I/O with WSACreateEvent.
2. Set timeouts on blocking calls with setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (char*)&timeout, sizeof(timeout)). If a call times out, handle it cleanly instead of getting cancelled.
3. Thread-safe shutdown: When closing a socket from another thread, call closesocket() directly — it will cause any blocking call to return with WSAEINTR, which you can handle in your loop (as in the fix above). Don't use WSACancelBlockingCall().
4. Test with aggressive edge cases: Run your app under stress — rapid connect/disconnect cycles, low memory, high CPU. WSAEINTR often hides in race conditions that only show up under load.

Bottom line: WSAEINTR is almost always your code (or a library you use) calling WSACancelBlockingCall(). Rip that out, move to non-blocking I/O, and your problem disappears. I've never seen a case where keeping that API was the right answer.