一：背景
1. 講故事
昨天有位朋友找到我，說他的程式記憶體存在洩露導致系統特別卡，大地址也開了，讓我幫忙看一下怎麼回事？今天上午看了下dump，感覺挺有意思，在我的分析之旅中此類問題也蠻少見，算是完善一下體系吧。
二：WinDbg 分析
1. 到底是哪裡的洩露
在.NET高階除錯訓練營中，我多次告訴學員們，在分析此類問題時一定要搞清楚是託管還是非託管的問題，否則就南轅北轍啦，接下來使用 !address -summary 觀察下記憶體段。
0:000:x86> !address -summary
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
<unknown> 17673 cd777000 ( 3.210 GB) 83.76% 80.26%
Image 3087 1c14c000 ( 449.297 MB) 11.45% 10.97%
Free 1418 aae6000 ( 170.898 MB) 4.17%
Heap32 11 6ee0000 ( 110.875 MB) 2.82% 2.71%
Stack32 186 39c0000 ( 57.750 MB) 1.47% 1.41%
Stack64 186 f80000 ( 15.500 MB) 0.39% 0.38%
Other 24 1da000 ( 1.852 MB) 0.05% 0.05%
Heap64 4 190000 ( 1.562 MB) 0.04% 0.04%
TEB64 62 7c000 ( 496.000 kB) 0.01% 0.01%
TEB32 62 3e000 ( 248.000 kB) 0.01% 0.01%
Other32 1 1000 ( 4.000 kB) 0.00% 0.00%
PEB64 1 1000 ( 4.000 kB) 0.00% 0.00%
PEB32 1 1000 ( 4.000 kB) 0.00% 0.00%
--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 16566 be8c2000 ( 2.977 GB) 77.67% 74.43%
MEM_IMAGE 4210 245be000 ( 581.742 MB) 14.82% 14.20%
MEM_MAPPED 421 12403000 ( 292.012 MB) 7.44% 7.13%
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_COMMIT 18901 e2904000 ( 3.540 GB) 92.36% 88.50%
MEM_RESERVE 2296 1297f000 ( 297.496 MB) 7.58% 7.26%
MEM_FREE 1519 ad6d000 ( 173.426 MB) 4.23%
仔細觀察卦中資訊：可以看到總的提交記憶體 MEM_COMMIT = 3.5G 都被 <unknown>=3.2G 這塊給吃掉了，這表示當前是一個赤裸裸的 非託管記憶體洩露 ，是某種程式碼透過 VirtualAlloc 這種方式直取 Windows記憶體管理器 記憶體，既然能用上 VirtualAlloc 肯定就不是業務程式設計師造成的，要想洞察 VirtualAlloc 的呼叫棧除了對程式安插監控和掛鉤子，其餘也沒什麼好辦法了，僅僅從現有的 dump 中觀察其實很難。
2. 真的沒有希望嗎
既然不知道是誰分配的，我們只能觀察事發現場，或許能從記憶體現場中找到點答案，那怎麼找事發現場呢？熟悉 Windows記憶體管理 的朋友都知道，要想分配記憶體，首先要在 虛擬地址 上分配一個記憶體段，然後將我們的資料放在記憶體段中的記憶體頁上，所以思路就是找到所有 COMMIT 的 SEGMENT 即可，使用 !address -f:Unk,MEM_COMMIT 觀察所有 Unk 的提交記憶體段。
0:000:x86> !address
BaseAddr EndAddr+1 RgnSize Type State Protect Usage
-----------------------------------------------------------------------------------------------
79530000 79550000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
79550000 79570000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
79580000 795a0000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [NatK............]
795a0000 795c0000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [........d.......]
795c0000 795e0000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
79620000 79640000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
79640000 79660000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
79660000 79680000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
79690000 796b0000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
796c0000 796e0000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [..d.i.v...c.l.a.]
796e0000 79700000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [t...p.r.o.t.o.t.]
79700000 79720000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [t...p.r.o.t.o.t.]
79720000 79740000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [........8..z....]
79740000 79760000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
79760000 79780000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [........d.......]
79780000 797a0000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [.....OP...vy....]
797a0000 797c0000 20000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
797c0000 797c1000 1000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE <unknown> [U...E.....H..E.P]
797c1000 797e0000 1f000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
797e0000 797e1000 1000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE <unknown> [U...E.....H..E.P]
797e1000 79800000 1f000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE <unknown> [................]
...
卦中資訊太多了，刷了好久才刷完，Break 之後觀察記憶體段，發現 RgnSize = 20000 的段貌似要多一些，為了發現 0x20000 的size到底有多少，這裡需要寫一段指令碼進行統計，截圖如下：
從卦中看 128k 的記憶體段個數就佔用了 9000+，應該是什麼東西分配了記憶體但沒有合理釋放。
由於沒有給程式裝監控，只能看記憶體段的地址上的內容了，這裡使用 windbg 自帶的 .writemem 命令將記憶體寫到檔案中觀察，簡單觀察之後，發現裡面有很多的 js 程式碼以及 html，比如下面的 PopupCalendar 方法，截圖如下：
3. 繼續乘勝追擊
既然抽到的幾個記憶體段有這些 網頁內容，但不見得大部分記憶體段都有這些內容，那怎麼去驗證呢？可以使用 s 搜尋記憶體去求證一下，比如我全記憶體搜尋包含 PopupCalendar 的記憶體段有多少。
0:000:x86> s-a 0 L?0xffffffff "PopupCalendar"
08a4ed7c 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 53 74 79 PopupCalendarSty
096f8fa3 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
096f9026 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
096ff5bb 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
096ff63e 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
...
f5fec996 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
f5ff2f2b 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
f5ff2fae 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
f5ff9543 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
f5ff95c6 50 6f 70 75 70 43 61 6c-65 6e 64 61 72 28 22 6f PopupCalendar("o
從記憶體地址看：PopupCalendar 從虛擬地址開頭的 08a4ed7c 到虛擬地址快結束的 f5ff95c6 都遍佈著這樣的字元，而且高達 1532 處，這也就說明當前非託管記憶體中有大量的 html 頁面被分配，但沒有被釋放，這也就是問題所在。
有了這些資訊後接下來就找朋友反饋，為什麼非託管記憶體中有這麼多的 html 頁面，是不是在 WPF 中不合理的使用了什麼 瀏覽器引擎 ，分配之後未合理釋放導致的洩露？
三：總結
這次事故應該是第三方元件在使用 html 的方式上造成的洩露，把包圍圈縮小到這裡相信朋友能很快的找到問題，驗證問題。
PS：在 dump 中尋找非託管記憶體洩露其實很多時候都比較絕望，需要你對 Windows記憶體管理 有一個比較深入的理解，還需要一個不驕不躁的分析心態。
