Summary
The build (windows-latest, Debug) CI leg intermittently fails because the ModelContextProtocol.Tests test host hangs and is killed after the 7-minute blame inactivity timeout. When the hang was captured, the test executing was:
ModelContextProtocol.Tests.Server.TaskCancellationIntegrationTests.TaskTool_CancellationToken_GetTaskShowsWorkingBeforeCancel
(The blame collector notes "This test may, or may not be the source of the crash.")
This appears to be a flaky / non-deterministic hang — the same assembly passes on the other target frameworks in the same run, and the failure only reproduces intermittently on the Windows Debug leg.
Occurrence
Relevant log excerpt
Passed! - Failed: 0, Passed: 2273, Skipped: 4, Total: 2277, Duration: 6 m 33 s - ModelContextProtocol.Tests.dll (net10.0)
Passed! - Failed: 0, Passed: 2273, Skipped: 4, Total: 2277, Duration: 6 m 9 s - ModelContextProtocol.Tests.dll (net8.0)
Passed! - Failed: 0, Passed: 1974, Skipped: 278, Total: 2252, Duration: 6 m 30 s - ModelContextProtocol.Tests.exe (net472)
The active test run was aborted. Reason: Test host process crashed
Data collector 'Blame' message: The specified inactivity time of 7 minutes has elapsed. Collecting hang dumps from testhost and its child processes.
Data collector 'Blame' message: Dumping this process tree (from bottom).
Data collector 'Blame' message: > 5068 - testhost.
Data collector 'Blame' message: +- 6860 - ModelContextProtocol.Tests.
Passed! - Failed: 0, Passed: 2268, Skipped: 4, Total: 2272, Duration: 6 m 27 s - ModelContextProtocol.Tests.dll (net9.0)
Test Run Aborted.
The active Test Run was aborted because the host process exited unexpectedly. Please inspect the call stack above, if available, to get more information about where the exception originated from.
The test running when the crash occurred:
ModelContextProtocol.Tests.Server.TaskCancellationIntegrationTests.TaskTool_CancellationToken_GetTaskShowsWorkingBeforeCancel
This test may, or may not be the source of the crash.
Attachments:
...\ModelContextProtocol.Tests_6860_20260713T214733_hangdump.dmp
...\testhost_5068_20260713T214741_hangdump.dmp
...\Sequence_6dd0728684124ee1a0d9e35a4ba318c2.xml
make: *** [Makefile:19: test] Error 1
##[error]Process completed with exit code 1
Hang dumps (ModelContextProtocol.Tests_6860_*.hangdump.dmp, testhost_5068_*.hangdump.dmp) and the blame Sequence_*.xml are attached to the run as test-result artifacts and should contain the managed call stack of the hung thread.
Notes for debugging
procdump64.exe could not be found appears earlier in the log, so only the .NET hang dump (not a full crash dump via procdump) was collected — worth downloading the *hangdump.dmp artifacts and inspecting the blocked thread's stack (e.g. via dotnet-dump analyze → clrstack).
TaskCancellationIntegrationTests.TaskTool_CancellationToken_GetTaskShowsWorkingBeforeCancel coordinates a working→cancel transition; a missed signal / await that never completes is a plausible cause of the inactivity hang. The Sequence XML will confirm whether it was mid-execution or already completed when the host hung.
Expected
The Windows Debug test leg should complete deterministically without hanging.
Summary
The
build (windows-latest, Debug)CI leg intermittently fails because theModelContextProtocol.Teststest host hangs and is killed after the 7-minute blame inactivity timeout. When the hang was captured, the test executing was:(The blame collector notes "This test may, or may not be the source of the crash.")
This appears to be a flaky / non-deterministic hang — the same assembly passes on the other target frameworks in the same run, and the failure only reproduces intermittently on the Windows Debug leg.
Occurrence
29271612002, jobbuild (windows-latest, Debug)(attempt 2)Relevant log excerpt
Hang dumps (
ModelContextProtocol.Tests_6860_*.hangdump.dmp,testhost_5068_*.hangdump.dmp) and the blameSequence_*.xmlare attached to the run as test-result artifacts and should contain the managed call stack of the hung thread.Notes for debugging
procdump64.exe could not be foundappears earlier in the log, so only the .NET hang dump (not a full crash dump via procdump) was collected — worth downloading the*hangdump.dmpartifacts and inspecting the blocked thread's stack (e.g. viadotnet-dump analyze→clrstack).TaskCancellationIntegrationTests.TaskTool_CancellationToken_GetTaskShowsWorkingBeforeCancelcoordinates a working→cancel transition; a missed signal / await that never completes is a plausible cause of the inactivity hang. The Sequence XML will confirm whether it was mid-execution or already completed when the host hung.Expected
The Windows Debug test leg should complete deterministically without hanging.