2017年3月16日 星期四

Bug Check: STATUS_HEAP_CORRUPTION

前言:
同事最近遇到了服務程式莫名其妙停止的問題,通常服務程式(Service)會異常停止,不外乎程式異常或是記憶體操作異常所導致的程式崩潰,但這種timing問題其實是很難靠log去追蹤的(如果幾個月才發生一次,log的累積量其實不難想像的龐大)。好在系統還是有辦法記錄這類的程式崩潰,並且隨後再透過Windbg來分析問題的狀況。

工具:
首先,你會需要知道系統產生dump的位置在哪裡。通常我會直接開軟體(AppCrashView)來看,順便初步看一下問題發生的原因。

再來就是找出dump的所在地。


分析:
這是一個HEAP崩壞問題,發生核心要做HeapFree的時候。

可能是heap manager偵測到heap區塊被多次釋放所導致(heap_failure_block_not_busy)。下面是問題heap block的詳細情形,值得注意的是Entry的位址為block的起始位址也是heap block header的位址,總共是16bytes,然後User就是資料所在的位置,也是動態記憶體配置後,程式設計者實際存取操作的地方。Size就是整個區塊的大小。然後Unused特別解釋一下,當設計者配置一個byte的記憶體大小(char*a = malloc(1))時,系統實際上會配置16bytes倍數的區塊,所以如果你對a[15]操作的時候,是不會有問題的,但如果對a[16]操作可能就會發生heap overrun的問題,而這個a[1]-a[15]的區間就是所謂的Unused區,而heap header也包含在這裡,因為這是不可動的。而這裡的0x10bytes 指的就是header的大小(16bytes)。再來,透過下一個block的位址,我們也可以查詢記憶體的操作有沒有溢位(overflow)。

參考:
最後是參考的網址