C# Windbg中的高锁数！heap-s，what'；下一步如何检测非托管内存泄漏？

我们的一个PRD small win服务在几个小时内突然飙升至80+GB内存，然后下降并稳定在6+GB内存，它通常仅在200 MB以下使用。我在6+GB时抓取了一个内存转储，并重新启动了服务器，一切都恢复正常。我正在调查它为什么会飙升到这么高，为什么会稳定在6+GB

我发现这是一个非托管内存泄漏问题，因为CLR堆很小：

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x000000910083ff20
generation 1 starts at 0x00000091007caba0
generation 2 starts at 0x0000009100001000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000009100000000  0000009100001000  00000091029691f0  0x29681f0(43418096)
Large object heap starts at 0x0000009110001000
         segment             begin         allocated              size
0000009110000000  0000009110001000  000000911013dcb8  0x13ccb8(1297592)
Total Size:              Size: 0x2aa4ea8 (44715688) bytes.
------------------------------
***GC Heap Size:            Size: 0x2aa4ea8 (44715688) bytes.***

但是堆摘要很高，更令人怀疑的是，锁计数很高：

0:000> !heap -s


************************************************************************************************************************
                                              NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key                   : 0x45d65d36d8f8b642
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
**000000917aa90000 00000002 6718396 6682116 6718196  71860  5580   419    2     93   LFH**
000000917a850000 00008000      64      4     64      2     1     1    0      0      
000000917acd0000 00001002    1280     88   1080     15     7     2    0      0   LFH
000000917ac90000 00001002    1280    108   1080     24     8     2    0      0   LFH
000000917b160000 00001002    1280    124   1080      7    10     2    0      0   LFH
000000917b310000 00041002      60      8     60      5     1     1    0      0      
000000917bd40000 00041002     260     36     60      4     3     1    0      0   LFH
0000009118080000 00001002    1084   1024   1084   1021     2     1    0      0      
-------------------------------------------------------------------------------------

0:000> !heap -stat -h 000000917aa90000
 heap @ 000000917aa90000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    2d0b0 373e - 9b845aa0  (39.37)
    10d1 41962 - 44eed902  (17.45)
    ddc8 373e - 2fdbae70  (12.12)
    7ab8 373e - 1a7b4090  (6.70)
    7168 373e - 1878cf30  (6.20)
    29d1 6e6b - 1209485b  (4.57)
    35d1 372d - b995cbd  (2.94)
    31d1 372d - abca8bd  (2.72)
    12d1 6e5a - 81c6b7a  (2.05)
    21d1 3746 - 74d2626  (1.85)
    fd1 6e6c - 6d27a2c  (1.73)
    1cd1 372d - 635f7bd  (1.57)
    40 22b52 - 8ad480  (0.14)
    100 6ef7 - 6ef700  (0.11)
    200 374f - 6e9e00  (0.11)
    c3500 5 - 3d0900  (0.06)
    80 6edb - 376d80  (0.05)
    d8 374e - 2ea9d0  (0.05)
    249f18 1 - 249f18  (0.04)
    90 3792 - 1f4220  (0.03)

然后我做了

！堆-flt s 2d0b0

我不能做

！heap-p-a

查看堆栈，因为我没有在PRD中启用gflags

相反，我尝试使用

dc 00000092b7088bb0 L200

根据字符串值进行猜测。在第一个卡盘

（2D0B0373E-9b845aa0（39.37）

中没有任何意义，但在第二个卡盘

（10d1 41962-44eed902（17.45））

中，我发现了类似的东西

00000092`b70b0250  00000000 00000000 44440000 4e4f4d2d  ..........DD-MON
00000092`b70b0260  0052522d 00000000 00000000 00000000  -RR.............
00000092`b70b0270  00000000 00000000 00000000 00000000  ................
00000092`b70b0280  00000000 00000000 00000000 00000000  ................
00000092`b70b0290  00000000 48480000 2e494d2e 46585353  ......HH.MI.SSXF
00000092`b70b02a0  4d412046 00000000 00000000 00000000  F AM............
00000092`b70b02b0  00000000 00000000 00000000 00000000  ................
00000092`b70b02c0  00000000 44440000 4e4f4d2d 2052522d  ......DD-MON-RR 
00000092`b70b02d0  4d2e4848 53532e49 20464658 00004d41  HH.MI.SSXFF AM..
00000092`b70b02e0  00000000 00000000 00000000 00000000  ................
00000092`b70b02f0  00000000 00000000 00000000 00000000  ................
00000092`b70b0300  00000000 00000000 00000000 00000000  ................
00000092`b70b0310  00000000 48480000 2e494d2e 46585353  ......HH.MI.SSXF
00000092`b70b0320  4d412046 525a5420 00000000 00000000  F AM TZR........
00000092`b70b0330  00000000 00000000 00000000 00000000  ................
00000092`b70b0340  00000000 00000000 00000000 00000000  ................
00000092`b70b0350  00000000 00000000 44440000 4e4f4d2d  ..........DD-MON
00000092`b70b0360  2052522d 4d2e4848 53532e49 20464658  -RR HH.MI.SSXFF 
00000092`b70b0370  54204d41 0000525a 00000000 00000000  AM TZR..........

它看起来像Oracle数据库查询日期时间格式字符串。我们确实使用Oracle，我很难相信我们正在泄漏Oracle连接，因为这个小型服务已经运行多年，这是第一次发生这种情况。 这就是我现在能走的路

很抱歉提出了这么长的问题，谢谢你花时间阅读

总结一下我的问题：

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x000000910083ff20
generation 1 starts at 0x00000091007caba0
generation 2 starts at 0x0000009100001000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000009100000000  0000009100001000  00000091029691f0  0x29681f0(43418096)
Large object heap starts at 0x0000009110001000
         segment             begin         allocated              size
0000009110000000  0000009110001000  000000911013dcb8  0x13ccb8(1297592)
Total Size:              Size: 0x2aa4ea8 (44715688) bytes.
------------------------------
***GC Heap Size:            Size: 0x2aa4ea8 (44715688) bytes.***

在！heap-s中，锁计数列的意思是什么，它看起来像一个 我可以继续挖掘的问题的指示器，请给我指出一个 我可以阅读的方向或博客

这些原始数据字符串是否对您而不是Oracle敲响了另一个警钟？您有过类似的问题吗

我们确实使用了很多.net远程处理。我知道它很旧，而且我从来没有深入研究过。它可能是这个问题的一个因素吗

我不能在PRD中做任何事情，也不能在DEV/TEST中重现这个问题，还有其他的方向吗

---

“Lock cont.”不是“Lock count”。它是“锁争用”。它是两个线程试图同时使用堆的次数。93对于一个具有大量线程的长时间运行进程来说并非不合理。哇，从没想过“cont”可能意味着计数以外的其他东西。如果这不是不寻常的话，我是否已经走到了死胡同了？我从来没有见过

count

缩写

cont

。既然你有堆，你可以四处看看里面有什么，看看内存是否只是泄漏了。@RaymondChen我怎么“看到里面有什么？”除了“dc 000000 92B7088BB0 L200”没有给我太多有意义的信息？你说的“看看内存是否只是泄漏”是什么意思？我知道它是泄漏的，因为内存过高，管理的堆大小很小。有14000个数据块，你看了其中的两个。使用

.writemem

将所有数据写入磁盘，然后使用一些外部分析工具检查内容。如果没有其他帮助，请将崩溃转储转换为图片就像德米特里·沃斯托科夫一样，似乎其他人也这样做过：