Failed to set socket receive timeout: setsockopt returned {r

Error message

Failed to set socket receive timeout: setsockopt returned {ret}

What it means

Bailed when the Windows setsockopt call setting SO_RCVTIMEO on the accepted ETW subprocess socket returns non-zero (SOCKET_ERROR). The receive timeout is what makes read_line give up after RECORDING_TIMEOUT; when the option cannot be applied, session setup aborts rather than risk a permanently blocking read.

Source

Thrown at crates/etw_tracing/etw_tracing.rs:554

}

fn receive_command(stream: &mut net::UnixStream) -> Result<(Command, bool)> {
    use std::os::windows::io::{AsRawSocket, AsSocket};
    use windows::Win32::Networking::WinSock::{SO_RCVTIMEO, SOL_SOCKET, setsockopt};

    // Set a receive timeout so read_line returns an error after `timeout`.
    let millis = RECORDING_TIMEOUT.as_millis() as u32;
    let socket = stream.as_socket();
    let ret = unsafe {
        setsockopt(
            windows::Win32::Networking::WinSock::SOCKET(socket.as_raw_socket() as _),
            SOL_SOCKET,
            SO_RCVTIMEO,
            Some(&millis.to_ne_bytes()),
        )
    };
    if ret != 0 {
        bail!("Failed to set socket receive timeout: setsockopt returned {ret}");
    }

    let mut reader = BufReader::new(&mut *stream);
    match recv_json::<Command>(&mut reader) {
        Ok(command) => Ok((command, false)),
        Err(error) => {
            log::warn!("Failed to receive ETW command, treating as timed-out Save: {error:#}");
            Ok((Command::Save, true))
        }
    }
}

pub struct EtwSession {
    output_path: PathBuf,
    stream: BufReader<net::UnixStream>,
    listener: net::UnixListener,
    socket_path: PathBuf,
}

View on GitHub (pinned to f4178619ac)

Solutions

Call WSAGetLastError right after the failing setsockopt to identify the concrete reason code
Verify the elevated ETW subprocess stays alive after connecting (check its logs) — an immediate exit resets the socket
Retry the accept + setsockopt sequence once to ride out transient resets
As a diagnostic, run the elevated helper manually to see whether it fails at startup

Defensive patterns

Strategy: retry

Try / catch

Treat setsockopt failure as per-connection: log the WSAGetLastError code captured right after the call, drop that connection, and wait for the next accept instead of tearing down the ETW session.

Prevention

Apply socket options immediately after accept, before any reads
Verify the subprocess is alive when it connects (an immediate exit resets the socket)
Capture WSAGetLastError alongside the return code for diagnosable logs

When it happens

Trigger: The accepted socket is already closed or reset by a subprocess that died immediately after connecting, the socket handle is invalid, or a Winsock/provider-level condition rejects SO_RCVTIMEO — setsockopt returns non-zero and this bail fires.

Common situations: ETW helper crashing on startup so the peer RSTs before options are set; antivirus/firewall interference on the loopback socket; unusual Windows socket provider configurations.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/6ba56d3743d9b164. Report an issue: GitHub.