Fix zombie minidump server process blocking Windows auto-update

[acarl005]

Description

The minidump crash-reporting server can become a zombie process on Windows, holding a file lock on warp.exe and causing the Inno Setup auto-updater to fail with DeleteFile failed; code 5. Access is denied.

Root cause

Warp spawns a child process to run the minidump server for native crash reporting. The parent keeps the server alive by sending a ping every 5 seconds; the server's stale_timeout (10s) is supposed to reap dead client connections when pings stop arriving.

When the parent Warp process exits (cleanly or otherwise), the stale timeout correctly removes the dead client connection — but the minidumper crate's ServerHandler::on_client_disconnected trait method defaults to LoopAction::Continue. Since our Handler did not override it, the server loop kept running indefinitely after the last client was reaped, polling IOCP for new connections that would never arrive.

To be clear: the 10-second stale_timeout we pass to Server::run() does work — it successfully detects and removes dead client connections. But stale_timeout only controls connection reaping, not server shutdown. After reaping, the server calls on_client_disconnected(0) to ask whether to exit. Since the default implementation returns LoopAction::Continue, the server keeps its main loop running — listening on the Unix domain socket for new client connections that will never come.

Why this is a problem on Windows specifically

On Windows, a running process holds an exclusive file lock on its executable. The Inno Setup installer detects that the main Warp instance exited (via the single-instance mutex), but cannot replace warp.exe because the orphaned minidump server — a separate process using the same binary — is still running and locking the file. This causes a DeleteFile failed; code 5 error that blocks the entire update.

On macOS and Linux, replacing a running executable's file on disk is permitted by the OS, so this bug would not block updates on those platforms (though the zombie process itself is still undesirable).

Fix

Override on_client_disconnected on the minidump server's Handler to return LoopAction::Exit when num_clients == 0. This ensures the server process exits promptly after its parent disconnects, releasing the file lock on warp.exe.

Linked Issue

Closes #10202

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Testing

Analyzed a Windows process memory dump (.DMP) of a zombie Warp process using WinDbg (cdb.exe) to confirm the root cause:

• Confirmed the zombie was the minidump server (command line included minidump-server subcommand)

• Thread stacks showed the main thread blocked in GetQueuedCompletionStatusEx (IOCP poll inside minidumper::Server::run)

• Sentry threads (sentry-transport, sentry-session-flusher) were parked, confirming the server loop never exited to drop the Sentry guard

• Process had been alive for >24 hours with its parent long gone

• I have manually tested my changes locally with ./script/run

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Co-Authored-By: Oz oz-agent@warp.dev

[acarl005]

This is the default impl

https://github.com/EmbarkStudios/crash-handling/blob/a5553466deba758f3213756fd23778cf5336dc78/minidumper/src/lib.rs#L59-L61

[oz-for-oss]

@acarl005

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR updates the minidump server handler to exit the server loop when the last client disconnects, addressing orphaned minidump server processes that can keep the Windows executable locked during updates.

Concerns

• No blocking concerns found in the reviewed diff.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz