zed-industries/zed · error

Unexpected status from subprocess: {other:?}

Error message

Unexpected status from subprocess: {other:?}

What it means

During the ETW recording handshake, launch_etw_recording() expected the elevated subprocess's first StatusMessage to be Started (or Error), but received another variant such as Stopped or TimedOut. Stopped/TimedOut are terminal states the child only sends after a recording session ends, so receiving one as the first message means the IPC protocol state machine desynchronized - typically a version mismatch between the parent process and the elevated child it spawned.

Source

Thrown at crates/etw_tracing/etw_tracing.rs:632

    let (stream, _) = listener.accept().context("Accept subprocess connection")?;

    let mut session = EtwSession {
        output_path: output_path.to_path_buf(),
        stream: BufReader::new(stream),
        listener,
        socket_path: sock_path,
    };

    let status: StatusMessage =
        recv_json(&mut session.stream).context("Wait for Started status")?;

    match status {
        StatusMessage::Started => {}
        StatusMessage::Error { message } => {
            bail!("Subprocess reported error during start: {message}");
        }
        other => {
            bail!("Unexpected status from subprocess: {other:?}");
        }
    }

    Ok(session)
}

#[derive(Debug, serde::Serialize, serde::Deserialize)]
#[serde(tag = "type")]
pub enum StatusMessage {
    Started,
    Stopped,
    TimedOut,
    Cancelled,
    Error { message: String },
}

#[derive(Debug, serde::Serialize, serde::Deserialize)]
#[serde(tag = "type")]

View on GitHub (pinned to f4178619ac)

Solutions

1. Restart Zed so parent and elevated child run the same binary, then retry the recording
2. Ensure only one Zed installation/version is in play (the elevated child is launched from std::env::current_exe(), so both come from the same path - check for concurrent updates or file replacement)
3. If it reproduces on a fresh same-version process, capture logs of both processes and report a Zed bug with the {other:?} payload

match launch_etw_recording(heap_pid, output_path) {
    Ok(session) => Ok(session),
    Err(err) if err.to_string().contains("Unexpected status from subprocess") => {
        // protocol/version mismatch: restarting the app realigns parent and child
        suggest_restart();
        Err(err)
    }
    Err(err) => Err(err),
}

When it happens

Trigger: accept() on the ETW Unix socket returns a stream whose first JSON line deserializes to StatusMessage::Stopped or StatusMessage::TimedOut instead of Started. Happens when the elevated child is a different Zed build than the running parent (exe replaced by an update/staged install between parent start and elevation), or a child bug sends the terminal status early.

Common situations: Zed auto-updated or the binary was swapped (e.g. cargo install / CI deploy) while an older instance was still running and then started an ETW recording; running mixed-version Zed binaries side by side where ShellExecuteW launches the new exe while the old parent expects the old protocol.

Related errors

• Subprocess reported error during start: {message}
• Socket closed before a message was received
• Failed to set socket receive timeout: setsockopt returned {r
• ShellExecuteW failed to launch elevated process (code: {resu
• Device lost: {err}

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