最近，我們的軟件在運行過程中，遇到了一個很詭異的問題。

軟件在一個測試同事的win7 32位系統上運行1個多小時后會閃退崩潰。奇怪的是，在測試該產品的主要測試人員的win10電腦上，則從未出現過這個情況。

下面詳細介紹一下這個問題的排查過程，以及給我們的一些啟示!

1、初步分析

我們在軟件中安裝了異常信息捕獲機制，但是軟件發生閃退時，并沒有捕獲到有效dump文件(崩潰信息存放在dump文件中)，生成的dump文件是空的!可能是在導出異常上下文信息時發生了二次崩潰，所以沒有生成有效的dump文件。

這個問題在他電腦上出現過好幾次了。于是，讓同事將windows系統上常用的軟件調試利器windbg掛載到目標進程上，看看復現閃退時能否抓到有效的信息。結果問題復現后，抓到的異常上下文對應的代碼模塊基本是不可能產生異常的，所以問題排查還是沒有頭緒!

突然無意中想到，軟件是運行一兩個小時后出現的，難道是軟件中有內存泄漏?把進程的虛擬內存耗完了，導致再申請內存時都失敗了，產生了空指針，導致空指針訪問違例，導致軟件閃退。這種假設可以解釋windbg捕獲到的不可能發生異常的代碼塊的現象了!

于是重新啟動軟件，觀察了任務管理器中我們軟件對應的進程的內存占用情況。看到我們軟件的進程的內存一直在增長，在運行1個多小時后竟然漲到1GB多了，這下基本可以確定，肯定是內存泄漏導致的內存被耗完，從而導致軟件再申請內存失敗了，導致訪問了空指針，導致軟件閃退了!

下面就是使用一些內存泄漏的檢測工具來來定位內存泄漏的模塊了!

2、使用騰訊的tMemMonitor內存泄漏檢測工具檢測內存泄露

最開始嘗試使用騰訊的tMemMonitor內存泄漏檢測工具，檢測一下內存泄漏發生在哪個模塊中。

具體的做法是，使用tMemMonitor將我們的軟件啟動起來：

讓軟件運行一個多小時，讓軟件產生1GB以上的內存泄漏，然后關閉軟件，如果檢測到內存泄漏就會彈出生成檢測報告的提示，打開報告就可以看到檢測結果了。

注意，tMemMonitor內存泄漏檢測工具只能檢測release版本的程序，被檢測程序必須由tMemMonitor啟動，并且被監測程序在退出時必須是正常退出的。如果關閉軟件時發生了崩潰，tMemMonitor是不會生成內存泄漏報告的。

檢測報告中會顯示發生內存泄漏的dll或exe的模塊名，并且會將相關的函數調用堆棧打印出來，比如：

但實際跑下來，看到檢測報告，并沒有看到有用的信息，檢測到泄漏內存的都比較小，和實際泄漏的內存大小相差甚遠!難道不是用戶態的內存泄漏?是內核態的內存泄漏?

3、使用windbg檢測內存泄漏

使用tMemMonitor工具分析不出來，于是又嘗試使用windbg分析了一把。使用此方法之前，要預先安裝好windbg工具。最新版本的windbg是從內置在微軟官方的SDK中的，可以自行到微軟的官方網站上下載安裝。

此內存泄漏檢測方法，會用到windbg安裝路徑下的gflags.exe和umdh.exe程序，如下所示：

具體的操作步驟是：

1)打開cmd窗口，切換到windbg的安裝目錄中，比如我的安裝路徑是：C:\Program Files\Windows Kits\10\Debuggers\\x86。

2)先使用命令設置用戶態函數棧回溯標記：gflags /i xxxxxxxxx.exe +ust，具體含義可以以“gflags /?”查看gflags相關命令行的參數說明：

3)使用umdh.exe將時刻1時的堆內存分配情況輸出到日志文件中：umdh.exe -pn:xxxxxxxxx.exe -f:E:\log1.txt。其中，umdh.exe是windows debug tools 下的一款命令行工具，它的全程是User Mode Dump Heap 這個工具會分析當前進程在堆上分配的內存。可以使用“umdh /?”查看umdh.exe支持的命令行參數，以及如何使用的：

然后讓程序運行一個多小時后，讓程序有足夠多的內存泄漏，然后再用命令：umdh.exe -pn:xxxxxxxxx.exe -f:E:\log2.txt，導出時刻2時的堆內存分配使用情況。

4)使用命令：umdh.exe E:\log1.txt E:\log2.txt -f:E:\result.txt，比較兩個時刻中間的時間段的堆內存的增長及使用情況，找出可能出現內存泄漏的地方：

這似乎還是有問題，明明泄漏了1GB多的內存，怎么檢測結果中最多泄漏的那項計算出來泄漏的內存才200MB，相差的比較多的，看來windbg似乎也不可信啊!

4、使用代碼分塊注釋的辦法，定位到發生內存泄漏的模塊

問題還是沒查出來，這個就比較頭疼了，軟件馬上要對外發布正式商用版本了，這個問題必須要解決啊!

最后沒辦法，只能采用逐步注釋代碼的方法，看看能否定位內存泄漏發生在哪個模塊中。經多次嘗試發現，與dcs數據協作模塊的庫有關系。然后查看了一下dcs服務器的連接狀態，服務器連不上，底層一直在不斷的定時重連，難道是每次重連失敗后沒有釋放socket套接字等資源導致的內存泄漏?

于是找到相關模塊的負責同事，讓他們排查，排查下來后發現，確實是服務器重連失敗后沒有將相關資源釋放掉導致的內存泄漏(使用websocket和服務器通信的)!

后來在我自己的兩臺電腦上驗證了一下，軟件運行在我win7 32位電腦上是有內存泄漏的，但在我另一臺win7 64位系統上則沒有內存泄漏。在測試同事的win10系統上，也詳細觀察了，win10系統上居然沒有內存泄漏，軟件運行一切正常!這個內存泄漏難道是和操作系統是強相關的?

5、進一步研究確認

知道大概的原因之后，我又用windbg和tMemMonitor都重新檢測了一下內存泄漏，看看哪個工具更好用，定位的更準確!

我們選擇檢測的時間段內，軟件已經占用了1.15GB的內存，內存泄漏估計得有900MB左右了。

此時windbg分析出來的內存泄漏模塊確實是對的，如下所示：

但是泄漏的內存只有200MB左右，這和實際的內存泄漏大小有很大的出入。當前windbg分析出的內存泄漏是用戶態的，可能有部分泄漏發生在程序的內核態?

而騰訊的tMemMonitor和windbg比要遜色不少，tMemMonitor不僅檢測出的泄漏內存大小比實際泄漏大小要小很多，而且根本沒有定位到發生內存泄漏的模塊。所以，windbg還是要強大不少的。

經后來驗證，在另一臺的win7 64位系統中，之前之所以沒有內存泄露，是因為這臺機器上登錄平臺的賬號是沒有dcs服務的權限，就不會登錄dcs服務器，就不會觸發dcs服務器的重連。而本例中的內存泄漏就是dcs重連失敗后沒有清理相關資源導致的。后來使用一個有dcs服務權限的賬號在這臺win7 64位系統中登錄我們的軟件，同樣也出現了內存泄漏。

但同樣的代碼、同樣的軟件在win10系統中卻沒有內存泄漏，通過打印日志可以確定win10系統中也觸發了dcs服務器的重連了，這可能是win10系統的內存管理機制和win7不同引起的吧!

6、總結

遇到問題后，要進行深入細致的研究，要搞清楚各種情況的來龍去脈!在詳細的研究過程中要多思考多驗證，會有新的發現和新的收獲!