Skip to content

[fix] Fix missing dumps for .NET Framework child processes in NetClientHangDumper #16098

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Jakub Jareš (nohwnd) merged 2 commits into from
Jun 11, 2026
Merged

[fix] Fix missing dumps for .NET Framework child processes in NetClientHangDumper #16098

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
39f3f55
Fix: add MiniDumpWriteDump fallback in NetClientHangDumper for .NET F…
nohwnd Jun 6, 2026
a77e3cf
Clarify fallback catch scope in NetClientHangDumper
nohwnd Jun 6, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 21 additions & 2 deletions src/Microsoft.TestPlatform.Extensions.BlameDataCollector/NetClientHangDumper.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,13 @@
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Runtime.InteropServices;
using System.Threading;
using System.Threading.Tasks;

using Microsoft.Diagnostics.NETCore.Client;
using Microsoft.VisualStudio.TestPlatform.ObjectModel;
using Microsoft.VisualStudio.TestPlatform.PlatformAbstractions;
using Microsoft.VisualStudio.TestPlatform.Utilities;

namespace Microsoft.TestPlatform.Extensions.BlameDataCollector;
Expand Down Expand Up @@ -62,9 +64,9 @@ public void Dump(int processId, string outputDirectory, DumpTypeOption type)
tasks.Add(Task.Run(
() =>
{
var outputFile = Path.Combine(outputDirectory, $"{p.ProcessName}_{p.Id}_{DateTime.Now:yyyyMMddTHHmmss}_hangdump.dmp");
try
{
var outputFile = Path.Combine(outputDirectory, $"{p.ProcessName}_{p.Id}_{DateTime.Now:yyyyMMddTHHmmss}_hangdump.dmp");
EqtTrace.Verbose($"NetClientHangDumper.CollectDump: Selected dump type {type}. Dumping {p.Id} - {p.ProcessName} in {outputFile}. ");

var client = new DiagnosticsClient(p.Id);
Expand All @@ -75,7 +77,24 @@ public void Dump(int processId, string outputDirectory, DumpTypeOption type)
}
catch (Exception ex)
{
EqtTrace.Error($"NetClientHangDumper.Dump: Error dumping process {p.Id} - {p.ProcessName}: {ex}.");
EqtTrace.Error($"NetClientHangDumper.Dump: Error dumping process {p.Id} - {p.ProcessName} via DiagnosticsClient: {ex}.");

// DiagnosticsClient can only connect to .NET Core/5+ processes. On Windows, fall back
// to MiniDumpWriteDump for any DiagnosticsClient failure — this primarily covers .NET Framework
// and native child processes with no diagnostics socket, but also acts as a last resort for
// other transient failures. FileMode.Create in CollectDump ensures any partial output is replaced.
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))

@nohwnd Jakub Jareš (nohwnd) Jun 6, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Crash & Hang Dump Reliability] The inline comment on lines 82–84 frames the fallback as specific to the "no diagnostics socket" case (.NET Framework / native processes), but the catch block is catch (Exception ex) — it activates for any DiagnosticsClient.WriteDump failure on Windows.

That broader scope is actually correct and beneficial: MiniDumpWriteDump.CollectDumpUsingMiniDumpWriteDump uses FileMode.Create, so it safely overwrites any partial/corrupt output the primary attempt may have left behind. And since the try block ends immediately after WriteDump() returns, a successful primary dump can never be accidentally clobbered by the fallback.

The risk is that a future reader may try to narrow this to ServerNotAvailableException based on the comment, inadvertently regressing the broader-failure handling. Consider updating the comment to make the intentional scope explicit, e.g.:

// DiagnosticsClient can only connect to .NET Core/5+ processes. On Windows, fall back
// to MiniDumpWriteDump for any DiagnosticsClient failure — this primarily covers .NET Framework
// and native child processes with no diagnostics socket, but also acts as a last resort for
// other transient failures. FileMode.Create in CollectDump ensures any partial output is replaced.

@nohwnd Jakub Jareš (nohwnd) Jun 6, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done — updated the comment to explicitly call out that the catch (Exception ex) intentionally covers all DiagnosticsClient failures on Windows (not just missing-socket), and noted that FileMode.Create in CollectDump safely replaces any partial primary output.

🔧 Iterated by PR Iteration Agent 🔧

{
EqtTrace.Verbose($"NetClientHangDumper.Dump: Falling back to MiniDumpWriteDump for process {p.Id} - {p.ProcessName}.");
try
{
WindowsHangDumper.CollectDump(new ProcessHelper(), p, outputFile, type);
}
catch (Exception fallbackEx)
{
EqtTrace.Error($"NetClientHangDumper.Dump: Fallback dump also failed for process {p.Id} - {p.ProcessName}: {fallbackEx}.");
}
Comment on lines +86 to +96
}
}
}, timeout.Token));
}
Expand Down