Windbg除錯互斥體 Mutex 死鎖

#include #include #include handle hmutexa = null;

handle hmutexb = null;
unsigned __stdcall threadproc1(void * parg) 
unsigned __stdcall threadproc2(void * parg) 
int main()
if (hthread2) 
// 關閉控制代碼
if(hmutexa)
closehandle(hmutexa);
if(hmutexb)
closehandle(hmutexb);
return 0;
}

觀察執行緒執行**可知，這是乙個典型的死鎖用例，2個執行緒相互等待。

執行緒1：擁有mutexa --> 過一段時間(sleep) ---> 想擁有mutexb

執行緒2：擁有mutexb --> 過一段時間(sleep) ---> 想擁有mutexa

執行緒1想擁有屬於執行緒2的mutexb，而執行緒2卻想擁有屬於執行緒1的mutexa，互不鬆手，就只能都等著了。

~*kvn檢視所有執行緒呼叫堆疊：

從執行緒#1棧幀03可以看到其正在等待控制代碼00000038。

從執行緒#2棧幀03可以看到其正在等待控制代碼00000034。

即：執行緒#1（id：22f4）--->等待控制代碼38

執行緒#2（id：33bc）---> 等待控制代碼34

到底控制代碼00000034和00000038是什麼型別的，可以使用!handle命令檢視：

從圖中可以看到：

控制代碼00000034為名為mutexa的互斥體，被執行緒id：2264 擁有。

控制代碼00000038為名為mutexb的互斥體，被執行緒id：33bc 擁有。

即：執行緒#1（id：22f4）等待00000038（互斥體mutexa ），擁有00000034（互斥體mutexb)

執行緒#2（id：33bc）等待控制代碼00000034（互斥體mutexb ），擁有00000038（互斥體mutexa)

所以，愛就是放手，有時候放手會讓彼此過得更好。

WinDbg 除錯互斥體 Mutex 死鎖

include include include handle hmutexa null handle hmutexb null unsigned stdcall threadproc1 void parg unsigned stdcall threadproc2 void parg int main...

Windbg除錯異常

用windbg分析包含異常資訊的dump檔案時，往往當前棧幀已不正確，可通過如下步驟找回 1 teb，找到stackbase和stacklimit 2 通過.cxr命令將異常上下文恢復到相關暫存器 如何找到異常上下文的位址呢？方法一 dds dps dqs stacklimit stackbase ...

windbg除錯技巧

1 64位機器上執行32位程式得到的dump，需要先進行轉換 load wow64exts sw2 載入符號表 系統符號表 srv d mylocalsymbols 吵雜模式符號匹配 有時候 沒大改，但重編了導致之前的pdb沒有了 符號載入，吵雜模式 強制匹配符號 symopt 0x40 sym n...