.NET Out Of Memory Exception - Used 1.3GB but have 16GB installed

Question

I am getting an Out Of Memory exception in my C# application when the memory usage for the application goes over about 1.3GB.

I had this same problem on a 32-bit machine with 3GB of memory and it made sense back then. But now I upgraded the hardware to a 64-bit machine with 16GB memory using a high-end motherboard and high-end RAM, but the Out Of Memory exception still occurs after 1.3GB!

I know that there are no single objects over 2GB and 1.3 is less than 2GB anyway, so the built-in MS 2GB limit on a single object is not likely to be the problem.

It seems like there is a Windows kill-switch of some sort when an app reaches a certain memory usage threshold. Then there should be a way to configure this. Is it in the registry perhaps?

Any help will be greatly appreciated!

Solution 1

There is no difference until you compile to same target architecture. I suppose you are compiling for 32 bit architecture in both cases.

It's worth mentioning that OutOfMemoryException can also be raised if you get 2GB of memory allocated by a single collection in CLR (say List<T>) on both architectures 32 and 64 bit.

To be able to benefit from memory goodness on 64 bit architecture, you have to compile your code targeting 64 bit architecture. After that, naturally, your binary will run only on 64 bit, but will benefit from possibility having more space available in RAM.

Solution 2

As already mentioned, compiling the app in x64 gives you far more available memory.

But in the case one must build an app in x86, there is a way to raise the memory limit from 1,2GB to 4GB (which is the actual limit for 32 bit processes):

In the VC/bin folder of the Visual Studio installation directory, there must be an editbin.exe file. So in my default installation I find it under

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\editbin.exe

In order to make the program work, maybe you must execute vcvars32.bat in the same directory first. Then a

editbin /LARGEADDRESSAWARE <your compiled exe file>

is enough to let your program use 4GB RAM. <your compiled exe file> is the exe, which VS generated while compiling your project.

If you want to automate this behavior every time you compile your project, use the following Post-Build event for the executed project:

if exist "$(DevEnvDir)..\tools\vsvars32.bat" (
   call "$(DevEnvDir)..\tools\vsvars32.bat"
   editbin /largeaddressaware "$(TargetPath)"
)

Sidenote: The same can be done with the devenv.exe to let Visual Studio also use 4GB RAM instead of 1.2GB (but first backup the old devenv.exe).

Solution 3

Its worth mentioning that the default for an 'Any CPU' compile now checks the 'Prefer 32bit' check box. Being set to AnyCPU, on a 64bit OS with 16gb of RAM can still hit an out of memory exception at 2gb if this is checked.

Solution 4

It looks like you have a 64bit arch, fine -- but a 32bit version of the .NET runtime and/or a 32bit version of Windows.

And as such, the address space available to your process is still the same, it has not changed from your previous setup.

Upgrade to both a 64bit OS and a 64bit .NET version ;)

Solution 5

Is your application running as a 64 or 32bit process? You can check this in the task manager.

It could be, it is running as 32bit, even though the entire system is running on 64bit.

If 32bit, a third party library could be causing this. But first make sure your application is compiling for "Any CPU", as stated in the comments.

View more solutions

Comments

[Tigran]

Yes, AnyCPU is an option too, where you have an option to JIT architecture dependent code. But targeting specific architecture remains still can benefit, in cases when you have non managed (say) resources. I have no idea what is OP's architecture about.

[Paceman]

I knew that :) - Thanks Tigran, I rebuilt the solution in x64 and the exception went away.

[Maverick]

Thanks a lot. This works for me. But do we have any identified issues after raising the memory limit to 4GB.

[RSSM]

This absolutely resolved my out of memory issues and saved us a ton of frustration