Getting command line via diagnostic pipe GetProcessInfo command during suspension only reports process name

[jander-msft]

Description

On a non-Windows platform, while a runtime instance is suspended, issuing the GetProcessInfo command on the diagnostic pipe will only return the process name for the command line field. None of the command line parameters are provided.

Configuration

All non-Windows platforms, both .NET 5 and .NET 6.

Regression?

No, my understanding is that during suspension on non-Windows platforms, this field never provided the full command line.

Other information

During suspension, the command line field in the GetProcessInfo response will be something like:

/__w/1/s/.dotnet/dotnet

If the GetProcessInfo command is issued immediately after resuming the runtime, the same data is reported (only the process name).

If the GetProcessInfo command is issued sometime after the runtime is resumed and has run for a bit, then it returns the proper command line, e.g.:

/__w/1/s/.dotnet/dotnet /__w/1/s/artifacts/bin/Microsoft.Diagnostics.Monitoring.UnitTestApp/Release/net5.0/Microsoft.Diagnostics.Monitoring.UnitTestApp.dll AsyncWait

cc @josalem

[ghost]

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

Issue Details

---

Description

On a non-Windows platform, while a runtime instance is suspended, issuing the GetProcessInfo command on the diagnostic pipe will only return the process name for the command line field. None of the command line parameters are provided.

Configuration

All non-Windows platforms, both .NET 5 and .NET 6.

Regression?

No, my understanding is that during suspension on non-Windows platforms, this field never provided the full command line.

Other information

During suspension, the command line field in the GetProcessInfo response will be something like:

/__w/1/s/.dotnet/dotnet

If the GetProcessInfo command is issued immediately after resuming the runtime, the same data is reported (only the process name).

If the GetProcessInfo command is issued sometime after the runtime is resumed and has run for a bit, then it returns the proper command line, e.g.:

/__w/1/s/.dotnet/dotnet /__w/1/s/artifacts/bin/Microsoft.Diagnostics.Monitoring.UnitTestApp/Release/net5.0/Microsoft.Diagnostics.Monitoring.UnitTestApp.dll AsyncWait

cc @josalem

Author:	jander-msft
Assignees:	-
Labels:	area-System.Diagnostics.Process, untriaged
Milestone:	-

[josalem]

I took a look at the code paths for this and I think this unfortunately falling prey to the same ordering problems that the assembly name does, namely, part of command line resolution happens in the host. This means we are stuck waiting on the host to populate the command line.

Specifically, the runtime suspends in EEStartupHelper in ceemain.cpp, which gets called by CorHost2::Start, but the command line that we use doesn't get populated until CorHost2::ExecuteAssembly is called. I'm not entirely sure why we have a partial population of the value while suspended honestly. I'll have to put it under a debugger and see when that value is being put there.

The main issue is that on non-Windows platforms, we calculate the commandline rather than read it from some system API. The host is using the assembly path for the main assembly to generate it.