Powershell: Get-Process - Missing paths and arguments

[toenuff]

In order for get-process to be useful on Linux, it needs to have access to all properties available via ps. Specifically, when ps is called with -f, you get the full path and args called for each process. Unfortunately, on Windows the path has been possible, but the arguments has not been. Most resort to the WMI objects to get this info. Alas, no wmi object on Linux.

Another problem is that the contents of the path property is weird on Linux. It actually shows the real path (unlike ps -f) for a few processes, but then others, it shows no path when there is one. For example, sshd:

10:57:20 PS /home/ubuntu> ps -ef |grep sshd
root      1002     1  0 Aug15 ?        00:00:00 /usr/sbin/sshd -D
root      8325  1002  0 10:19 ?        00:00:00 sshd: ubuntu [priv]
ubuntu    8408  8325  0 10:19 ?        00:00:01 sshd: ubuntu@pts/0
10:57:24 PS /home/ubuntu> gps sshd |select name, path

Name Path
---- ----
sshd
sshd
sshd

And here's the opposite when it shows a path in gps that is the actual path of the bin running:

10:58:41 PS /home/ubuntu> ps -ef |grep vi
ubuntu    4769  4659  0 Aug15 pts/2    00:00:00 /usr/bin/vi t.py
ubuntu    6183  5897  0 Aug16 pts/4    00:00:00 vi t.py
10:58:43 PS /home/ubuntu> gps vi |select name, path

Name Path
---- ----
vi   /usr/bin/vim.basic
vi   /usr/bin/vim.basic

There doesn't need to be complete consistency with the formatting, but the property for the process object needs to have the contents of ps somewhere in some property.

This is likely going to be a dotnet issue over a PowerShell one, but it is a story that needs to be addressed by PowerShell in order to become a truly usable shell for Linux.

[CJHarmath]

I would say that this is also a big miss on Windows as well.
Just consider this example:

PS C:\> start notepad c:\temp\foo.txt
PS C:\> (get-process notepad ).StartInfo.Arguments

It starts up a notepad.exe with an argument, then when trying to get-process, you won't be able to see that argument anywhere. Your best bet is what @toenuff said to go the WMI route based on the PID, which is messy, but yeah this is more of a .NET limitation as the result is the same when calling
[System.Diagnostics.Process]::GetProcessesByName("notepad").StartInfo.Arguments

Apparently that is always empty for already running processes, so not even sure what's the point of having it.
Would be nice if this issue could trigger a fix in .NET then this can be solved as well.
For example procexp is showing the arguments just fine and it does not seem to be an expensive operation to me, probably using Win32 API's.

Also I would say get-process should return process arguments as top level property vs exposing it as a .NET Startinfo.Arguments

Thanks

[SteveL-MSFT]

Great idea, @toenuff @csharmath can one/both of you author an RFC to capture all the details and propose how the output should look along with the parameters?

[davehull]

Path, StartInfo and other useful properties are not populated for all Windows processes either (e.g. csrss.exe). I'm assuming this is not a PowerShell problem, but an issue with how CreateProcessW was called at process creation time. Some values can be null, like the process path and presumably StartInfo.

It would be useful if MSFT would fix this for csrss.exe, smss.exe, wininit.exe, services.exe and any others. When you can't determine the path of a process, it makes it difficult to investigate issues.

[felixfbecker]

This seems to be the most common thing googled for Get-Process:

The accepted answer on StackOverflow is to use WMI, which of course doesn't work on macOS/Linux.

I fully agree that this is a big blocker to making PowerShell become a fully useful shell on Linux/macOS.

[kfsone]

Same machine:

Windows 10 17755.1, powershell 5.0:
(Get-Process |? StartInfo | Measure).Count
173

Windows 10 17755.1, pwsh core 6.0a:
(Get-Process |? StartInfo | Measure).Count
0

W10 PS5: PSVersion 5.1.17755.1
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17755.1
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1`

PS Core:
PSVersion 6.0.4 PSEdition Core GitCommitId v6.0.4 OS Microsoft Windows 10.0.17755 Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0

[SteveL-MSFT]

Someone should open an issue in corefx repo and link it back to this issue

[iSazonov]

The issue was fixed in #12288 for Windows and MacOS. For MacOS see #12832.