I encountered a strange problem when analyzing memory leaks in windbg... Memory was lost...
!address -summaryshows MEM_COMMIT = 3.3G
0:048> !address -summary
Mapping file section regions...
Mapping module regions...
Mapping PEB regions...
Mapping TEB and stack regions...
Mapping heap regions...
Mapping page heap regions...
Mapping other regions...
Mapping stack trace database regions...
Mapping activation context regions...
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 447 7df8`acd2e000 ( 125.971 TB) 98.42%
<unknown> 1688 207`19afc000 ( 2.028 TB) 99.96% 1.58%
Stack 234 0`18260000 ( 386.375 MB) 0.02% 0.00%
Heap 120 0`168ec000 ( 360.922 MB) 0.02% 0.00%
Image 1856 0`0aa00000 ( 170.000 MB) 0.01% 0.00%
Other 11 0`001dd000 ( 1.863 MB) 0.00% 0.00%
TEB 78 0`0009c000 ( 624.000 kB) 0.00% 0.00%
PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%
--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_MAPPED 387 200`03a66000 ( 2.000 TB) 98.59% 1.56%
MEM_PRIVATE 1745 7`44e5c000 ( 29.077 GB) 1.40% 0.02%
MEM_IMAGE 1856 0`0aa00000 ( 170.000 MB) 0.01% 0.00%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 447 7df8`acd2e000 ( 125.971 TB) 98.42%
MEM_RESERVE 631 206`7d08b000 ( 2.025 TB) 99.84% 1.58%
MEM_COMMIT 3357 0`d6237000 ( 3.346 GB) 0.16% 0.00%
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 1587 0`c52ee000 ( 3.081 GB) 0.15% 0.00%
PAGE_READONLY 1147 0`0816b000 ( 129.418 MB) 0.01% 0.00%
PAGE_EXECUTE_READ 312 0`05f0a000 ( 95.039 MB) 0.00% 0.00%
PAGE_EXECUTE_READWRITE 57 0`019a1000 ( 25.629 MB) 0.00% 0.00%
PAGE_NOACCESS 129 0`013d8000 ( 19.844 MB) 0.00% 0.00%
PAGE_READWRITE|PAGE_GUARD 78 0`000ec000 ( 944.000 kB) 0.00% 0.00%
PAGE_WRITECOPY 47 0`0006f000 ( 444.000 kB) 0.00% 0.00%
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free 1c6`45d8f000 7c2e`42281000 ( 124.181 TB)
<unknown> 7dfc`a2a6d000 1f8`bfa04000 ( 1.972 TB)
Stack 45`800c0000 0`0104b000 ( 16.293 MB)
Heap 1c6`3636f000 0`07d01000 ( 125.004 MB)
Image 7ffa`bafbf000 0`00e7a000 ( 14.477 MB)
Other 1c0`05d40000 0`00181000 ( 1.504 MB)
TEB 45`f68b0000 0`00002000 ( 8.000 kB)
PEB 45`f6939000 0`00001000 ( 4.000 kB)
!eeheapshows the total memory of the heap 900M。[gc (798M) loader(132M) ]
0:048> !eeheap
Loader Heap:
--------------------------------------
System Domain: 00007ffa7929d0a0
...
Module 00007ffa1e71d6a0: Size: 0x0 (0) bytes.
Module 00007ffa1ec8da48: Size: 0x0 (0) bytes.
Module 00007ffa1ee3cb18: Size: 0x0 (0) bytes.
Module 00007ffa1f439618: Size: 0x0 (0) bytes.
Total size: Size: 0x0 (0) bytes.
--------------------------------------
Total LoaderHeap size: Size: 0x7dfd000 (132108288) bytes total, 0x2d4000 (2965504) bytes wasted.
=======================================
Number of GC Heaps: 16
------------------------------
Heap 0 (000001C0069F7AE0)
...
Heap 15 (000001C006E01BA0)
generation 0 starts at 0x000001C5A7770600
generation 1 starts at 0x000001C5A776B898
generation 2 starts at 0x000001C5A7121000
ephemeral segment allocation context: none
segment begin allocated size
000001C5A7120000 000001C5A7121000 000001C5A883B790 0x171a790(24225680)
Large object heap starts at 0x000001C5E7121000
segment begin allocated size
000001C5E7120000 000001C5E7121000 000001C5E774D1E0 0x62c1e0(6472160)
Pinned object heap starts at 0x000001C5F7121000
000001C5F7120000 000001C5F7121000 000001C5F7390EF8 0x26fef8(2555640)
Heap Size: Size: 0x1fb6868 (33253480) bytes.
------------------------------
GC Heap Size: Size: 0x2f9480a0 (798261408) bytes.
!eeheap -sshows 68M of unmanaged memory
0:048> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0x741d83161cb41a46
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
000001c0057d0000 00000002 97696 68108 97304 10566 686 18 7 51 LFH
External fragmentation 15 % (686 free blocks)
000001c005750000 00008000 64 4 64 2 1 1 0 0
000001c005b30000 00001002 3516 2564 3124 116 43 3 0 1 LFH
000001c006790000 00001002 60 8 60 5 1 1 0 0
000001c006740000 00001003 60 8 60 6 1 1 0 N/A
000001c007030000 00001002 1472 156 1080 2 14 2 0 0 LFH
000001c007110000 00041002 60 8 60 5 1 1 0 0
000001c617d60000 00041002 452 24 60 0 2 1 0 0 LFH
000001c616060000 00001002 1472 216 1080 22 11 2 0 0 LFH
-------------------------------------------------------------------------------------
Conclusion: gc heap(798M) loader heap(132M) unmanged heap(68M) is much smaller than 3.3G of process memory.
Where did my remaining memory of about 2G go? Thank you all in advance.
CodePudding user response：
what are you looking for in the dump if you want to know the details of MEM_COMMIT
you can issue !address -f:MEM_COMMIT
use .logopen x:\foo.ext and log the results to a file
as the resulting output maybe large
here is a verification of summary mem_commit size versus filtered mem_commit size
0:000> .shell -ci "!address -summary" grep -i mem_COMMIT
MEM_COMMIT 155 0`02f3d000 ( **47.238 MB**) 0.00% 0.00%
.shell: Process exited
0:000> r$t0=0;!address -f:MEM_COMMIT -c:"r $t0 = @$t0 %3";?? @$t0/1048576.0
double **47.23828125**
0:000>
CodePudding user response：
798 MB GC Heap (as mentioned by you)
132 MB Loader Heap (as mentioned by you)
68 MB Native Heap (as mentioned by you)
>15 MB Stacks (at 64kB each, for 234 Stacks)
170 MB Image (DLLs that are loaded)
-------
1183 MB
The rest is probably native heap as well, but with allocations > 512 kB, so they are not handled by the heap manager any more but will be treated like VirtualAlloc() calls and thus fall into the <unknown> category.