Description

When issuing a a GetProcessInfo2 command on the diagnostic pipe to a runtime instance that is suspended, it will fail to get the managed entrypoint assembly information and return an empty string.

The expected behavior is that for any .NET process that does have a managed entrypoint, that this command will return the managed entrypoint assembly even while the process was suspended at startup.

Without this, it makes any diagnostic tool have an extremely difficult time determining if it should start observing a process based on its entrypoint name, especially in a multi-container environment where the process name is likely dotnet for all .NET processes and the process ID is 1 for many of them; the main differentiator will be the entrypoint name. Diagnostic tools would have start observing the process (start event pipe sessions, or maybe even attach a profiler, during suspension), have to "wait a little while" until the command does return a valid value for the entrypoint, and possibly cancel all of the diagnostic operations on the process if it was not one that the tool really wanted to observe.

Expectation is that the GetProcessInfo2 should be able to get the managed entrypoint assembly information during suspension. From a naive perspective, this shouldn't require running managed code but just to read the assembly information from the metadata table.

Regression?

No

Other information

This is in reference to the following code:

Behavior was introduced in the following PR: #55379

cc @josalem