Skip to content

Why does System.Diagnostic.Process#HandleCount exist? #1812

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jpsnover opened this issue Aug 15, 2016 · 14 comments
Closed

Why does System.Diagnostic.Process#HandleCount exist? #1812

jpsnover opened this issue Aug 15, 2016 · 14 comments
Labels
Issue-Bug Issue has been identified as a bug in the product Resolution-Fixed The issue is fixed. WG-Cmdlets general cmdlet issues

Comments

@jpsnover
Copy link
Contributor

jpsnover commented Aug 15, 2016

Steps to reproduce

$a,$b = gps
$a.pstypenames

Expected behavior

System.Diagnostic.Process
System.Object

Actual behavior

System.Diagnostic.Process#HandleCount
System.Diagnostic.Process
System.Object

Environment data

jps> $a,$b = get-process                                                                                                              
jps> $a.pstypenames                                                                                                                   
System.Diagnostics.Process#HandleCount
System.Diagnostics.Process
System.Object
jps> $PSVersionTable                                                                                                                  

Name                           Value                                                                                                 
----                           -----                                                                                                 
PSVersion                      6.0.0-alpha                                                                                           
PSEdition                      Core                                                                                                  
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                               
BuildVersion                   3.0.0.0                                                                                               
GitCommitId                    v6.0.0-alpha.8                                                                                        
CLRVersion                                                                                                                           
WSManStackVersion              3.0                                                                                                   
PSRemotingProtocolVersion      2.3                                                                                                   
SerializationVersion           1.1.0.1        
@andyleejordan
Copy link
Member

This is... an excellent question. I couldn't find HandleCount referenced anywhere but as fields in internal sources in .NET Core.

/cc @daxian-dbw

@daxian-dbw
Copy link
Member

I remember it was because in remoting scenario the type definition on the client side expects the 'HandleCount' property when deserializing a Process object, and it will fail with exception when that property is not available. The noteproperty was added just to make sure all existing powershell client can work well in this case during remoting.

/cc @Francisco-Gamino

@SteveL-MSFT SteveL-MSFT added the WG-Cmdlets general cmdlet issues label Sep 13, 2016
@SteveL-MSFT SteveL-MSFT added the Resolution-Won't Fix The issue won't be fixed, possibly due to compatibility reason. label Sep 29, 2016
@SteveL-MSFT
Copy link
Member

Making a change may break existing remoting scenarios particularly between WindowsPowerShell and PowerShell Core. Does not impact the functionality. Recommend no change.

@iSazonov
Copy link
Collaborator

I caught the Issue when writing Pester tests:

Get-Process | Export-Csv -Path $testfile -Force

#TYPE System.Diagnostics.Process#HandleCount
"HandleCount","Name","SI","Handles","VM","WS","PM","NPM","Path","Company","CPU","FileVersion","ProductVersion","Description","Product","__NounName","SafeHandle","BasePriority","ExitCode","HasExited","ExitTime","Id","MachineName","MaxWorkingSet","MinWorkingSet","Modules","NonpagedSystemMemorySize64","PagedMemorySize64","PagedSystemMemorySize64","PeakPagedMemorySize64","PeakWorkingSet64","PeakVirtualMemorySize64","PriorityBoostEnabled","PriorityClass","PrivateMemorySize64","ProcessName","ProcessorAffinity","SessionId","StartInfo","Threads","VirtualMemorySize64","EnableRaisingEvents","StandardInput","StandardOutput","StandardError","WorkingSet64","MainModule","PrivilegedProcessorTime","StartTime","TotalProcessorTime","UserProcessorTime"
"0","ApplicationFrameHost","3","0","2199252946944","20496384","12066816","17936","C:\Windows\system32\ApplicationFrameHost.exe",,"0.28125",,,,,"Process","Microsoft.Win32.SafeHandles.SafeProcessHandle","8",,"False",,"5776",".","1413120","204800","System.Diagnostics.ProcessModuleCollection","17936","12066816","328544","13901824","27131904","2199287431168","True","Normal","12066816","ApplicationFrameHost","15","3",,"System.Diagnostics.ProcessThreadCollection","2199252946944","False",,,,"20496384","System.Diagnostics.ProcessModule (ApplicationFrameHost.exe)","00:00:00.1562500","10/17/2016 6:13:36 AM","00:00:00.2812500","00:00:00.1250000"

I believe that this is not exactly what is expected.

@iSazonov
Copy link
Collaborator

iSazonov commented Oct 19, 2016

@daxian-dbw and @SteveL-MSFT Could you please comment on this?

@daxian-dbw
Copy link
Member

@iSazonov The HandleCount was kept there just to make sure when running $p = Invoke-Command -Session $sn { Get-Process -Id $pid } on a down-level powershell client targeting a powershell core on server side, it doesn't throw exception on the down-level powershell client.

Object like System.Diagnostics.Process is deserialized to Deserialized.System.Diagnostics.Process when transferring from server to client. Type Deserialized.System.Diagnostics.Process is defined in types.ps1xml, and if you inspect the definition, you will see the property HandleCount is present, and it's expected when powershell deserializes the Process object. The missing of such property will cause an exception to be thrown on the client side.

We certainly can change types.ps1xml and powershell core to make it not expect the HandleCount property when deserializing Process objects from server. However, that won't help the existing down-level powershell instances out there, and we still want the down-level PS client to be able to remote to powershell core without problems. That's why we kept the HandleCount property, even though it's meaningless in CoreCLR.

@iSazonov
Copy link
Collaborator

@daxian-dbw Thanks for the great in-depth explanation. This clearly. But my question is easier. My question is specifically about Export-Csv behavior.
Why do Export-Csv write "Type#HandleCount" in Powershell 6.0 while the expected behavior is to write "Type"? I believe it is bug and regression.

In Powershell 5.0:

$a= Get-Process -ComputerName comp
$a[0].psobject

ImmediateBaseObject : System.Diagnostics.Process (avagent)
BaseObject          : System.Diagnostics.Process (avagent)
TypeNames           : {System.Diagnostics.Process, System.ComponentModel.Component, System.MarshalByRefObject,
                      System.Object}

In Powershell 6.0:

$a= Get-Process -ComputerName comp
$a[0].psobject

ImmediateBaseObject : System.Diagnostics.Process (ApplicationFrameHost)
BaseObject          : System.Diagnostics.Process (ApplicationFrameHost)
TypeNames           : {System.Diagnostics.Process#HandleCount, System.Diagnostics.Process, System.Object}

In code Export-Csv get TypeNames[0]. Perhaps we need to take BaseObject ? Or remove #HandleCount from TypeNames[0]? Or take TypeNames[1] if TypeNames[0] contains "#HandleCount"?

@lzybkr
Copy link
Contributor

lzybkr commented Oct 20, 2016

It seems somewhat useful to know the HandleCount property was synthesized and therefore not useful, e.g. we could change the display of ProcessInfo to not show the HandleCount property at all if the typename is ProcessInfo#HandleInfo.

@iSazonov
Copy link
Collaborator

@lzybkr If this will fix both (@jpsnover and my) issues, maybe should reopen the Issue?

@iSazonov
Copy link
Collaborator

According to #2207 it is CoreCLR bug that is waiting for a fix.

@SteveL-MSFT SteveL-MSFT reopened this Nov 2, 2016
@SteveL-MSFT SteveL-MSFT added Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors and removed Resolution-Won't Fix The issue won't be fixed, possibly due to compatibility reason. labels Nov 2, 2016
@SteveL-MSFT
Copy link
Member

Recommendation is to change the formatting to not show this as it's not useful to admin and the property is still available for compat reasons

@SteveL-MSFT SteveL-MSFT added the Issue-Bug Issue has been identified as a bug in the product label Nov 2, 2016
@iSazonov
Copy link
Collaborator

iSazonov commented Nov 3, 2016

Where should it be fixed? Maybe here in Process.cs

             // In CoreCLR, the System.Diagnostics.Process.HandleCount property does not exist. 
             // I am adding a note property HandleCount and temporarily setting it to zero. 
             // This issue will be fix for RTM and it is tracked by 5024994: Get-process does not populate the Handles field. 
             PSMemberInfo hasHandleCount = processAsPsobj.Properties["HandleCount"]; 
             if (hasHandleCount == null) 
             { 
                 PSNoteProperty noteProperty = new PSNoteProperty("HandleCount", 0); 
                 processAsPsobj.Properties.Add(noteProperty, true); 
                 processAsPsobj.TypeNames.Insert(0, "System.Diagnostics.Process#HandleCount"); 
             } 

remove processAsPsobj.TypeNames.Insert(0, "System.Diagnostics.Process#HandleCount");
I have not found using this in code anywhere.

@SteveL-MSFT SteveL-MSFT self-assigned this Nov 3, 2016
@SteveL-MSFT
Copy link
Member

@iSazonov the suggestion is to change the formatter and keep the code for compat reasons. this way it doesn't show up for the interactive user as it's not really useful anyways (IMHO), but still available on the object (on Windows for some dev scenarios). while looking for the code, I already made a fix and will submit a PR

@iSazonov
Copy link
Collaborator

iSazonov commented Nov 3, 2016

@SteveL-MSFT Clear! Thanks!

SteveL-MSFT added a commit that referenced this issue Nov 3, 2016
SteveL-MSFT added a commit that referenced this issue Nov 5, 2016
daxian-dbw pushed a commit that referenced this issue Nov 7, 2016
@SteveL-MSFT SteveL-MSFT added Resolution-Fixed The issue is fixed. and removed Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors labels Jan 26, 2017
@SteveL-MSFT SteveL-MSFT removed their assignment Jan 26, 2017
surfingoldelephant added a commit to surfingoldelephant/PowerShell-Docs that referenced this issue Apr 15, 2025
VM(M) was removed prior to Windows PowerShell v5.1.

Handles was removed in v6.0.
See: PowerShell/PowerShell#1812
sdwheeler added a commit to MicrosoftDocs/PowerShell-Docs that referenced this issue Apr 15, 2025
* Fix process default display column list

VM(M) was removed prior to Windows PowerShell v5.1.

Handles was removed in v6.0.
See: PowerShell/PowerShell#1812

* Add module definition to Get-Process description

* Add CIM alternative to Get-Process Example 8

This adds a Get-CimInstance/Invoke-CimMethod example as an alternative
approach to Get-Process -IncludeUserName. It replaces the obsolete
Get-WmiObject example that was present in the Windows PowerShell v5.1
doc.

This also removes the incorrect assertion in the v7.x docs that
-IncludeUserName requires elevation outright. That is only true for
v5.1.

* Improve Get-Process Ex 4 Priority grouping

The Priority table view for Diagnostics.Process groups on the
PriorityClass property. Format-Table expects input to already be
sorted, but the original example used unsorted data, rendering it
fairly unhelpful.

This adds a call to Sort-Object and sorts on PriorityClass before
calling Format-Table. This ensures all processes are correctly grouped
by the Priority view. A script block is used in lieu of the property
name directly, as the latter surfaces getter exceptions as a
non-terminating error. This will occur with, e.g., PPL processes in
Windows (even when elevated).

Reference to PS home directory .ps1xml files is also removed from the
v7.x docs. Format definitions were moved directly into source code in
v6+.

As a Format-* cmdlet is used, the term "display" is used to emphasize
output is not intended for further processing.

* Add concise alternative to Get-Process Example 3

* Refresh Get-Process style/formatting and examples

This fixes incorrect markdown formatting and adds link references.

This also ensures Get-Process output examples correctly reflect the PS
version targeted by the doc. E.g., Windows PS v5.1 includes Handles in
its default table view. This was removed in PS v6.0. See PS issue 1812.
Windows PS v5.1 uses (K) in its table view; PS v6.0+ uses (M).

Named parameters are added where appropriate.

Minor verbiage changes and added notes have also been made.

* Add warning about Get-Process in a 32-bit PS host

* Remove link references

* Fix links

* Editorial changes and fix link issue

---------

Co-authored-by: Sean Wheeler <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug Issue has been identified as a bug in the product Resolution-Fixed The issue is fixed. WG-Cmdlets general cmdlet issues
Projects
None yet
Development

No branches or pull requests

6 participants