0

So i am in the lucky position of learning something total new today. Analysing a dump file from a spooler process in order to find an answer what might be the cause for a 2.5gb memory consumption. I got a dump file of the spooler and installed Windbg. I loaded the file and played around with the commands.

!heap -s looks promising:

LFH Key                   : 0xa2020c358efe35ad
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
000001fee80c0000 00000002   65032  62408  64928   4607   704    16    0   27b0   LFH
000001fee7f70000 00008000      64      4     64      2     1     1    0      0      
000001fee7f80000 00001002 2767468 2745088 2767364  16720   416   175    0     13   LFH
000001fee8660000 00001002      60      8     60      5     1     1    0      0      
000001fee8d40000 00001002    1184    224   1080     89    10     2    0      0   LFH
000001fee8ec0000 00001002   47884  38444  47780   3499   128     9    0     11   LFH
000001fee9060000 00001002    1184    244   1080    152     7     2    0      0   LFH
000001fee9020000 00001002      60     16     60      5     2     1    0      0      
000001fee93a0000 00001002     164     24     60      3     2     1    0      0   LFH
000001fee9350000 00001002   31696  30592  31592    739   171     6    0     21   LFH
000001fee92c0000 00001002    1184    224   1080    139     6     2    0      0   LFH
000001fe850a0000 00001002   15508   7628  15404    277    47     5    0      0   LFH
-------------------------------------------------------------------------------------

Now i am trying to find out what the address 000001fee7f80000 could belong to.

Any helping hand would be great.

Some other related informations I tried:

0:000> !address 000001fee7f80000   

Usage:                  Heap
Base Address:           000001fe`e7f80000
End Address:            000001fe`e7f8f000
Region Size:            00000000`0000f000 (  60.000 kB)
State:                  00001000          MEM_COMMIT
Protect:                00000004          PAGE_READWRITE
Type:                   00020000          MEM_PRIVATE
Allocation Base:        000001fe`e7f80000
Allocation Protect:     00000004          PAGE_READWRITE
More info:              heap owning the address: !heap 0x1fee7f80000
More info:              heap segment
More info:              heap entry containing the address: !heap -x 0x1fee7f80000


Content source: 1 (target), length: f000



0:000> !heap -x 0x1fee7f80000
Entry             User              Heap              Segment               Size  PrevSize  Unused    Flags
-------------------------------------------------------------------------------------------------------------
000001fee7f80000  000001fee7f80010  000001fee7f80000  000001fee7f80000       720         0         1  busy
jeb
  • 848
  • 5
  • 16
  • I find it way easier to analyze mem leaks with [UMDH](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-umdh-to-find-a-user-mode-memory-leak) or perfmon. There is some capacity to detect leaks with the classic windbg and gflags (using allocation stack bracktraces) but without them, it's pretty much searching a needle in the haystack. – Neitsa Jul 07 '23 at 13:55
  • @Neitsa thank you, I was not aware UMDH existis maybe that's all i need in order to solve the problem. – jeb Jul 07 '23 at 14:00

0 Answers0