Add diagnostics for Process test hangs

[steveisok]

Focus and serialize Windows ProcessStartInfo tests, log startup and test ordering, and capture a WER dump before the Helix timeout.

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

[steveisok]

/azp run runtime-libraries-coreclr outerloop-windows

[steveisok]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Adds additional diagnostics and run-configuration changes to help investigate hangs in System.Diagnostics.Process tests, primarily on Windows. The PR introduces both logging (per-test + targeted messages) and a watchdog/WER dump configuration mechanism.

Changes:

• Windows-only test execution configuration updates (disable parallelization, enable progress output, and currently filters to a single test class via XUnitOptions).
• New diagnostics helper with a module initializer, WER LocalDumps configuration attempt, and a FailFast watchdog.
• Adds assembly-level xUnit BeforeAfterTestAttribute hook and adds extra diagnostic logging in a couple of ProcessStartInfoTests.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj	Adds Windows-only test runner settings (parallelization/progress and class filtering) and includes the new diagnostics source file.
src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs	New diagnostics implementation: per-test logging hook, module initializer logging, WER LocalDumps setup, and watchdog FailFast timeout.
src/libraries/System.Diagnostics.Process/tests/ProcessStartInfoTests.cs	Adds targeted diagnostic logs around specific test execution points.
src/libraries/System.Diagnostics.Process/tests/AssemblyInfo.cs	Registers the diagnostics attribute at assembly level.

Suppressed comments (1)

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:83

• Configuring WER LocalDumps under HKLM requires admin and will typically fail in CI/Helix (and if it succeeds, it leaves a machine-wide setting behind). Using HKCU avoids the elevation requirement and limits scope to the current user, making it more likely the dump configuration actually takes effect.

            {
                using RegistryKey? key = Registry.LocalMachine.CreateSubKey(keyPath);
                if (key is null)
                {
                    Log($"Unable to create WER LocalDumps key HKLM\\{keyPath}.");

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[steveisok]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[steveisok]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj:17

• The hard-coded -class System.Diagnostics.Tests.ProcessStartInfoTests filter in XUnitOptions means Windows runs of this test project will only execute that single test class, skipping the rest of the Process test suite on Windows (significant test coverage reduction). This kind of focusing should be passed as a CI/test invocation parameter (e.g., /p:XUnitClassName=...) rather than baked into the project file.

  <PropertyGroup Condition="'$(TargetPlatformIdentifier)' == 'windows'">
    <TestDisableParallelization>true</TestDisableParallelization>
    <XUnitOptions>$(XUnitOptions) -class System.Diagnostics.Tests.ProcessStartInfoTests -parallel none</XUnitOptions>
    <XUnitShowProgress>true</XUnitShowProgress>

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:49

• The watchdog thread is started unconditionally from the module initializer and will FailFast after 3 minutes even for non-hung runs (e.g., slow machines or local debugging). Consider gating this to Helix runs (or an explicit opt-in env var) so it doesn’t introduce new crash behavior in normal Windows test execution.

            var watchdog = new Thread(Watchdog)
            {
                IsBackground = true,
                Name = "Process tests hang watchdog"
            };
            watchdog.Start();

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:87

• Configuring WER LocalDumps via Registry.LocalMachine writes machine-wide state and will typically require elevated permissions; if it fails (UnauthorizedAccess), the dump capture won’t be configured at all. Prefer using a per-user key so the diagnostics can work under normal test permissions and avoid persisting HKLM changes.

                using RegistryKey? key = Registry.LocalMachine.CreateSubKey(keyPath);
                if (key is null)
                {
                    Log($"Unable to create WER LocalDumps key HKLM\\{keyPath}.");
                    return;

[steveisok]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[steveisok]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Note

This error may be related to your runner configuration. You can now configure runners for Copilot code review separately from Copilot cloud agent by creating a copilot-code-review.yml file with your setup steps. Read the docs for details.

[steveisok]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (6)

src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj:17

• XUnitOptions currently includes -class System.Diagnostics.Tests.ProcessStartInfoTests (and XUnitShowProgress enables -verbose). The -class filter will skip all other test classes for Windows TFMs, reducing coverage and potentially masking regressions; the verbose output is also unusually chatty to enable unconditionally.

    <TestDisableParallelization>true</TestDisableParallelization>
    <XUnitOptions>$(XUnitOptions) -class System.Diagnostics.Tests.ProcessStartInfoTests -parallel none</XUnitOptions>
    <XUnitShowProgress>true</XUnitShowProgress>

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:47

• The watchdog thread is started unconditionally, but Watchdog() currently calls FailFast after 3 minutes. That means any Windows run longer than 3 minutes will be terminated even if it’s making progress.

            var watchdog = new Thread(Watchdog)
            {
                IsBackground = true,
                Name = "Process tests hang watchdog"
            };

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:63

• To support an inactivity-based watchdog, Log should update the last-activity timestamp in a thread-safe way before writing output.

        internal static void Log(string message)
        {
            s_log.WriteLine($"[Process test hang diagnostics] {message}");
        }

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:104

• Watchdog() currently sleeps once and then unconditionally FailFasts. With an inactivity timestamp, this can instead trigger only when no test progress has been logged for the timeout window.

        private static void Watchdog()
        {
            Thread.Sleep(WatchdogTimeout);
            const string message = "System.Diagnostics.Process.Tests exceeded the diagnostic watchdog timeout.";
            Log(message);

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:35

• The watchdog currently enforces an absolute timeout. Tracking last test activity and having the watchdog trigger on inactivity avoids terminating long-but-progressing test runs.

This issue also appears in the following locations of the same file:

• line 60
• line 100

        private static readonly TimeSpan WatchdogTimeout = TimeSpan.FromMinutes(3);
        private static readonly TextWriter s_log = TextWriter.Synchronized(
            new StreamWriter(Console.OpenStandardError(), new UTF8Encoding(encoderShouldEmitUTF8Identifier: false), bufferSize: 1024, leaveOpen: true) { AutoFlush = true });

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:52

• Registry.GetValue can throw (e.g., access denied / security policy). Since this is diagnostic-only logging, it should not be able to fail the entire test assembly.

            Log("Reading Windows InstallationType.");
            object? installationType = Registry.GetValue(InstallationTypeKey, "InstallationType", defaultValue: null);
            Log($"InstallationType={installationType ?? "<null>"}");

[steveisok]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Suppressed comments (3)

src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj:18

• -class System.Diagnostics.Tests.ProcessStartInfoTests in XUnitOptions filters the Windows test run down to a single test class, which effectively disables the rest of the System.Diagnostics.Process test coverage on Windows. If the goal is only to serialize and add diagnostics, drop the class filter and keep only the parallelization settings.

  <PropertyGroup Condition="'$(TargetPlatformIdentifier)' == 'windows'">
    <TestDisableParallelization>true</TestDisableParallelization>
    <XUnitOptions>$(XUnitOptions) -class System.Diagnostics.Tests.ProcessStartInfoTests -parallel none</XUnitOptions>
    <XUnitShowProgress>true</XUnitShowProgress>
  </PropertyGroup>

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:63

• The watchdog currently measures wall-clock time since module initialization, so any legitimate run that takes longer than the watchdog timeout can be terminated even if tests are making progress. Track the most recent test activity and have the watchdog trigger only after a period of inactivity.

        internal static void Log(string message)
        {
            s_log.WriteLine($"[Process test hang diagnostics] {message}");
        }

src/libraries/System.Diagnostics.Process/tests/ProcessTestHangDiagnostics.cs:106

• Watchdog unconditionally calls FailFast after a single sleep, regardless of whether tests are actively progressing. Switching to an inactivity-based loop avoids terminating long-but-healthy runs and still triggers quickly when a test actually hangs.

        private static void Watchdog()
        {
            Thread.Sleep(WatchdogTimeout);
            const string message = "System.Diagnostics.Process.Tests exceeded the diagnostic watchdog timeout.";
            Log(message);
            Environment.FailFast(message);
        }