Fun with the WorkingSet and int32

I finally found an honest to goodness bug in the .NET framework.

I've been playing around with the Process class lately to log the WorkingSet (memory usage). The problem I've found is that the WorkingSet returns the amount of memory being used by the process as an integer (32 bit signed integer). OK, so the maximum value of an integer is 2,147,483,647 -- which is remarkably close to the total amount of memory that a process can have in its working set.

So, no problems right? Wrong.

There is actually a switch in Windows that will allow a process to use 3 gig of memory instead of 2 gig. This switch is often turned on when dealing with Analysis Services -- this thing can be a memory hog. So now what happens is that when I poll the WorkingSet I get a negative number, a really big negative number. Usually, in the realm of -2,147,482,342.

That looks kind of funny -- I'm pretty sure you cannot be using a negative amount of memory.
Worse is that I didn't realize what the problem was for a couple of weeks. The overflow bit.

Working set is returned to the .NET framework as a binary value. The first bit of an integer is the sign bit. 0 is positive, 1 is negative. So, when the value turned from (binary) 1111111111111111111111111111111 to (binary) 10000000000000000000000000000000 the value goes from 2147483647 to -2147483647.

OK, so I still have to fix this. Here is what I came up with (in C#):

long lWorkingSet = 0;
if (process.WorkingSet >= 0)
 lWorkingSet = processWorkingSet;
else
 lWorkingSet = ((long)int.MaxValue*2)+process.WorkingSet;

Hopefully that fixes the problem for now.

The real question will come in down the road. Microsoft knows about this problem. I still have find out how they are going to fix this for Win64...where this trick will no longer work.