I saw an interesting item over on the PowerShell newsgroup today. The poster was using Get-Process on an X64 system and was seeing negative numbers in the Working Set column against the SQL Server. The answer was a simple one, as it turns out.
The Get-Process cmdlet returns [System.Diagnostics.Process] objects, but with some added members – the cmdlet in effect expands the objects for PowerShell. Specifically, the Cmdlet adds 6 Alias Properties that are aliased to other properties in the [System.Diagnoistics.Process] Class:
- Handles = Handlecount
- Name = ProcessName
- NPM = NonpagedSystemMemorySize
- PM = PagedMemorySize
- VM = VirtualMemorySize
- WS = WorkingSet
This makes life easier for the admin who can use the shorter Alias property names, et:
$process = “*SQL"*”
GPS $process | ft name, ws -auto
The reason the poster was seeing negative numbers is fairly simple: the WS property is aliased to WorkingSet, but WorkingSet is a 32-bit value. In the poster’s case, the working set size overflowed the 32-bit value, resulting in a negative number being displayed. The solution is fairly simple if you look at the class’s Property details: use a different property which contains a 64- bit value. The class has several 64-bit properties:
So the solution was easy – just use:
$process = “*SQL"*”
GPS $process | ft name, workingset64 –auto
The maximum size of an Int32 is 2**32, meaning the maximum size of the WS/WorkingSet property is 4GB. Thus this problem can never occur on an I386 system since on i386, processes have a maximum size of 4GB, But as x64 becomes more common, and from Server 2008 R2 becomes the norm, this problem will grow.
Interestingly, in the API documentation MIcrosoft now state that the 32-bit values are obsolete. You could argue this is a bug in PowerShell. For PowerShell V2, Microsoft really should change the WS and other AliasProperties to alias the 64-bit properties. For CTP2, this has not been done.