'"Lock cont." column in WinDbg heap stats output

Does anyone know the meaning of the "Lock cont." column in WinDbg's "!heap -s" output?

Background: I have a running server process on Win10 that seems to have a significant heap leaks (several hundred MB) that occur every few hours. UMDH snapshots seemed to have reasonable data but did not show any significant leak. Internal object counters of the running software are pretty constant also. I must not stop the running process in its environment and can't reproduce it on other machines yet. So I'm looking for clues in process dumps that could help reproducing the problem.

Below are two heap stat outputs of two dumps taken during 3 days of uptime. The "Lock cont." column looks suspicious to me. I can't find any member that would correspond to it in the _HEAP structure of that heap.

************************************************************************************************************************
                                              NT HEAP STATS BELOW
************************************************************************************************************************
NtGlobalFlag enables following debugging aids for new heaps:
    stack back traces
LFH Key                   : 0x3f35bc5ac7ba9927
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
000002565ca90000 08000002  113596  99912 113492   1879   453    11    1     34   LFH
0000025656610000 08008000      64      4     64      2     1     1    0      0      
000002565e8a0000 08001002    3228   2448   3124    543    27     3    0      0   LFH
    External fragmentation  22 % (27 free blocks)
000002565ef70000 08001002      60      8     60      5     1     1    0      0      
000002565ef40000 08001002     164     36     60     10     3     1    0      0   LFH
000002565f760000 08001002      60      8     60      1     1     1    0      0      
0000025661af0000 08001002    1184    652   1080    272    20     2    0      0   LFH
-------------------------------------------------------------------------------------

************************************************************************************************************************
                                              NT HEAP STATS BELOW
************************************************************************************************************************
NtGlobalFlag enables following debugging aids for new heaps:
    stack back traces
LFH Key                   : 0x3f35bc5ac7ba9927
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
000002565ca90000 08000002  680176 676160 680072  13730  1262    65    2  12c41   LFH
0000025656610000 08008000      64      4     64      2     1     1    0      0      
000002565e8a0000 08001002    7320   5120   7216   1983    76     4    0      c   LFH
    External fragmentation  38 % (76 free blocks)
000002565ef70000 08001002      60      8     60      5     1     1    0      0      
000002565ef40000 08001002     164     36     60     10     3     1    0      0   LFH
000002565f760000 08001002      60      8     60      1     1     1    0      0      
0000025661af0000 08001002    1184    652   1080    269    22     2    0      0   LFH
-------------------------------------------------------------------------------------
c++heap-memorywindbg


Solution 1:[1]

"cont." is the abbreviation for "contention", so "Lock cont." is "lock contention".

The global heap is multithreaded, but access is behind a lock; if a thread tries to access the global heap while another has a lock on it, then it has to wait (the contention). So this number is the number of times that several threads tried to use the heap at the same time.

For the data structure, look at dt nt!_HEAP_COUNTERS, maybe +0x024 LockCollisions : Uint4B.

For the UMDH part: you might need to increase the size of the user mode stack trace database using gflags.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1

Related Questions