Microsoft.Testing.Platform Crash-Resilient TRX: Keep Evidence When the Host Dies

When a test process unexpectedly terminates, it is crucial to preserve evidence of what was completed and what was in progress at the time of the crash. Microsoft.Testing.Platform (MTP) crash-resilient TRX (Test Result XML) files provide a solution by writing completed results during the run, rather than waiting for a clean shutdown. This feature helps create a partial TRX file that contains the results even if the host dies abruptly.

The crash-resilient TRX also includes a crash-sequence artifact, which identifies completed and in-flight tests. This information turns an opaque infrastructure failure into evidence that can be archived and inspected later. The MTP 2.3 version introduced the TRX reporter that streams results while tests execute, ensuring that results remain available in a valid partial report even if the host terminates abruptly.

To enable this functionality, the sample project targets .NET 10 and uses MSTest.Sdk version 4.3.3. The project configuration enables Microsoft Testing Extensions Code Coverage and Crash Dump. The deterministic demonstration uses three test fixtures: Test A passes, Test B terminates the host when an environment variable is present, and Test C should never start in the crash run.

When running the test suite, the script first verifies the normal operation and parses the resulting TRX file. Then, it launches the guarded crash scenario with specific flags to produce a partial TRX file, a crash dump, and a crash sequence log. The important assertions ensure that the partial TRX is parseable, contains the passed result for Test A, does not contain Test C, and the sequence log identifies Test B.

The partial TRX and crash sequence provide valuable evidence even without a dump. In the verified sample, the controlled run exited with code 7, retained the completed result for Test A, excluded Test C, and identified Test B in the crash sequence. This evidence can be archived alongside the TRX and sequence log to provide a comprehensive picture of the test environment and behavior in case of unexpected terminations.

This approach is particularly useful for capturing evidence of abrupt test-host termination scenarios, such as native crashes, stack overflows, or failing fast paths. However, it is not necessary for ordinary failed assertions, as a normal TRX file already records such failures. The partial TRX contains only completed results, and the sequence log provides an indication of the likely in-flight test but does not prove the root cause.

Crash dumps are platform- and permission-sensitive, can be large, and may contain sensitive data from process memory. Store them securely with restricted access and short retention periods. The MTP crash dump mechanism requires .NET 6 or later and is not supported on .NET Framework. Additionally, the --crash-report option is limited to Linux and macOS.

For tests that experience stalls, consider using virtual time instead of waiting on the wall clock. The author's previous article, "The Test That Slept and the Test That Never Woke Up," covers this alternative approach.