WinDbg MEM_COMMIT is at 1GB, eeheap is showing 150MB, can't find remaining memory

Question

I am having a bit of trouble trying to find some unmanaged memory allocation from a .dmp file.

I have been trying to follow the tips - here but I am hitting a bit of a wall

!address -summary gives me the below which shows the MEM_COMMIT is at 1.030Gb which is expected (please ignore the TB of memory, this is probably due to the fact this is from a virtual web server)

!eeheap -gc gives me the below which shows the .net memory usage is 150MB (if I run !eeheap on it's own I do not see any extra heaps, I still see 8 GC heaps that total 150MB)

This leads me to believe the majority of the memory usage is coming from unmanaged memory

The instructions I have been following then say to use !heap -s to find where the unmanaged memory is. When I do that I see the below

Now I would expect to see a large amount of memory being used by a heap that I could further analyse to try and locate the unmanaged memory, but I do not see any heaps that come close to filling showing the 1GB of used memory

I did notice that !address -summary showed 600MB in PAGE_READWRITE, so I tried !address /f:PAGE_READWRITE which I hoped would give me something else to go on, but it gives me a list of memory used by PAGE_READWRITE and Im not too sure how to analyse any further

Basically I want to know where the difference in memory between 1GB and 150MB of .net allocated memory is being used

Any help would be great

Collen

The free TB are a result of an application being 64bit. You can get that amount of virtual memory, but it might be swapped to disk. – Leif

load the dmp in DebugDiag analyzer (MemoryAnalysis) – Blooper

@Blooper - I haven't managed to get DebugDiag to give me any information about unmanaged memeory – Collen

The only information i get from DebugDiag appears to be from managed memory, the total memory it reports on totals to 150mb – Collen

I meet the exactly same problem in 2024. – Fulgurous

Answer 1

In "Usage Summary", you can see

<unknown>  17 GB
Heap       235 MB

<unknown> can be .NET or memory directly allocated by VirtualAlloc(). IMHO, someone using VirtualAlloc() directly is quite rare.

Heap is memory allocated via the Heap manager. So, !heap -s will not show more than 235 MB.

MEM_COMMIT is just another state of memory and it can be in any of the usage states. To find the 1 GB of committed memory, you need to sum up everything you have:

154 MB used by .NET GC Heaps
235 MB used by Heaps
234 MB used by Images
up to 50 MB in Stacks
... some smaller parts not really relevant

This already explains 620 to 670 MB of memory, depending on how much of the stack memory was actually committed.

If you execute !eeheap without the -gc parameter, you'll see that there is more memory used by .NET since it also has LoaderHeaps, JIT Heaps, domain heaps etc.

Leif

Thanks, can you clarify "image" for me? Is it .dll's or actual images? – Collen

@martpendle: Images is the term for DLLs, EXEs and similar. They are loaded into memory to execute code from them and therefore likely 100% committed memory. – Leif

Thanks, is there anyway I can see which ones are loaded and how much memory they are taking up? – Collen

No doubt Windbg can do it to but VMMap from Sysinternals would show that and more quit easily. – Notation

Thanks, if I run !eeheap on its own then I see 8 heaps and the bytes shown there total the same amount of bytes shown under "GC Heap Size". I dont see any other heap types. Am I doing something wrong? (i have added this to my question) – Collen

lm lists all images. You can calculate the size from the output. !lmi <name> also includes the size. Don't worry too much about images - there's usually not much to optimize. – Leif

I think you can not simply add memory usage as above to calculate the 1GB committed memory, that is because, you can not ensure that 235 MB in Heaps are committed, right? – Fulgurous