Recently I’ve been doing a lot of work with the Process.GetCurrentProcess() method and since the application I am building is being developed on the 2.0 64bit framework, I was worried that if I used Process.GetCurrentProcess().WorkingSet64, that the application wouldnt work with 32bit OS’s, since WorkingSet was deprecated, but not enforced.

After some thought though, I realised 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.  Except, there is actually a switch in Windows that will allow a process to use 3 gig of memory instead of 2 gig.  So what would happen when you poll the WorkingSet you will get a negative number, a really big small negative number. Usually, in the realm of -2,147,482,342.  As the more perceptive of you have guessed the problem already.  The overflow bit.

So you ask, why didn’t Microsoft just change the API so WorkingSet returned an Int64 instead of an Int32.  Well they could, except that they would break applications built against version 1.0 and 1.1 frameworks, as this post explains.

But after all this pondering, it turns out that WorkingSet64 des exactly what WorkingSet does, except returns an Int64 instead – and as such is less prone to breaks.  Works with both 32bit and 64bit Windows and Frameworks and all is good with the world.