Uh oh!
There was an error while loading. Please reload this page.
Add --crash-report option to the CrashDump extension - #8191
Conversation
Co-authored-by: Evangelink <11340282+Evangelink@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Extends the CrashDump MTP extension with new --crashreport and --crashreport-only options that wire the test host runtime variables DOTNET_EnableCrashReport / DOTNET_EnableCrashReportOnly and publish the resulting *.crashreport.json as artifacts.
Changes:
- New CLI options with mutual-exclusion validation (
--crashreportrequires--crashdump;--crashreport-onlyexcludes the others). - Environment variable provider sets the new runtime variables (and keeps
DbgEnableMiniDumpfor--crashreport-only); lifetime handler emits new "dump only / report only / dump + report" messages and publishes crash report artifacts. - New resx/xlf entries, PACKAGE.md doc update, unit/acceptance/help-info test coverage for the new options.
Show a summary per file
| File | Description |
|---|---|
| src/Platform/Microsoft.Testing.Extensions.CrashDump/CrashDumpCommandLineOptions.cs | Adds option name constants for the two new flags. |
| src/Platform/Microsoft.Testing.Extensions.CrashDump/CrashDumpCommandLineProvider.cs | Registers new options and adds combined-options validation via chained ternary. |
| src/Platform/Microsoft.Testing.Extensions.CrashDump/CrashDumpEnvironmentVariableProvider.cs | Sets/validates DOTNET_EnableCrashReport(Only) and conditionalizes DbgEnableMiniDump. |
| src/Platform/Microsoft.Testing.Extensions.CrashDump/CrashDumpProcessLifetimeHandler.cs | Picks crash message variant; publishes .crashreport.json artifacts in addition to dumps. |
| src/Platform/Microsoft.Testing.Extensions.CrashDump/Resources/CrashDumpResources.resx | New resource strings for descriptions, errors, and crash messages. |
| src/Platform/Microsoft.Testing.Extensions.CrashDump/Resources/xlf/*.xlf | Auto-added state="new" entries mirroring the resx additions across all locales. |
| src/Platform/Microsoft.Testing.Extensions.CrashDump/PACKAGE.md | Documents new crash report capabilities. |
| test/UnitTests/Microsoft.Testing.Extensions.UnitTests/CrashDumpTests.cs | Adds unit tests for valid/invalid combinations of the new flags. |
| test/IntegrationTests/Microsoft.Testing.Platform.Acceptance.IntegrationTests/CrashDumpTests.cs | Acceptance tests for dump+report, report-only, and --crashreport without --crashdump. |
| test/IntegrationTests/Microsoft.Testing.Platform.Acceptance.IntegrationTests/HelpInfoAllExtensionsTests.cs | Updates expected help/info output to include the new options. |
Copilot's findings
- Files reviewed: 22/22 changed files
- Comments generated: 3
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…shDump tests/code - Reorder --crashreport / --crashreport-only after --crashdump-type in the Help and Info expectations to match the platform's alphabetical ordering (CommandLineHandler.PrintOptionsAsync OrderBy(option.Name)). - Refactor CrashDump option validation into explicit if-statements for clarity. - Rename EnableMiniDumpValue -> EnabledValue (now reused for crash report vars). - Make CrashReportOnly_CustomDumpName_CreateOnlyCrashReport robust on Windows by doing an exact filename comparison instead of relying on Directory.GetFiles pattern matching, which can match 'customdumpname.dmp.crashreport.json'. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Revert the validation refactor, EnabledValue rename, and the Windows-safe filename check in CrashReportOnly_CustomDumpName_CreateOnlyCrashReport. The HelpInfoAllExtensionsTests ordering fix is preserved. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Copilot's findings
Comments suppressed due to low confidence (1)
src/Platform/Microsoft.Testing.Extensions.CrashDump/CrashDumpProcessLifetimeHandler.cs:1
- Mirror of the existing dump-fallback path: if
Path.GetDirectoryName(expectedCrashReportFile)returns an empty string (when the dump file pattern is just a filename with no directory component),Directory.GetFiles("", ...)will throwArgumentException. The pre-existing dump branch has the same issue, but consider falling back to the current directory or skipping the scan when the directory is empty so the new code path doesn't introduce another instance of the same brittleness.
// Copyright (c) Microsoft Corporation. All rights reserved.
- Files reviewed: 22/22 changed files
- Comments generated: 8
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
- CrashDumpCommandLineProvider: replace chained ternary with explicit if-statements for clarity and easier extension. - CrashDumpEnvironmentVariableProvider: rename EnableMiniDumpValue to EnabledValue since it's now reused for the crash report environment variables (DOTNET_EnableCrashReport / DOTNET_EnableCrashReportOnly). - CrashReportOnly_CustomDumpName_CreateOnlyCrashReport: do an explicit filename comparison instead of relying on Directory.GetFiles' pattern matching, which on Windows can also match 'customdumpname.dmp.crashreport.json' for the literal pattern 'customdumpname.dmp'. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Amaury Levé (Evangelink)
commented
May 14, 2026
Copilot address review comments |
Co-authored-by: Evangelink <11340282+Evangelink@users.noreply.github.com>
Amaury Levé (Evangelink)
commented
May 18, 2026
Copilot address review comments |
| { | ||
| await _outputDisplay.DisplayAsync(this, new ErrorMessageOutputDeviceData(string.Format(CultureInfo.InvariantCulture, CrashDumpResources.CannotFindExpectedCrashDumpFile, expectedDumpFile)), cancellationToken).ConfigureAwait(false); | ||
| foreach (string dumpFile in Directory.GetFiles(Path.GetDirectoryName(expectedDumpFile)!, "*.dmp")) | ||
| { |
There was a problem hiding this comment.
Already addressed in 8763b96 — the *.dmp fallback enumeration is now filtered with Path.GetExtension(f).Equals(".dmp", StringComparison.OrdinalIgnoreCase) so a customdumpname.dmp.crashreport.json (or any other extension that merely starts with .dmp) cannot leak through (CrashDumpProcessLifetimeHandler.cs:109-110).
| public Task<ValidationResult> ValidateCommandLineOptionsAsync(ICommandLineOptions commandLineOptions) | ||
| => ValidationResult.ValidTask; | ||
| => commandLineOptions.IsOptionSet(CrashDumpCommandLineOptions.CrashReportOptionName) | ||
| && RuntimeInformation.IsOSPlatform(OSPlatform.Windows) | ||
| ? ValidationResult.InvalidTask(CrashDumpResources.CrashReportNotSupportedOnWindowsErrorMessage) | ||
| : ValidationResult.ValidTask; |
There was a problem hiding this comment.
Already addressed in 8763b96 — the --crash-report option description in CrashDumpResources.resx:182-184 and PACKAGE.md:18,24 both explicitly state "Requires .NET 7+ when used alone; .NET 6+ when combined with --crashdump" and call out "This runtime requirement is not enforced by the tool: on unsupported runtimes no crash report will be emitted." That meets the "at minimum, the help text should make clear" bar. Surfacing a warning at runtime would require detecting the runtime version up-front, which we deliberately punted as out of scope for the initial PR.
| string optionNameIndent = new(' ', indentLevel * 2); | ||
| string optionInfoIndent = new(' ', (indentLevel + 1) * 2); | ||
| foreach (CommandLineOption option in options.OrderBy(x => x.Name)) | ||
| foreach (CommandLineOption option in options.OrderBy(x => x.Name, StringComparer.Ordinal)) |
There was a problem hiding this comment.
Noted. The sort change in CommandLineHandler.cs:113-116 was subsequently softened to StringComparer.OrdinalIgnoreCase (per r3258181853) so casing differences also sort stably. The visible-order change will be picked up by the next platform release notes when that bundle is assembled — there's no standalone changelog file in this repo to update for an in-flight MTP change.
- CrashDumpProcessLifetimeHandler: filter the *.dmp fallback enumeration by exact extension (case-insensitive) so Windows 8.3 short-name matching cannot re-publish *.dmp.crashreport.json files as dump artifacts. - CrashReportOptionDescription: explicitly state that the .NET runtime requirement is not enforced by the tool and that no report is emitted on unsupported runtimes. - CommandLineHandler: document the rationale for using StringComparer.Ordinal for option ordering (deterministic across TFMs, user-visible). - Updated HelpInfoAllExtensionsTests expectations and regenerated XLF files for the CrashDump resource change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| { | ||
| await _messageBus.PublishAsync(this, new FileArtifact(new FileInfo(dumpFile), CrashDumpResources.CrashDumpDisplayName, CrashDumpResources.CrashDumpArtifactDescription)).ConfigureAwait(false); | ||
| await _outputDisplay.DisplayAsync(this, new ErrorMessageOutputDeviceData(string.Format(CultureInfo.InvariantCulture, CrashDumpResources.CannotFindExpectedCrashReportFile, expectedCrashReportFile, CrashReportFileSearchPattern)), cancellationToken).ConfigureAwait(false); | ||
| foreach (string crashReportFile in Directory.GetFiles(Path.GetDirectoryName(expectedCrashReportFile)!, CrashReportFileSearchPattern)) |
There was a problem hiding this comment.
Already addressed in 8763b96 — the *.crashreport.json fallback now filters with f.EndsWith(CrashReportFileExtension, StringComparison.OrdinalIgnoreCase) so a foo.crashreport.jsonbak (or any 8.3 short-name alias) cannot be re-published as a crash report (CrashDumpProcessLifetimeHandler.cs:130-131).
| @@ -1,4 +1,4 @@ | |||
| // Copyright (c) Microsoft Corporation. All rights reserved. | |||
| // Copyright (c) Microsoft Corporation. All rights reserved. | |||
There was a problem hiding this comment.
Already addressed in 8763b96 — the UTF-8 BOM is back on CrashDumpEnvironmentVariableProvider.cs:1 (matching every other C# file in the project).
| // Use StringComparer.Ordinal so the option ordering is deterministic across TFMs | ||
| // (the culture-aware default sorts '-' differently between .NET Framework and .NET (Core)). | ||
| // Note: this affects the visible order of options in `--help` / `--info` output. | ||
| foreach (CommandLineOption option in options.OrderBy(x => x.Name, StringComparer.Ordinal)) |
There was a problem hiding this comment.
Already addressed in 8763b96 — switched from StringComparer.Ordinal to StringComparer.OrdinalIgnoreCase (CommandLineHandler.cs:116) so casing differences also sort stably, and added an inline comment calling out that this affects the visible order of options in --help/--info. The release-notes mention will be picked up when the next platform release bundle is assembled.
| - **Crash report collection**: optionally emits a lightweight JSON crash report to help diagnose crashes without uploading a full dump (Linux/macOS only — see [dotnet/runtime#80191](https://github.com/dotnet/runtime/issues/80191)) | ||
| - **Post-mortem debugging**: collected dumps can be analyzed with tools like Visual Studio, WinDbg, or `dotnet-dump` | ||
| - **Cross-platform**: supported on Windows, Linux, and macOS. Note that dumps collected on macOS can only be analyzed on macOS | ||
| - **Cross-platform**: crash dumps are supported on Windows, Linux, and macOS (dumps collected on macOS can only be analyzed on macOS). Crash reports are currently only supported on Linux and macOS. |
There was a problem hiding this comment.
Already addressed in 8763b96 — PACKAGE.md:18 and PACKAGE.md:24 both call out the runtime version requirement: "requires .NET 7+ when used alone or .NET 6+ when combined with --crashdump".
| bool dumpFileFound = generateDump && File.Exists(expectedDumpFile); | ||
| bool crashReportFileFound = generateCrashReport && File.Exists(expectedCrashReportFile); | ||
| string? processCrashedMessage = (dumpFileFound, crashReportFileFound) switch |
There was a problem hiding this comment.
Already addressed in 8763b96 — the variables are now dumpArtifactProduced / crashReportArtifactProduced (CrashDumpProcessLifetimeHandler.cs:84-85), with an inline comment clarifying "what was actually produced, not what was requested".
| [TestMethod] | ||
| [OSCondition(ConditionMode.Include, OperatingSystems.Windows, IgnoreMessage = "Validates Windows-specific error for --crash-report")] | ||
| public async Task CrashReport_OnWindows_FailsWithValidationError() |
There was a problem hiding this comment.
Already addressed in 8763b96 — CrashDump_WithCrashReport_OnWindows_FailsWithValidationError at CrashDumpTests.cs:97-106 runs --crashdump --crash-report and asserts ExitCode.InvalidCommandLine plus the not supported on Windows message.
| bool generateDump = _commandLineOptions.IsOptionSet(CrashDumpCommandLineOptions.CrashDumpOptionName); | ||
| bool generateCrashReport = _commandLineOptions.IsOptionSet(CrashDumpCommandLineOptions.CrashReportOptionName); |
There was a problem hiding this comment.
Fixed in #8328 — the generic CrashDumpProcessCrashed banner now reads "Test host process with PID '{0}' crashed but the expected diagnostic artifact(s) were not produced". Since IsEnabledAsync guarantees at least one of --crashdump / --crash-report is set whenever this handler runs, reaching the (false, false) branch always means an expected artifact was not produced, so the more informative wording is always accurate. XLF files regenerated in the same commit.
Amaury Levé (Evangelink)
commented
May 18, 2026
Copilot address review comments |
Co-authored-by: Evangelink <11340282+Evangelink@users.noreply.github.com>
Co-authored-by: Evangelink <11340282+Evangelink@users.noreply.github.com>
Addressed in 9ef5281 with follow-up clarification in 717f1e5. I tightened the crash report fallback filtering, restored the C# BOM, updated runtime docs, switched option ordering to OrdinalIgnoreCase, and added Windows coverage for |
Uh oh!
There was an error while loading. Please reload this page.
… follow-up) (#8328) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
New Feature
What does this feature do?
The CrashDump extension can now ask the .NET runtime to generate JSON crash reports in addition to, or instead of, a dump. This makes crash triage lighter-weight in CI, especially for environments where full dump collection is expensive or impractical.
A single composable flag
--crash-reportwas chosen over the original two-flag (--crashreport+--crashreport-only) design: one flag = one artifact type, the option can be combined freely with--crashdump, and no awkward mutual-exclusion validation is needed.Why is this feature needed?
DOTNET_EnableCrashReportandDOTNET_EnableCrashReportOnlyare already available in the runtime, but the MTP CrashDump extension only exposed dump generation. Surfacing crash reports gives a cheaper diagnostic path and improves crash investigation on machines where developers cannot inspect native dumps directly.Implementation details
CLI surface
--crash-report(kebab-case, matching the broader MTP CLI convention such as--results-directory,--diagnostic-output-directory, etc.)--crashdump→ dump only--crash-report→ crash report only--crashdump --crash-report→ dump + crash report--crash-reportis rejected at command-line validation time because the .NET runtime ignoresDOTNET_EnableCrashReport/DOTNET_EnableCrashReportOnlyon Windows (see dotnet/runtime#80191). The error message points users to--crashdumpas the alternative.Runtime configuration
--crashdump --crash-report→DOTNET_DbgEnableMiniDump=1+DOTNET_EnableCrashReport=1--crash-report→DOTNET_DbgEnableMiniDump=1+DOTNET_EnableCrashReportOnly=1(createdump still needs MiniDump activation to emit the report)Artifacts and user-visible behavior
*.crashreport.jsongenerated/could not findmessaging), so it no longer claims success for an artifact the runtime did not emit.PACKAGE.mdto describe the new option and the Windows limitation.Platform fix (deterministic option ordering)
Microsoft.Testing.Platformnow sorts CLI options for--help/--infousingStringComparer.Ordinalinstead of the culture-aware default. Without this, the relative order of--crash-reportvs--crashdumpdiffered between .NET Framework (word sort ignores-) and .NET (Core) (ordinal-like ICU sort), which would make the help/info acceptance tests non-deterministic across TFMs.Coverage
--crash-reportalone,--crash-reportcombined with--crashdump, and the Windows-only validation rejection.--crashdump --crash-report(dump + report, Linux/macOS only)--crash-reportalone with default name (report only, Linux/macOS only)--crash-reportwith--crashdump-filename(report only with custom name, Linux/macOS only)--crash-reporton Windows → fails with the platform-limitation error--help/--infoexpectations for the new CLI option ordering.Example