What it means when PM(K) of ps gets negative values? - windows

Question

I got the following negative PM (The amount of pageable memory that the process is using, in kilobytes) values when execute the ps command. What it means when the values are negative?
PS H:\> ps sqlservr
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
5947 4145 -1218888 1537304 981 ...50.77 8344 sqlservr
PS H:\> ps sqlservr
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
6060 4172 -1218876 1537316 981 ...52.08 8344 sqlservr
PS H:\> ps sqlservr
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
6481 4258 -1218832 1537376 981 ...56.55 8344 sqlservr
The negative value may be the overflow of Int32? However, the following statements shows that the paged memory was 4TB? Which is not possible.
$m = [int32]::MaxValue
($m + ($m -1218832) + 2)/1024/1024
# returns 4094.83763122559 (GB)

Answer 1

This is a simple signed/unsigned overflow error. It's overflowing both the negative space and (in many modern situations) overflowing the unsigned 32-bit range as well.
I believe all PM(K) is doing is showing PagedMemorySize / 1024. They should be showing PagedMemorySize64 / 1024.
Here's what I get on my local server with 16GB of RAM and 14GB reserved for SQL Server:
PS C:\> $x = ps sqlservr
PS U:\> $x
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
1555 1280 -1683524 132568 81 2056 sqlservr
PS U:\> $x.PagedMemorySize / 1024
-1683524
PS C:\> $x.PagedMemorySize
-1723928576
PS C:\> $x.PagedMemorySize.GetType().FullName
System.Int32
The guys who wrote Get-Process should have used unsigned integers, but didn't.
You can do the two's compliment math pretty easily, but it'll be pretty clear that the value still doesn't make sense because you've overflowed out of 32-bit address space entirely:
PS C:\> ($x.PagedMemorySize + [uint32]::MaxValue + 1) / 1GB
2.39446640014648
And you can prove out that the number takes more than 31 bits of address space pretty easily:
PS C:\> [math]::log($x.PagedMemorySize + [uint32]::MaxValue + 1)/[math]::log(2)
31.2597041913968
[Note: I might have that wrong... I can never remember when to add the 1.]
You should use PagedMemorySize64 / 1024:
PS C:\> $x.PagedMemorySize64.GetType().FullName
System.Int64
PS C:\> $x.PagedMemorySize64 / 1KB
15093692
PS C:\> $x.PagedMemorySize64 / 1GB
14.3944664001465
And you can prove out that you need more than 32 bits of address space as easily as we did above:
PS C:\> [math]::log($x.PagedMemorySize64)/[math]::log(2)
33.847442404377
So my system needs 34 of the 64 bits to address all the memory it's using.
You can even see where the 2.39 GB number from above comes from with a little binary math:
PS C:\> ($x.PagedMemorySize64 -band [uint32]::MaxValue) / 1GB
2.39446640014648
Technically, they should have used unsigned 64-bit integers for PagedMemorySize64, but it's pretty unlikely that you'll need that much address space for the foreseeable future ([int64]::MaxValue / 1PB = 8,192 petabytes).