Microsoft Edge is not the process you started

Edge 151.0.4129.59, Windows 11, a clean profile directory, no other Edge instance running on the machine. Ward starts msedge.exe with a debugging port and watches it.

The spawned process exits after roughly sixty milliseconds, with a success status. Several seconds later, a different process writes DevToolsActivePort into the profile directory and starts listening on a loopback port. That second process is Edge. It is the browser window the operator can see. It is not the process that was started, and it is not a child of it in any way that survives the handoff.

Sixty milliseconds is fast enough that a launcher watching for an early exit will always see it, and slow enough that it does not look like a startup failure.

The code that waits for a browser to publish its debugging endpoint had a sensible short circuit: if the process exits before the endpoint appears, stop waiting and report that the browser died. That check is what makes a genuinely failed launch fail in two seconds instead of thirty.

On Edge, that check fires every single time, on a launch that is going perfectly well. The endpoint appears afterwards, and by then nobody is waiting for it.

The fix has three parts, and none of them is the obvious one.

Wait out a handoff grace period rather than trusting the exit. The spawned process exiting is now evidence of nothing on its own. The wait continues for a bounded period, looking for the endpoint file.

Find the successor by socket, not by command line. The obvious way to identify the right process is to look for one whose command line contains the profile directory. That does not work: on Windows, ProcessHandle.info().commandLine() is empty, including for processes you started yourself. A test asserting on it silently asserts nothing. The search is done by finding which process is listening on the loopback port the endpoint file names.

Hold a process handle, not a process. Once the successor is adopted, it has to be watchable and killable exactly like a process Ward spawned, so the session holds a handle rather than the original object.

Two related facts, both worth knowing before you build anything that supervises browsers on Windows.

ProcessHandle.info().command() and startInstant() do work for a process you did not spawn. It is only commandLine() that is unavailable. That combination is useful: process id plus start instant is enough to defeat pid reuse, which matters if you ever teach a supervisor to recognise its own orphans across a restart.

And DevToolsActivePort survives a previous run. If you do not clear it before launching, you will read a stale port, connect to nothing, and spend an hour investigating the wrong browser. Ward passes a port of zero, so the browser picks one, and reads back what it actually bound.

There is a second way to get no DevToolsActivePort, and it has nothing to do with Edge.

If a previous run of the manager was killed rather than closed, the browsers it started keep running. The next start clears the database rows that said those profiles were running, so the list now says "not running" and is wrong. Press start on one of those profiles and the command line goes to the orphan: Chromium's singleton owns that user data directory, the newly spawned process exits in milliseconds, and no endpoint file is ever written.

Same symptom. Completely different cause. The way to tell them apart is the lockfile in the user data directory, which is present exactly while a Chromium owns that directory and - measured on Chrome 151 on Windows - is absent again even after the browser is killed outright, because it is held with delete-on-close and Windows releases it regardless.

That makes it a good instrument for explaining a launch that has already failed, and a bad one for refusing a launch in advance. A false positive there would block a profile that was free, which is worse than the failure it was trying to describe.

If you supervise browser processes, the process you start is a request, not a handle on the thing you asked for. Watch the artefact the browser produces - the endpoint file, the listening socket - rather than the process you happen to have a reference to.

And when a launcher tells you a browser died, ask how it knows.