OutOfMemoryException, Dump file size, and GC Heap Size

A 32bit .net application, running on a 32 bit machine, ran into an OutOfMemoryException. I then took a full memory dump, and although using WinDbg I can verify that a lot of memory is being used, I wonder why we get OOMEs, although the GC Heap Size, according to WinDbg's output to "!eeheap -gc", is only around 1GB, so it looks like there's quite some space left up to the 1.5GB of .net.

Here's are parts of the output:

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x6a12ffcc
generation 1 starts at 0x6a12ffc0
generation 2 starts at 0x016a1000
ephemeral segment allocation context: (0x6a12ffd8, 0x6a12ffe4)
 segment    begin allocated     size
016a0000 016a1000  0269ff64 0x00ffef64(16772964)
...

69130000 69131000  6a12ffd8 0x00ffefd8(16773080)
Large object heap starts at 0x026a1000
 segment    begin allocated     size
026a0000 026a1000  03698a98 0x00ff7a98(16743064)
...

70020000 70021000  70a7d750 0x00a5c750(10864464)
Total Size  0x3c67abb4(1013427124)
------------------------------
GC Heap Size  0x3c67abb4(101开发者_C百科3427124)

Is this to be expected? Where would the remaining ~500MBs be?

Some more details:

• The dump file itself has a size of 2.007.000.476 Bytes.
• The machine the software was run on had only 1GB of physical RAM, but virtual memory of that machine was setup to grow to up to 3GB (so that the app should be able to grow up to the 1.5GB maximum of 32bit .net applications).

Most likely the process isn't 3GB aware. It is a per process setting.

Also if you want to see total memory usage, you can use !heap -s. This will give you a summary of what each heap is doing and the amount of memory it used. This will show you fragmentation issues as well. Combine this with the managed heap, and it should give you an idea of total memory usage.

A dump size of nearly 2 Gb indicates that the user address space of the process is full. Memory is filled not only by .Net memory allocations, but also native (C/C++) allocations, jitted code, binaries, stacks, ... With Windbg, check the virtual space usage with !address -summary. To get a global view, you can also use DebugDiag to analyze the dump.