[System.Diagnostics.Process]::GetProcesses(computer) returns local processes

[SteveL-MSFT]

Repro in PowerShell Core 6

[System.Diagnostics.Process]::GetProcesses("not existing computer")

Expected

error not able to connect to computer

Actual

local processes returned

[stephentoub]

@joperezr, @wtgodbe, this appears to be a bug in System.Diagnostics.PerformanceCounterLib.PerformanceMonitor. It's simply doing:
https://source.dot.net/#System.Diagnostics.Process/System/Diagnostics/PerformanceCounterLib.cs,210

_perfDataKey = Registry.PerformanceData;

whereas netfx is doing:
http://referencesource.microsoft.com/#System/services/monitoring/system/diagnosticts/PerformanceCounterLib.cs,1189

if (machineName != "." && String.Compare(machineName, PerformanceCounterLib.ComputerName, StringComparison.OrdinalIgnoreCase) != 0)
{
    perfDataKey = RegistryKey.OpenRemoteBaseKey(RegistryHive.PerformanceData, machineName);
}
else
{
    perfDataKey = Registry.PerformanceData;
}

In other words, it's ignoring the remote machine name and always using the local machine info 😦

This is pretty bad... not only does it mean we get the error originally reported, but it means Process.GetProcesses(machineName) is returning the wrong info when the machine does actually exist.

[danmoseley]

It looks like it was originally ported that way. Perhaps from Silverlight? We do not have a scheme for testing the remote aspects of Process.

[SteveL-MSFT]

For the purposes of PowerShell Core, I'm recommending users rely on PSRP (PowerShell Remoting) instead of trying to use dotnet remoting, so from my point of view, I would be fine if this wasn't supported.

[stephentoub]

Thanks, @SteveL-MSFT. Good to hear this isn't a blocker for PowerShell, but I still think it's problematic more generally. Having an API spit out incorrect results is rarely a good thing 😄

[SteveL-MSFT]

@stephentoub just to clarify, not supported meaning to throw an exception or removed (not sure if it's part of .Net Std...). In anycase, for PSCore6, I've removed usage of it so the user can't get bad results.

[joperezr]

@SteveL-MSFT thanks for catching this! @stephentoub looks like in non-Windows we throw PNSE but in Windows we have this bug. Correct me if I'm wrong but I think that it might be doable to fix this in order to show the correct info on Windows at least, and not have to throw PNSE in there as well.

[stephentoub]

I think that it might be doable to fix this in order to show the correct info on Windows at least

Right. I actually expect the fix is trivial, essentially just fixing the missing code I showed earlier, unless we broke something else as well. The trickier part is testing it.

[wtgodbe]

@stephentoub do you have any suggestions for how to test a fix for this?

[stephentoub]

Do you have any suggestions for how to test a fix for this?

If nothing else, the repro shared in the initial post, e.g.

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        foreach (Process p in Process.GetProcesses(Guid.NewGuid().ToString()))
        {
            Console.WriteLine(p.ProcessName);
        }
    }
}

should fail, throwing an exception as it does on netfx:

Unhandled Exception: System.InvalidOperationException: Couldn't connect to remote machine. ---> System.InvalidOperationException: Couldn't get process information from performance counter. ---> System.ComponentModel.Win32Exception: The network path was not found
   at System.Diagnostics.PerformanceMonitor.Init()
   at System.Diagnostics.PerformanceCounterLib.GetPerformanceData(String item)
   at System.Diagnostics.NtProcessManager.GetProcessInfos(PerformanceCounterLib library)
   --- End of inner exception stack trace ---
   at System.Diagnostics.NtProcessManager.GetProcessInfos(PerformanceCounterLib library)
   at System.Diagnostics.NtProcessManager.GetProcessInfos(String machineName, Boolean isRemoteMachine)
   --- End of inner exception stack trace ---
   at System.Diagnostics.NtProcessManager.GetProcessInfos(String machineName, Boolean isRemoteMachine)
   at System.Diagnostics.ProcessManager.GetProcessInfos(String machineName)
   at System.Diagnostics.Process.GetProcesses(String machineName)
   at Program.Main()

On .NET Core on Windows today, though, it successfully prints out the names of all of the processes on the local machine. We should be able to validate that we get such errors in a unit test, including in CI.

To my knowledge, we don't currently have infrastructure in CI that would let us do the next level of validation, which is that putting in a valid machine name to which the user has access successfully enumerates the processes on the remote machine. But whoever fixes it should at the very least manually verify the fix with machines they do have permissions to. And ideally we'd come up with some way to automate that validation in CI as well.

[wtgodbe]

Resolved by dotnet/corefx#25784