MTP 2.3 writes TRX as tests finish, so a dead test host no longer erases the evidence

Since version 2.3, the Microsoft.Testing.Platform TRX reporter streams results while tests execute instead of waiting for a clean shutdown, so results already written to disk remain available as a valid partial report when the host terminates abruptly ^[1]. The consequence for CI owners is narrow but real: a crashed test host now costs you the results that had not finished, not the entire run's evidence ^[1][2].

The distinction matters because a report written only at the end disappears with the process, and a streamed one cannot resurrect a result that never completed but does preserve the work that did ^[1][2]. Three artifacts answer three different questions, and they are not substitutes. TRX says what completed ^[1]. The crash-sequence log names completed and in-flight tests, which narrows where execution stopped ^[3]. The dump may carry process state that explains why ^[5]. A dev.to walkthrough by ssukhpinder pairs the TRX report with `--crashdump --crashdump-type Mini --crash-sequence on`, noting that the sequence log is far smaller than the dump while still recording test progress ^[4][5].

The sample behind that walkthrough targets net10.0 with MSTest.Sdk 4.3.3, whose resolved MTP reporting and crash-dump packages come in at 2.3.3, which is on the streaming side of the 2.3 boundary ^[6][2]. Crash dumps are switched on with the `EnableMicrosoftTestingExtensionsCrashDump` property; the default MSTest runner profile already supplies TRX ^[7]. The author stays on TRX deliberately, because the JUnit, CTRF, HTML, and GitHub reporters are documented as experimental ^[8].

The demonstration is a three-test fixture: A passes, B calls `Environment.FailFast` only when the `DEMO_CRASH` environment variable is set to 1, and C should never start in the crash run ^[9]. The guard is the whole design; the verification script scopes the variable to the child process and restores the previous value afterwards ^[10]. The crash run adds `--report-trx --report-trx-filename crash.trx` to the crash flags and is expected to exit nonzero ^[11]. The assertions run after that: crash.trx must parse, must contain A's passed result, must not contain C, and the sequence text must name B ^[12]. Reported validation: three passing results in the normal run, and a controlled run that exited with code 7, kept A in the streamed TRX, omitted C, and named B in the crash sequence ^[13]. That is one surviving result out of three tests, which is exactly the arithmetic of a mid-run kill ^[1].

Two operational details are worth more than the demo. First, the Windows validation host did not produce the requested dump at all, because its native `createdump` tooling rejected the PID argument, and the verifier reports that as information rather than pretending every host can dump ^[14]. Dumps are the artifact you cannot rely on; the streamed TRX and the sequence log are the ones you can. Second, and this is the change to make in your pipeline: the evidence upload step has to run even when the test command fails, or the expected nonzero exit from the crash blocks the very step that makes the run legible ^[16]. The author also archives `crash.console.log` alongside the TRX and sequence so that tooling failures stay visible instead of vanishing into a red job ^[15].

What to watch: whether your agents can actually create dumps, since Microsoft's crash and hang dump documentation covers platform constraints as well as switches ^[5]; and whether the experimental reporters graduate, because a streamed JUnit or CTRF file would extend the same crash resilience to non-.NET dashboards ^[8].