Build1 publisher3 min readPublished
MTP 2.3 writes TRX as tests finish, so a dead test host no longer erases the evidence
Microsoft.Testing.Platform streams results during the run instead of at clean shutdown. That only pays off if your CI uploads artifacts after a failing test step.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Starting with Microsoft.Testing.Platform (MTP) 2.3, the TRX reporter streams results while tests execute instead of waiting for a clean shutdown; if the host terminates abruptly, results already written remain available in a valid partial report. Microsoft documents the behavior in its MTP test-reporting guide.
- A report written only after a clean run can disappear with the process; a streamed report cannot recover a result that never finished, but it can preserve the work that did.
- MTP's crash-sequence artifact names completed and in-flight tests, helping identify what was running when the host disappeared.
- The author pairs TRX with two stable MTP crash-diagnostics options: --crashdump --crashdump-type Mini --crash-sequence on.
- The dump can contain process state for deeper debugging; the sequence log is much smaller and records test progress, so it can identify the test that was in flight. Microsoft's crash and hang dump documentation explains the switches and platform constraints.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
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].