把長期運轉後的當機追查到控制代碼洩漏的案例

案例概要

這是一個針對只在連續運轉約 1 個月後才會突然當機的 Windows 應用程式，從整理觀測點開始，最終收斂到以控制代碼洩漏為中心的調查的案例。 重點不只在原因本身，而在於決定了該先把哪些觀測整理好。

症狀

• 數天內不會出現，只在長期運轉後才當機
• 只從例外的出現方式，難以判斷是否為洩漏
• 只在現場發生，開發機上需要壓縮重現條件

限制

• 以月為單位等待重現並不實際
• 因為包含相機重新連線與異常路徑，只靠正常情境的日誌並不夠
• 必須能持續觀測哪一種資源在增加

觀測了什麼

• Handle Count、Private Bytes、Thread Count 的 heartbeat
• 工作階段開始、重新連線、結束的邊界日誌
• create/open/register 與 close/dispose/unregister 成對的生命週期日誌

如何釐清問題

首先不直接追「長期運轉當機」本身，而是把重現壓縮到重新連線與 timeout 相關的失敗路徑。 結果判斷出比起記憶體洩漏，懷疑控制代碼洩漏更合理，因而能把觀測集中到那裡。

如何改善

• 增加監視項目，讓人不只能看當機的當下，也能追蹤增加的趨勢
• 整理邊界日誌，讓人更容易追查是哪個職責開啟、哪個職責關閉
• 將調查結果整理成容易銜接到後續異常情境測試基礎的形式

本案例連結的服務

本案例同時連結到釐清只在長期運轉後才出現的故障的故障調查・根本原因分析，以及從實作端整理日誌、重新連線、運作觀測的 Windows 應用程式開發。

相關文章

聯絡我們

如果您遇到的課題與本頁內容相近，歡迎附上目前狀況與所需支援的形式與我們聯絡。