記一次 .NET 某工控視覺軟件非托管泄漏分析

作者：一線碼農(nóng)聊技術 2022-10-09 10:47:37

開發(fā) 前端

前段時間有位朋友找到我，說他的程序出現(xiàn)了非托管泄漏，某一塊的操作會導致非托管內(nèi)存上漲的很快，讓我?guī)兔δ嫦蚩聪率悄睦锏牟僮鳑]有釋放資源？既然找到我，那就上 WinDbg 分析吧。

一、背景

1.講故事

最近分享了好幾篇關于非托管內(nèi)存泄漏? 的文章，有時候就是這么神奇，來求助的都是這類型的dump，一飲一啄，莫非前定。讓我被迫加深對 NT堆?, 頁堆的理解，這一篇就給大家再帶來一篇內(nèi)存泄漏。

二、WinDbg 分析

1. 哪里的內(nèi)存泄漏

看內(nèi)存泄漏還是老規(guī)矩，使用 !address -summary 命令就可以了。

0:000> !address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    443      7fc`685d1000 (   7.986 TB)           99.82%
Heap                                    658        3`563aa000 (  13.347 GB)  92.89%    0.16%
<unknown>                               770        0`1ff5a000 ( 511.352 MB)   3.48%    0.01%
Image                                  1196        0`108ba000 ( 264.727 MB)   1.80%    0.00%
Stack                                   108        0`08c40000 ( 140.250 MB)   0.95%    0.00%
Other                                    31        0`081d8000 ( 129.844 MB)   0.88%    0.00%
TEB                                      36        0`00048000 ( 288.000 kB)   0.00%    0.00%
PEB                                       1        0`00001000 (   4.000 kB)   0.00%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                443      7fc`685d1000 (   7.986 TB)           99.82%
MEM_COMMIT                             2464        3`67933000 (  13.618 GB)  94.77%    0.17%
MEM_RESERVE                             336        0`300ec000 ( 768.922 MB)   5.23%    0.01%

從卦中看，當前進程有 13.6 G? 的提交內(nèi)存，NtHeap 占用了 13G?，很明顯這是非托管內(nèi)存泄漏，既然是非托管泄漏，那就需要二番戰(zhàn)，也就是讓朋友開啟 ust?，或者啟用應用程序驗證器 (Application Verifier)? 開啟頁堆，目的就是記錄分配這塊內(nèi)存的源頭，這里就讓朋友用 gflags 開啟下 ust，具體怎么開，這里就不介紹了，大家可以網(wǎng)上搜一下。

2. 追蹤 ust 加持下的調(diào)用棧

有了 ust 的加持，接下來就可以繼續(xù)分析，使用 !heap -s 觀察下 nt 堆的布局。

0:000> !heap -s
SEGMENT HEAP ERROR: failed to initialize the extention
NtGlobalFlag enables following debugging aids for new heaps:
    stack back traces
LFH Key                   : 0x0000004c4f657ebf
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
0000000000060000 08000002   32576  17212  32576    430   161     6    1      0   LFH
0000000000010000 08008000      64      8     64      5     1     1    0      0      
0000000008810000 08001002    1088    500   1088     15     5     2    0      0   LFH
...
0000000029fb0000 08001002   88320  67408  88320  32559   343    47  189    1b7   LFH
    External fragmentation  48 % (343 free blocks)
0000000029870000 08001002     512      8    512      3     1     1    0      0      
...
-------------------------------------------------------------------------------------

從卦中看，commit 最大的也就是 67408k = 67M?, 這和 13G? 差的不是一星半點，如果你了解 NtHeap 的布局，應該知道當分配內(nèi)存 > 512k? 的時候，會進入到 HEAP 的 VirtualAllocdBlocks? 雙向鏈表中，言外之意就是當你覺得內(nèi)存對不上的時候，就要觀察下這個鏈表了，即上圖中的 Virt blocks? 列，可以看到 handle=0000000029fb0000? 的 Virt blocks=189?，接下來繼續(xù)下鉆 handle=0000000029fb0000 這個堆。

0:000> !heap -h 0000000029fb0000 
SEGMENT HEAP ERROR: failed to initialize the extention
Index   Address  Name      Debugging options enabled
 23:   29fb0000 
    Segment at 0000000029fb0000 to 000000002a7b0000 (007eb000 bytes committed)
    Segment at 0000000026070000 to 0000000026170000 (000ff000 bytes committed)
    Segment at 0000000027d10000 to 0000000027f10000 (001f7000 bytes committed)
    Segment at 00000000318a0000 to 0000000031ca0000 (00400000 bytes committed)
    Segment at 0000000044a00000 to 0000000045200000 (005f1000 bytes committed)
    Segment at 000000004ae90000 to 000000004be60000 (00efc000 bytes committed)
    Segment at 000000005b3b0000 to 000000005c380000 (00e2e000 bytes committed)
    Segment at 000000005d8c0000 to 000000005e890000 (00cf1000 bytes committed)
    Segment at 000000005c380000 to 000000005d350000 (002e7000 bytes committed)
    Flags:                08001002
    ForceFlags:           00000000
    Granularity:          16 bytes
 ...
    Virtual Alloc List:   29fb0118
    Unable to read nt!_HEAP_VIRTUAL_ALLOC_ENTRY structure at 0000000043500000
    Uncommitted ranges:   29fb00f8

我去，卦中出現(xiàn)了不愿看到的 Unable to read nt!_HEAP_VIRTUAL_ALLOC_ENTRY structure at 0000000043500000?，也就是說顯示不出 _HEAP_VIRTUAL_ALLOC_ENTRY 結構，可以用 dt 驗證一下。

0:000> dt nt!_HEAP_VIRTUAL_ALLOC_ENTRY
Symbol nt!_HEAP_VIRTUAL_ALLOC_ENTRY not found.

為什么在他的機器上沒記錄到，可能和它生產(chǎn)服務器的 Windows 系統(tǒng)有關，這里就不細究原因，接下來的問題是：!heap? 命令失效，該怎么把 VirtualAllocdBlocks 給挖出來呢？只能純?nèi)巳饬?..

3. 如何人肉挖 VirtualAllocdBlocks

要想人肉挖，需要一些底層知識，比如下面三點。

VirtualAllocdBlocks 是什么？

VirtualAllocdBlocks 是一個記錄大塊內(nèi)存的雙向鏈表結構，可以用 dt nt!_HEAP 0000000029fb0000 命令從 HEAP 中找出來。

0:000> dt nt!_HEAP 0000000029fb0000
ntdll!_HEAP
   +0x118 VirtualAllocdBlocks : _LIST_ENTRY [ 0x00000000`43500000 - 0x00000000`32970000 ]
   +0x128 SegmentList      : _LIST_ENTRY [ 0x00000000`29fb0018 - 0x00000000`5c380018 ]
   ...

0:000> dt _LIST_ENTRY 0000000029fb0000+0x118
ntdll!_LIST_ENTRY
 [ 0x00000000`43500000 - 0x00000000`32970000 ]
   +0x000 Flink            : 0x00000000`43500000 _LIST_ENTRY [ 0x00000000`47240000 - 0x00000000`29fb0118 ]
   +0x008 Blink            : 0x00000000`32970000 _LIST_ENTRY [ 0x00000000`29fb0118 - 0x00000000`4ee90000 ]

從卦中可以看到， VirtualAllocdBlocks? 是一個擁有 Flink? 和 Blink 的雙向鏈表結構。

_HEAP_VIRTUAL_ALLOC_ENTRY 是什么？

我們都知道 heap 的 block <512k? 是 _HEAP_ENTRY? 結構，那 block >512k? 的塊就是 _HEAP_VIRTUAL_ALLOC_ENTRY 結構，不信的話可以用 dt 導出來。

0:016> dt nt!_HEAP_VIRTUAL_ALLOC_ENTRY
ntdll!_HEAP_VIRTUAL_ALLOC_ENTRY
   +0x000 Entry            : _LIST_ENTRY
   +0x010 ExtraStuff       : _HEAP_ENTRY_EXTRA
   +0x020 CommitSize       : Uint8B
   +0x028 ReserveSize      : Uint8B
   +0x030 BusyBlock        : _HEAP_ENTRY

從卦中可以看到，除了真正的分配 BusyBlock? 之外還有一些附屬信息，比如 CommitSize? , ReserveSize? 等等，接下來就可以抽取第一個節(jié)點地址加上 +0x30? 來找到這個真正的內(nèi)存分配塊，即 0x0000000043500000 + 0x30?，然后使用 !heap -p -a 就可以看到這個分配塊的源頭在哪里了。

0:000> !heap -p -a 0x0000000043500000 + 0x30
    address 0000000043500030 found in
    _HEAP @ 29fb0000
              HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
        0000000043500030 100100 0000  [00]   0000000043500060    1000040 - (busy VirtualAlloc)
        775bc35b ntdll! ?? ::FNODOBFM::`string'+0x00000000000153eb
        7fed230483b halcon!HXmalloc+0x000000000000008b
        7fed22dd81d halcon!HXAllocRLTmp+0x000000000000265d
        7fed22d6bd0 halcon!HXAllocTmp+0x0000000000000a80
        7fed44a346a halcon!HCancelWait+0x000000000000007a
        7fed2386b8f halcon!CCallHProc+0x000000000000073f
        7fe83e3bcf6 +0x000007fe83e3bcf6

 
0:000> !ip2md 0x000007fe83e3bcf6
MethodDesc:   000007fe83c39138
Method Name:  HalconDotNet.xxx
Class:        000007fe83c6b890
MethodTable:  000007fe83c3f300
mdToken:      0000000006000df5
Module:       000007fe83a7f498
IsJitted:     yes
CodeAddr:     000007fe83e3bb90
Transparency: Safe critical

可以看到第一塊 size= 0x1000040 byte = 16M? 的內(nèi)存是 HalconDotNet 分配的，接下來我們多抽幾個，或者用腳本來歸納一下，發(fā)現(xiàn)有大量的 88M 內(nèi)存占用，大體上歸為兩類：

C# 代碼分配未釋放：

內(nèi)部代碼：

三、總結

最后就是把這個結果給了朋友，讓朋友看下用 !ip2md 顯示出來的托管方法，為什么沒有釋放，是不是漏了。

這個dump可以看出是因為對 halcon? 做了一套 DotNet 版的封裝上出現(xiàn)了一些瑕疵，這個 dump 的難點在于當 !heap 擴展命令失效的情況下，如何通過純手工的方式把 NTHeap 剝離的明明白白。

責任編輯：武曉燕來源：一線碼農(nóng)聊技術

NET 視覺軟件

成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

記一次 .NET 某工控視覺軟件 非托管泄漏分析