2. 程式人生 > >windbg的使用四（Windbg檢查死鎖 ）

windbg的使用四（Windbg檢查死鎖 ）

阿新 • • 發佈：2019-01-24

先上個程式碼，自己隨手寫的：

[cpp] view plaincopyprint?
  1. #include  
  2. CRITICAL_SECTION cs1;  
  3. CRITICAL_SECTION cs2;  
  4. DWORD __stdcall thread1(LPVOID lp)  
  5. {  
  6.     EnterCriticalSection(&cs1);  
  7.     Sleep(10);  
  8.     EnterCriticalSection(&cs2);  
  9. return 0;  
  10. }  
  11. DWORD  __stdcall thread2(LPVOID lp)  
  12. {  
  13.     EnterCriticalSection(&cs2);  
  14.     Sleep(10);  
  15.     EnterCriticalSection(&cs1);  
  16. return 0;  
  17. }  
  18. int main()  
  19. {  
  20.     InitializeCriticalSection(&cs1);  
  21.     InitializeCriticalSection(&cs2);  
  22.     CreateThread(NULL, 0, thread1, 0, 0, NULL);  
  23.     CreateThread(NULL, 0, thread2, 0, 0, NULL);  
  24.     system("pause");  
  25. return 0;  
  26. }  


執行，生成release版本，去掉pdb，執行，程式停住了，windbg載入到程序，

先用~*kb檢視下所有的執行緒堆疊:

0:003> ~*kb
   0  Id: 1a98.24c Suspend: 1 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr  Args to Child             0012fddc 7c92df5a 7c8025db 00000044 00000000 ntdll!KiFastSystemCallRet 0012fde0 7c8025db 00000044 00000000 00000000 ntdll!NtWaitForSingleObject+0xc 0012fe44 7c802542 00000044 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8 0012fe58 7854bd40 00000044 ffffffff 00000000 kernel32!WaitForSingleObject+0x12 0012fedc 7854c702 00000000 00392b98 00392de0 MSVCR90!_dospawn+0x1d1 [f:\dd\vctools\crt_bld\self_x86\crt\src\dospawn.c @ 215] 0012ff00 7854c84b 00000000 00392b98 0012ff5c MSVCR90!comexecmd+0x60 [f:\dd\vctools\crt_bld\self_x86\crt\src\spawnve.c @ 137] 0012ff38 7854cc71 00000000 00392b98 0012ff5c MSVCR90!_spawnve+0x12a [f:\dd\vctools\crt_bld\self_x86\crt\src\spawnve.c @ 273] 0012ff70 004010a8 004020f4 00000001 00401218 MSVCR90!system+0x8e [f:\dd\vctools\crt_bld\self_x86\crt\src\system.c @ 87] WARNING: Stack unwind information not available. Following frames may be wrong. 0012ffc0 7c817077 00300031 0032002d 7ffdc000 test2+0x10a8 0012fff0 00000000 00401360 00000000 78746341 kernel32!BaseProcessStart+0x23
   1  Id: 1a98.1588 Suspend: 1 Teb: 7ffde000 Unfrozen ChildEBP RetAddr  Args to Child             0050ff14 7c92df5a 7c939b23 0000002c 00000000 ntdll!KiFastSystemCallRet 0050ff18 7c939b23 0000002c 00000000 00000000 ntdll!NtWaitForSingleObject+0xc 0050ffa0 7c921046 00403370 0040101d 00403370 ntdll!RtlpWaitForCriticalSection+0x132 0050ffa8 0040101d 00403370 000203a8 7c80b729 ntdll!RtlEnterCriticalSection+0x46 WARNING: Stack unwind information not available. Following frames may be wrong. 0050ffec 00000000 00401000 00000000 00000000 test2+0x101d
   2  Id: 1a98.185c Suspend: 1 Teb: 7ffdd000 Unfrozen ChildEBP RetAddr  Args to Child             0060ff14 7c92df5a 7c939b23 00000034 00000000 ntdll!KiFastSystemCallRet 0060ff18 7c939b23 00000034 00000000 00000000 ntdll!NtWaitForSingleObject+0xc 0060ffa0 7c921046 00403388 0040104d 00403388 ntdll!RtlpWaitForCriticalSection+0x132 0060ffa8 0040104d 00403388 000203a8 7c80b729 ntdll!RtlEnterCriticalSection+0x46 WARNING: Stack unwind information not available. Following frames may be wrong. 0060ffec 00000000 00401030 00000000 00000000 test2+0x104d
#  3  Id: 1a98.159c Suspend: 1 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr  Args to Child             003dffc8 7c972119 00000005 00000004 00000001 ntdll!DbgBreakPoint 003dfff4 00000000 00000000 00000000 00000000 ntdll!DbgUiRemoteBreakin+0x2d
[cpp] view plaincopyprint?
  1. 我們注意到1號執行緒的執行緒堆疊是從ntdll!RtlEnterCriticalSection中開始的，那麼ntdll!RtlEnterCriticalSection又是什麼函式的入口呢，首先猜到的是EnterCriticalSection,這個函式是kernel32.dll中的，為了驗證猜測，我們用dump檢視到kernel32.dll的匯出函式：  

果然如此，

1. !cs

!cs 擴展顯示一個或多個臨界區(critical section)或者整個臨界區樹

前面說的ntdll!RtlEnterCriticalSection的第一個引數是臨界區的地址，事實上用uf反彙編它，可以看到是ret 4，說明就只有一個引數

那麼，

!cs Address 指定要顯示的臨界區地址。如果省略該引數，偵錯程式顯示當前程序中所有臨界區。
[cpp] view plaincopyprint?
  1. 0:003> ~1kb  
  2. ChildEBP RetAddr  Args to Child                
  3. 0050ff14 7c92df5a 7c939b23 0000002c 00000000 ntdll!KiFastSystemCallRet  
  4. 0050ff18 7c939b23 0000002c 00000000 00000000 ntdll!NtWaitForSingleObject+0xc  
  5. 0050ffa0 7c921046 00403370 0040101d 00403370 ntdll!RtlpWaitForCriticalSection+0x132  
  6. 0050ffa8 0040101d 00403370 000203a8 7c80b729 ntdll!RtlEnterCriticalSection+0x46  
  7. WARNING: Stack unwind information not available. Following frames may be wrong.  
  8. 0050ffec 00000000 00401000 00000000 00000000 test2+0x101d  
  9. 0:003> !cs 00403370   
  10. -----------------------------------------  
  11. Critical section   = 0x00403370 (test2+0x3370)  
  12. DebugInfo          = 0x7c99e9e0  
  13. LOCKED  
  14. LockCount          = 0x1  
  15. OwningThread       = 0x0000185c  
  16. RecursionCount     = 0x1  
  17. LockSemaphore      = 0x2C  
  18. SpinCount          = 0x00000000  
[cpp] view plaincopyprint? [cpp] view plaincopyprint?
  1. 這裡LockCount為1意思為除了一個執行緒擁有它外，另外還有一個執行緒在等待它，它是由EnterCriticalSection增加，LeaveCriticalSection來減小的,比如我再加一點程式碼:  
[cpp] view plaincopyprint?
  1. DWORD  __stdcall thread3(LPVOID lp)  
  2. {  
  3.     EnterCriticalSection(&cs2);  
  4.     Sleep(10);  
  5.     EnterCriticalSection(&cs1);  
  6. return 0;  
  7. }  
  8. int main()  
  9. {  
  10.     InitializeCriticalSection(&cs1);  
  11.     InitializeCriticalSection(&cs2);  
  12.     CreateThread(NULL, 0, thread1, 0, 0, NULL);  
  13.     CreateThread(NULL, 0, thread2, 0, 0, NULL);  
  14.     CreateThread(NULL, 0, thread3, 0, 0, NULL);  
  15.     system("pause");  
  16. return 0;  
  17. }  

這時執行windbg：

[cpp] view plaincopyprint?
  1. 0:004> ~1kb  
  2. ChildEBP RetAddr  Args to Child                
  3. 0051fe48 7c92df5a 7c939b23 00000034 00000000 ntdll!KiFastSystemCallRet  
  4. 0051fe4c 7c939b23 00000034 00000000 00000000 ntdll!NtWaitForSingleObject+0xc  
  5. 0051fed4 7c921046 00417140 00411420 00417140 ntdll!RtlpWaitForCriticalSection+0x132  
  6. *** WARNING: Unable to verify checksum for D:\Project1\test2\Debug\test2.exe  
  7. 0051fedc 00411420 00417140 00000000 00000000 ntdll!RtlEnterCriticalSection+0x46  
  8. 0051ffb4 7c80b729 00000000 00000000 00000000 test2!thread1+0x50 [d:\project1\test2\test2\test2.cpp @ 10]  
  9. 0051ffec 00000000 00411122 00000000 00000000 kernel32!BaseThreadStart+0x37  
  10. 0:004> !cs 00417140  
  11. -----------------------------------------  
  12. Critical section   = 0x00417140 (test2!cs2+0x0)  
  13. DebugInfo          = 0x7c99ea00  
  14. LOCKED  
  15. LockCount          = 0x2  
  16. OwningThread       = 0x00001f60  
  17. RecursionCount     = 0x1  
  18. LockSemaphore      = 0x34  
  19. SpinCount          = 0x00000000  

可以發現LockCount變成了2，如果臨界區是有訊號的，則顯示NOT LOCKED(值為-1)

OwningThread表示擁有這個臨界區的執行緒ID,RecursionCount表示擁有執行緒調了幾次EnterCriticalSection，這其實也影響到了LockCount,如果擁有執行緒多呼叫一次EnterCriticalSection,那麼 LockCount也會相應加1，因為LockCount標識了任意執行緒呼叫EnterCriticalSection請求這個互斥量的次數減1,(所以0-1=-1為NOT LOCKED)當然，前面如果呼叫了LeaveCriticalSection,那麼 LockCount也會相應減1

我們繼續看原有的程式：

~~[TID]執行緒 ID 為 TID 的執行緒。（中括號是必需的，而且在第二個~和左括號間不能有空格）

[cpp] view plaincopyprint?
  1. 0:003> ~~[0x0000185c]  
  2.    2  Id: 1a98.185c Suspend: 1 Teb: 7ffdd000 Unfrozen  
  3.       Start: test2+0x1030 (00401030)   
  4.       Priority: 0  Priority class: 32  Affinity: f  

 這意思就是1號執行緒等待的臨界區擁有者是2號執行緒，那麼同樣我們對2號執行緒進行分析:

[cpp] view plaincopyprint?
  1. 0:003> ~2kb  
  2. ChildEBP RetAddr  Args to Child                
  3. 0060ff14 7c92df5a 7c939b23 00000034 00000000 ntdll!KiFastSystemCallRet  
  4. 0060ff18 7c939b23 00000034 00000000 00000000 ntdll!NtWaitForSingleObject+0xc  
  5. 0060ffa0 7c921046 00403388 0040104d 00403388 ntdll!RtlpWaitForCriticalSection+0x132  
  6. 0060ffa8 0040104d 00403388 000203a8 7c80b729 ntdll!RtlEnterCriticalSection+0x46  
  7. WARNING: Stack unwind information not available. Following frames may be wrong.  
  8. 0060ffec 00000000 00401030 00000000 00000000 test2+0x104d  
  9. 0:003> !cs 00403388   
  10. -----------------------------------------  
  11. Critical section   = 0x00403388 (test2+0x3388)  
  12. DebugInfo          = 0x7c99e9c0  
  13. LOCKED  
  14. LockCount          = 0x1  
  15. OwningThread       = 0x00001588  
  16. RecursionCount     = 0x1  
  17. LockSemaphore      = 0x34  
  18. SpinCount          = 0x00000000  
  19. 0:003> ~~[0x00001588]  
  20.    1  Id: 1a98.1588 Suspend: 1 Teb: 7ffde000 Unfrozen  
  21.       Start: test2+0x1000 (00401000)   
  22.       Priority: 0  Priority class: 32  Affinity: f  

原來2號執行緒等待的臨界區擁有者是1號執行緒，所以經典的死鎖現象出現了！！！！！！！！！！！！！！！！！！！！！！！！

下面繼續介紹下!cs的擴充套件:

!cs -s 如果可能的話，顯示每個臨界區的初始堆疊回溯。
!cs -l 僅顯示鎖定的臨界區。
[cpp] view plaincopyprint?
  1. 0:003> !cs -l   
  2. -----------------------------------------  
  3. DebugInfo          = 0x7c99e9c0  
  4. Critical section   = 0x00403388 (test2+0x3388)  
  5. LOCKED  
  6. LockCount          = 0x1  
  7. OwningThread       = 0x00001588  
  8. RecursionCount     = 0x1  
  9. LockSemaphore      = 0x34  
  10. SpinCount          = 0x00000000  
  11. -----------------------------------------  
  12. DebugInfo          = 0x7c99e9e0  
  13. Critical section   = 0x00403370 (test2+0x3370)  
  14. LOCKED  
  15. LockCount          = 0x1  
  16. OwningThread       = 0x0000185c  
  17. RecursionCount     = 0x1  
  18. LockSemaphore      = 0x2C  
  19. SpinCount          = 0x00000000  


!cs starAddress EndAddress指定要搜尋臨界區的地址範圍

[cpp] view plaincopyprint?
  1. 0:003> !cs 0x00400000 0x00500000  
  2. -----------------------------------------  
  3. DebugInfo          = 0x7c99e9c0  
  4. Critical section   = 0x00403388 (test2+0x3388)  
  5. LOCKED  
  6. LockCount          = 0x1  
  7. OwningThread       = 0x00001588  
  8. RecursionCount     = 0x1  
  9. LockSemaphore      = 0x34  
  10. SpinCount          = 0x00000000  
  11. -----------------------------------------  
  12. DebugInfo          = 0x7c99e9e0  
  13. Critical section   = 0x00403370 (test2+0x3370)  
  14. LOCKED  
  15. LockCount          = 0x1  
  16. OwningThread       = 0x0000185c  
  17. RecursionCount     = 0x1  
  18. LockSemaphore      = 0x2C  
  19. SpinCount          = 0x00000000  
!cs -o 對所有顯示出來的已鎖定的臨界區，顯示所有者的堆疊。
!cs -?顯示該命令的幫助文字。
[cpp] view plaincopyprint?
  1. 0:003> !cs -?  
  2. !cs [-s] [-l] [-o]                   - dump all the active critical sections in the current process.  
  3. !cs [-s] [-o] address                - dump critical section at this address.  
  4. !cs [-s] [-l] [-o] address1 address2 - dump all the active critical sections in this range.  
  5. !cs [-s] [-o] -d address             - dump critical section corresponding to DebugInfo at this address.  
  6. "-s" will dump the critical section initialization stack trace if it is available.  
  7. "-l" will dump only the locked critical sections.  
  8. "-o" will dump the critical section owner's stack.  

相關推薦

windbg的使用四（Windbg檢查死鎖 ）

先上個程式碼，自己隨手寫的： [cpp] view plaincopyprint? #include   CRITICAL_SECTION cs1;   CRITICAL_SECTION cs2;   DWORD __stdcall thread1(LPVOID lp)   {       Ente

java單例模式（雙重檢查加鎖）的原因

csharp sta get 第一次 instance new 同步機制 原因 AR public class Singleton{ private static Singleton instance = null;//是否是final的不重要，因為最多只可能實

併發控制四（活鎖和死鎖）

和作業系統一樣，封鎖的方法可能引起活鎖和死鎖等問題。 活鎖 如果事務T1封鎖了資料R，事務T2又請求封鎖R，於是T2等待；T3也請求封鎖R，當T1釋放了R上的封鎖之後系統首先批准了T3的請求，T2仍然等待；然後T4又請求封鎖R，當T3釋放了R之後系統又批准了T4的請求，T2

Deadlock found when trying to get lock（死鎖）問題解決

今天壓測使用者中心的登入介面。發現這個介面在併發下幾乎不可用，錯誤率70%。 檢視後臺日誌全是： 登入接口出現死鎖了。 看了下程式碼，登入中做了更新使用者登入時間，插入使用者log。查詢資料庫，發行使用者更新和插入log都會lock wait 判斷可能是在壓測同一個使

死鎖面試題（什麼是死鎖，產生死鎖的原因及必要條件）

什麼是死鎖？ 所謂死鎖，是指多個程序在執行過程中因爭奪資源而造成的一種僵局，當程序處於這種僵持狀態時，若無外力作用，它們都將無法再向前推進。 產生死鎖的原因？ 可歸結為如下兩點： a. 競爭資源 系統中的資源可以分為兩類： 1.

python 建立子程序subprocess以及注意的問題（死鎖）

原文 ： http://blog.csdn.net/jgood/article/details/4498166 最近，我們老大要我寫一個守護者程式，對伺服器程序進行守護。如果伺服器不幸掛掉了，守護者能即時的重啟應用程式。上網Google了一下，發現Python有很幾個模

作業系統：銀行家演算法（避免死鎖）

演算法介紹： 程式實現： /***************************************************** 程式：銀行家演算法實現 作者：小單 時間: 2013年11月5日 ***********************

《計算機作業系統》總結五（死鎖）

例如，對一條編譯的語句，該程序可以建立一個子程序執行編譯程式對使用者源程式進行編譯。類似地，子程序也可以繼續建立子程序去完成指定的功能。因此，一個作業就動態地轉換成了一組執行實體——程序族。當父程序遇到作業說明書中的“撤出作業”的語句時，將該作業從執行狀態改變為完成狀態，將作業及相關結果送入磁碟上的輸出井。作

WinDbg -- 除錯互斥體(Mutex)死鎖

一. 演示用例 #include <windows.h> #include <tchar.h> #include <process.h> HANDLE hMutexA = NULL; HANDLE hMutexB =

一個詭異BUG引發的血案（執行緒死鎖造成的CPU利用率逐漸增高）

        我首先宣告，我有一些標題黨的嫌疑，確實沒有什麼血案發生，頂多是我找BUG 時由於太用力把嘴脣給咬破了。         這個故事發生在剛剛過去的猴年春節前夕，公司準備上傳最後一個包到appstore,然後大家各回各家各找各媽。大家憧憬著即將到來的假期寫著程

java 自旋鎖（可重入且無死鎖）

java自旋鎖 的實現原理：如果自旋鎖被另外一個執行緒物件持有，那麼當前獲取鎖的執行緒將陷入while迴圈等待，直到那個持有自旋鎖的執行緒物件釋放它所持有的自旋鎖，那麼那些想要獲取該自旋鎖的執行緒物件 將會有一個獲得該自旋鎖。   基於他這種原理，等待的時候，並不釋放cpu

課堂測試四（文件讀寫）

upd select tag art main cor color -s ioe 學生信息管理系統 （本程序以文本方式存儲數據，不通過數組，直接對文件進行操作） 學生類 Student.java 1 public class Student { 2 priva

python函數四（裝飾器進階）

開放 int col wrap 運行 lag 分享 none name 一。開放封閉原則 　　1.對擴展是開放的 　　　　任何一個程序，不可能在設計之初就已經想好了所有的功能並且未來不做任何更新和修改。所以我們必須允許代碼擴展、添加新功能。 　　2.對修改是封閉的 　　　　

Maven學習筆記四（坐標和依賴）

Maven學習筆記 坐標 什麽是坐標？ 在平面幾何中坐標（x,y）可以標識平面中唯一的一點 Maven 坐標主要組成 groupId：定義當前 Maven 項目隸屬項目、組織 artifactId：定義實際項目中的一個模塊 version：定義當前項目的當前版本

JMS學習四（ActiveMQ消息過濾）

eat exp receiver 同步 默認 on() prop nal runt 消息的過期、消息的選擇器和消息的優先級。 一、消息的過期 允許消息過期 。默認情況下，消息永不會過期。如果消息在特定周期內失去意義，那麽可以設置過期時間。 有兩種方法設置消息的過期時間，時間

java 併發（執行緒&鎖）

java 併發（執行緒&鎖） ##執行緒 ###執行緒概念 作業系統排程的最小單元是執行緒，也叫輕量級程序（LightWeight Process），在一個程序裡可以建立多個執行緒，這些執行緒都擁有各自的計數器、堆疊和區域性變數等屬性，並且能夠訪問共享的記憶體變數。處

spring學習總結——裝配Bean學習四（匯入和混合配置）

情景：在典型的Spring應用中，我們可能會同時使用自動化和顯式配置（JavaConfig）或者XML配置，幸好在Spring中，這些配置方案都不是互斥的。你儘可以將JavaConfig的元件掃描和自動裝配和/或XML配置混合在一起。 　　關於混合配置，第一件需要了解的事情就是在自動裝配時，它並不在意要裝配

MySQL資料庫基礎知識四（外來鍵和引用）

級聯刪除，級聯更新 外來鍵維護資料的一致性。 下面是幾條術語： 父表：包含原始鍵值的表。 子表：引用了父表中鍵值的相關表。 建立父表和子表關聯案例 父表： create table parent { par_id INT NOT NULL, PRIMAR

LAMP架構十四（ Apache配置訪問控制）

十四、apache 訪問控制 在Apache2.2版本中，訪問控制是基於客戶端的主機名、IP地址以及客戶端請求中的其他特徵，使用Order(排序), Allow(允許), Deny(拒絕),Satisfy(滿足)指令來實現。 在Apache2.4版本中，使用mod_authz_host這

Spring原始碼解析之四（容器的功能擴充套件）

容器的功能擴充套件 1、概述 之前的文章中BeanFactory介面以及它的預設實現類XmlBeanFactory為例進行分析，但是Spring中還提供了另一個介面ApplicationContext，用於擴充套件BeanFactory中現有的功能。  ApplicationCon