Does .Net handle unmanaged memory differently than a C++ runtime/binary executable?

Question

A .Net application that uses p/invoke to interact with a Fortran library with massive amounts of static data allocation is unable to load the library when it is well under the 2 GB static data limit on Windows. The largest static code size I have had success with in loading via p/invoke is around 1 GB. If I write a simple C program that loads the library, I can load with static data sizes up to 1.9 GB. Both test applications are 32-bit.

The managed application attempts to load the library via LoadLibrary which fails, and the error message returned from Marshal.GetLastWin32Error is "not enough storage is available to process this command." Is there a difference in the way the CLR handles static memory allocation for unmanaged libraries vs. what the C++ runtime would provide with binary executable?

Answer 1

You don't have much of a guarantee in a C program either, it takes just one crappy injected DLL loaded at a base address that splits the available address space in two and the OS can no longer find a hole big enough to fit that huge section.

Much worse in a .NET program, it already has lots of code and data loaded by the time your pinvoke call starts to run. At least 10 heaps for example. The biggest hole is generally about 650-750 megabytes, but only immediately after startup. SysInternals' VMMap utility can show you the lay of the land.

Very little you can do to make the hole bigger. Be sure your .NET version is recent enough so it gets a 4 gigabyte address space on the 64-bit version of Windows. Your Fortran DLL needs to be /LARGEADDRESSAWARE for that to work. Restructuring the Fortran code so it allocates from the heap instead is surely something you don't want to do. High time to start building the 64-bit version of it, that's simple.