dotnet.exe should not appear in "dotnet counters list-processes"

[chrisnas]

After installing dotnet-counters Preview 6, two different outputs are generated when "dotnet counters list-processes" and "dotnet-counters list-processes" are executed.

When using the "dotnet counters" syntax, dotnet.exe seems to spawn the C:\Users<user>.dotnet\tools\dotnet-counters.exe application.
Since dotnet.exe exposes its own \.\pipe\dotnetcore-diagnostic- named pipe, it appears in the list (based on https://github.com/dotnet/diagnostics/blob/master/src/Microsoft.Diagnostics.Tools.RuntimeClient/Eventing/EventPipeClient.cs#L35).

However, I don't see any filtering out of the current process so I can't explain why dotnet-counters.exe does not appear when it runs...

[chrisnas]

After investigation, the dotnet-counters.exe installed under C:\Users.dotnet\tools folder is not a "managed" application (might have been AoT compiled). In that case, the named pipe initialization from the Core CLR does not seem to be executed (which is a bit scary if this is the case).

A quick fix for the managed version could be the following code in ListProcesses method (https://github.com/dotnet/diagnostics/blob/master/src/Tools/dotnet-counters/Program.cs#L66):

               .Select(GetProcess)
               .Where(process => process != null)
               .OrderBy(process => process.ProcessName)
               .ThenBy(process => process.Id);

           // don't appear in the list 
           var currentPid = System.Diagnostics.Process.GetCurrentProcess().Id;
           foreach (var process in processes)
           {
               try
               {
                   if (process.Id == currentPid)
                       continue;

                   console.Out.WriteLine($"{process.Id, 10} {process.ProcessName, -10} {process.MainModule.FileName}");```

[noahfalk]

After investigation, the dotnet-counters.exe installed under C:\Users.dotnet\tools folder is not a "managed" application (might have been AoT compiled).

I think you are seeing the effect of a bootstrapper that gets used so we can sign the tool for security purposes, but anything that loads the runtime should be opening the pipe.

[EDIT]: I just realized, if you are running dotnet-counters.exe using the 2.1 .Net Core Runtime, that would explain why it isn't in the list.

[chrisnas]

I'm using 3.0 Preview 6

[noahfalk]

I'm using 3.0 Preview 6

Is that the only .Net Core version installed on the machine? dotnet-counters will preferentially run on 2.1 if you have it installed.

[chrisnas]

You're right @noahfalk :^)

dotnet-counter.exe is from preview 6 but the Core CLR is from 2.1.9

The .runtimeconfig.json contains the reference to 2.1

[tommcdon]

@sywhang @josalem

[noahfalk]

Rather than eliminate dotnet.exe from the list I'd suggest marking it with some indicator that it is the parent process. This gives users the information that if they want to pick a process to attach to, the parent dotnet process probably isn't the one they wanted, while still leaving the final choice in their hands. For example imagine if users used powershell core as their shell. I think it would be perfectly reasonable to want to list or trace that shell process and we'd be actively interfering with some users if we hid it from them.

I suspect the root of this issue is that we have too many processes named dotnet with little other information. Eliminating the parent trims one item from the list, but if there is more than one remaining it is still an ambiguous choice. In the future we could add some more unique qualifier such as the name of the assembly with the entrypoint so that many processes can be disambiguated.