原博地址：http://blog.csdn.net/zdl1016/article/details/3948131
學習IP：http://www.programlife.net/handle-leak-debug-skill.html
描述:
引擎exe,運行10多分鐘後, 自動退出. 我靠, 退的悄聲無息的. 甚至連個windows抱歉的界面都不彈出來.
分析:
1: 關於程序悄聲無息退出的問題
一個程序出錯, 一般都是windows很抱歉, 進程要關閉啥的, 問你要不要調試. 這次進程居然屁都不放一個就say88了.中間肯定有問題.
進程出錯, 一般windows都會生成響應的dump文件(內存轉儲),以供調試分析用. 而且如果指定了調試工具, 會提示調用相應的工具調試, 比如vs2005. 不同的電腦有不同的設置. 當時xEye是運行在小主機上的, 沒有安裝vs2005, 自然也沒有提示調試.
但是, 我想, 一定有dump悄悄的生成了. 一般情況下, 這個在程序崩潰的時候, 生成dump的任務是drwtsn32.exe這個工具負責的. 爲什麼這個工具知道進程出問題了都不提示一下呢? 改改設置看看.
運行=>drwtsn32=>選中視覺通知, 選中聲音通知,選中故障轉儲文件.
ok, 下次程序再崩掉的時候, drwtsn就會提示你了.
（2009-06-29日補充：多線程導致的問題，會讓程序悄然退出！vs2005都拿其沒則！崩潰線程任何有價值的信息都沒有！後來發現，是線程間通信的數據結構不一致導致的！）
2:爲什麼程序會跑一段時間就退出?
老聶同志發現xEye存在嚴重的句柄泄漏問題. 難道是此問題?
通過任務管理器=>選擇列=>可以顯示進程的打開的句柄書, xEye的句柄以每秒100個的速度狂長.
通過process explorer(微軟的)工具, 查看xEye打開的句柄, 發現不斷增加的是Event handle.
但是代碼裏面沒有CreateEvent()函數.
問題處在哪裏呢?
請出windbg幫忙.
固然不負重望. 通過一個視頻教程裏面演示用windbg檢測句柄泄漏, 很快定位出是easyusb.dll的問題. 我靠. 這個原來是外來的動態庫的問題.(此問題彤哥通過本方法,一個工程一個工程的替換, 也發現了是easyusb.dll的問題, 但是效率甚低)
2、windbg調試
1）找到windbgs安裝目錄下的gflags.exe工具，該工具可用來打開windows自帶的一些調試選項，具體gflags.exe的詳細使用可以查看windbg幫助； 這裏我們設置勾上application verifiwer，該工具主要可用來對程序做一些穩定性的檢測，本次調試主要用於保存棧的相關信息。同時設置stack backtrace即棧的大小爲10.
2）運行windbg，打開第一步編譯的程序，並使其跑起來；此時你查看任務管理器中的句柄信息，會發行相應進程句柄一直在增加。
3）windbg用ctrl+break命令中斷進程運行，用！htrace -enable命令開啓句柄檢測；htrace提供了進行句柄相關檢測的命令，可查看windbg幫助。 同時用g命令讓程序運行。
4）再次中斷進程，使用！htrace -snapshot命令，獲得此時進程句柄的鏡像。並再次讓程序運行。
5）第三次中斷進程運行，我們再使用！htrace -diff命令獲得當前句柄狀態與第4步 snapshot鏡像句柄的差異； 我們可以發現：新增很多打開的句柄，平常情況下這些打開的句柄有可能不是泄露，需要具體分析，但是本次示例程序太簡單，所以剛好所有打開的句柄都屬於泄露的。
6）我們使用lsa 傳遞指定位置對應的代碼，lsa handlew2!fun4+0x0000002e 到這裏，我們就找到了泄露句柄的函數。
參考：
http://hi.baidu.com/firefly_only/blog/item/76f50e22945b9b5b9922ed6c.html
ok. 修復之.
現在句柄泄漏的問題搞定了, 但是進程還是跑一會就退出了!!!
後來發現進程存在 棧溢出. 通過cdb(windbg的兄弟)很快也搞定了, 仍然是easyusb.dll問題. 如果僅查看異常時的調用堆棧, 會以爲是classifying.dll的問題呢. 關於解決堆棧溢出的問題, 另有一片日誌有記錄.
最後發現是底層驅動的問題． ok, 這個話題扯遠了, 非我輩能玩的起的了, 交給他們處理了.