On Windows, .ProcessName should use QueryFullProcessImageNameW or GetProcessImageFileNameW.
Presently it used NtQuerySystemInformation(SystemProcessInformation).
The problem with NtQuerySystemInformation(SystemProcessInformation) is:
-
It is tremendously slower, returning all information about all processes,
instead of just the name, for one process. This is pretty obviously terrible, unless there are very few processes, and perhaps if you only have the process id and not a handle already (two syscalls, open and query). (Too bad Windows doesn't allow query by id to cut the cost.) Enum also has an advantage, sometimes, like, if you actually want more information than just the name. But generally it seems silly.
-
It does not work with terminated processes, which NtQuerySystemInformation(SystemProcessInformation) omit.
For example, you cannot have a generic:
WriteLine("The process {0} ended", process.ProcessName);
unless you call .ProcessName prior to termination to populate the CLR's cache. Such order/cache-sensitivity is also fragile but maybe ok. And that is not even possible: .NET does not expose creating processes suspended, so you will always race with a fast process that terminates quickly. So .ProcessName is all but unusable. We are removing our uses pretty thoroughly as a result. Though it is ok on current process, which will never be terminated.
We have actual code like this, causing us much grief, because..complicated reasons (we actually run mostly on an alternate implementation of NT, which was enumerating terminated processes, which mostly masked these problems, but not entirely; the problem is worse on native NT).
We are going to reduce our uses of process.ProcessName as a result.
On Windows, .ProcessName should use QueryFullProcessImageNameW or GetProcessImageFileNameW.
Presently it used NtQuerySystemInformation(SystemProcessInformation).
The problem with NtQuerySystemInformation(SystemProcessInformation) is:
It is tremendously slower, returning all information about all processes,
instead of just the name, for one process. This is pretty obviously terrible, unless there are very few processes, and perhaps if you only have the process id and not a handle already (two syscalls, open and query). (Too bad Windows doesn't allow query by id to cut the cost.) Enum also has an advantage, sometimes, like, if you actually want more information than just the name. But generally it seems silly.
It does not work with terminated processes, which NtQuerySystemInformation(SystemProcessInformation) omit.
For example, you cannot have a generic:
WriteLine("The process {0} ended", process.ProcessName);
unless you call .ProcessName prior to termination to populate the CLR's cache. Such order/cache-sensitivity is also fragile but maybe ok. And that is not even possible: .NET does not expose creating processes suspended, so you will always race with a fast process that terminates quickly. So
.ProcessNameis all but unusable. We are removing our uses pretty thoroughly as a result. Though it is ok on current process, which will never be terminated.We have actual code like this, causing us much grief, because..complicated reasons (we actually run mostly on an alternate implementation of NT, which was enumerating terminated processes, which mostly masked these problems, but not entirely; the problem is worse on native NT).
We are going to reduce our uses of process.ProcessName as a result.