dotnet-trace breaks apps that create their own child processes

[zivkan]

Description

I'm not sure if this is a feature request or a bug, but trying to use dotnet-trace collect --show-child-io -- dotnet package search json freezes and must be stopped with ctrl-c. The output is:

The runtime has been configured to pause during startup and is awaiting a Diagnostics IPC ResumeStartup command from a Diagnostic Port.
DOTNET_DiagnosticPorts="dotnet-trace-48696-20250614_161420.socket"
DOTNET_DefaultDiagnosticPortSuspend=0

The .NET SDK implements most of its NuGet functionality by executing another console app as its own child process. dotnet-trace doesn't have a problem with most non-nuget commands, and dotnet nuget why is a special case, the first NuGet command to run in-proc, and dotnet-trace works with that as well. Older versions of the .NET SDK ran msbuild as a child process of dotnet tool restore and dotnet tool install, and dotnet-trace causes those to freeze and never recover as well.

If this is a known limitation, I've been unable to find it documented anywhere, but that could be a limitation in my own search ability.

Configuration

I can reproduce on Windows and in WSL

Regression?

Other information

[hoyosjs]

One possible work around for this is #3175 (comment). That issue fell short of what this is trying to achieve - it's a weird side effect of dotnet-trace being a single process tracing tool.

[noahfalk]

Hi @zivkan! Thanks for the report! To give you a clear answer on your question - its a known limitation, albeit the docs only talk about it obliquely so not surprised you didn't find it easily. In the doc section Use diagnostic port to collect a trace from startup there is a warning box at the bottom that mentions child process hangs when using dotnet-run. I think we could break this down into a number of work items:

1. [Bug fixes] Improve docs and warnings:

• Update the docs to clearly call out launching a process with child processes won't work. The current warning is only visible in the docs for one particular way of doing the scenario and specific to dotnet-run. This is a more general limitation than what the docs imply.
• Improve the warning from the app that is being suspended ([ProcessLauncher] Explicitly set diagnostic port configs #5503 is doing this)
• Improve the warning from dotnet-trace when it receives a connection from a 2nd process.

2. [Tiny feature request] Upgrade dotnet-trace so that it automatically resumes any process that connects after the 1st. This allows dotnet-trace to work as long as the process you want to trace is the first one.

3. [Bigger feature request] Upgrade dotnet-trace so that it can collect traces of multiple processes.

I'd suggest we use this issue to track the bucket of warning/doc improvements and open other issues as needed for the feature request parts.

[zivkan]

Thanks for letting me know.

For what it's worth, the reason I was investigating is because a customer reported that a dotnet restore or dotnet tool restore command was making HTTP requests to an unexpected host. I was hoping that dotnet-trace could be used with --provider System.Net.Http to capture HTTP request information to confirm that it was really coming from the .NET SDK command, so this known limitation rules out this being a debugging technique. However, I think that dotnet-trace can't capture stack traces, unlike PerfView on Windows, so it probably wasn't a viable way to get suitable information from the customer anyway.

[noahfalk]

I think that dotnet-trace can't capture stack traces

Fyi dotnet-trace can capture managed stack traces, but it won't include native code frames on those stacks.