RunTestsShouldThrowOnStackOverflowException is still flaky. When a testhost crashes, the "Stack overflow." line can reach ErrorDataReceived late under thread-pool starvation (many hosts running in parallel on CI). The exit handler shared one 500ms budget with the process-exit wait and then blocked a thread-pool thread on it, so it both ran low on time and competed for the very thread that delivers the output it was waiting for. The callstack got dropped and the abort message was truncated to just the process path.

Decouple the stderr drain from the exit-wait budget, await the EOF signal instead of blocking it, and only spend the generous budget when the process exited abnormally. Clean exits keep a short grace period and the wait returns as soon as EOF arrives.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The generous stderr-drain budget is only meant for a genuine crash. When
we kill a still-running test host on purpose - aborting or cleaning up a
run from an IDE - it exits with a non-zero code that is indistinguishable
from a crash, so it would wait the full crash budget. If a grandchild
process (e.g. a browser driver) inherited the stderr handle and keeps the
pipe open, EOF never arrives and the abort hangs for seconds.

Record the processes we kill in TerminateProcess and treat their exit as
an abort (short drain), not a crash. A process that exited on its own is
never recorded, so a real crash still gets the generous budget needed to
capture a late callstack. Added a unit test for the budget selection.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The CancellationTokenSource that bounds the post-exit wait is created with a timeout, so it allocates a timer; dispose it via 'using' so we don't leak one per testhost exit when many hosts are spawned.

The stderr-drain test had been reduced to the already-drained fast path, so it could not catch a regression where EOF arrives just after the exit handler starts waiting. Make EOF land ~150ms into the wait so the test exercises waiting for a late ErrorDataReceived delivery and returning promptly, and keep a separate fast-path test for the already-drained case.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The late-EOF test from the previous commit signaled EOF from a Task.Run
with a Task.Delay, neither taking a CancellationToken. That trips
MSTEST0049, which is only a warning in Debug but an error in the Release
build CI runs - so the Windows leg failed at compile and every test was
skipped. That is why the build went red without a test actually failing.

Rewrite it without a timed background task: start the wait, assert it is
still in progress, then signal EOF and await it. That exercises the same
"EOF lands after the wait has started" path, but deterministically - no
sleep, no timing assertion that could itself flake - and without the
analyzer-tripping Task.Run/Task.Delay.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… returns promptly

The already-drained case is the common one on a clean exit; short-circuit before allocating the CancellationTokenSource and Task.Delay timer. Also tighten the late-EOF test so it fails if the wait ever ignored EOF and ran to the full timeout.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>