在windbg中分析崩潰轉儲

我正在使用第三方封閉源代碼API，它引發一個異常，指出「所有命名管道都很忙」。在windbg中分析崩潰轉儲

我想進一步調試（而不是僅僅通過），所以我實際上可以瞭解封面下發生了什麼。

我已使用WinDbg轉儲了此過程。我現在應該使用哪些命令來分析此轉儲？

感謝

2009-10-30 csharpdev

它是託管還是本機？你能拋出更多的細節嗎？ – Naveen 2009-10-30 13:58:27

這當客戶端調用的CreateFile對現有管道和所有現有的管道實例都忙普遍發生。此時CreateFile返回一個錯誤，錯誤代碼是ERROR_PIPE_BUSY。此時正確的方法是使用超時值調用WaitNamedPipe以等待管道實例變爲可用。

當多個客戶端嘗試同時連接到命名管道時，通常會發生此問題。

來源

2009-10-31 18:23:21 steve

我認爲第三方DLL是本地（否則，只用反射鏡）

使用的WinDbg分析轉儲之前，請嘗試使用進程監視器（Sysinternals的，免費軟件）來監控你的流程的活動。如果由於文件系統相關問題而導致失敗，您可以準確查看是什麼導致了問題，以及在發生故障前究竟發生了什麼。

如果Process-Monitor不夠，那麼您可以嘗試並調試您的過程。但爲了查看關於第三方DLL的一些有意義的信息，您將需要它是pdb的。

設置正確的調試符號後，您可以使用k命令或其中一個變體（我假設您正在談論本機代碼）查看調用堆棧。如果你的進程確實因爲這個DLL而崩潰，而不是檢查你傳遞給它的函數的參數，以確保問題不在你身邊。我猜想進一步調用堆棧，你會到達一些Win32 API--檢查dll函數傳遞的參數，試圖看看是否有「異味」。如果你有dll的私有符號，你可以檢查它的函數的局部變量（dv），它可以給你更多的信息。

我希望我給你一個很好的起點。

來源

2009-11-06 18:35:39

這對於使用WinDbg的分析死機，可能是一些使用的一個很好的資源：http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html

文章是Windows 10，但它包含指向Windows的早期版本的類似信息。

來源

2009-11-06 18:43:39 boot13

鏈接已損壞。 – UserControl 2017-03-29 17:08:52

@UserControl：謝謝指出。我已經更新了答案。 – boot13 2017-04-01 02:37:56

在使用Windbg進行事後調試時，在決定深入挖掘之前運行一些常規診斷命令會很有用。這些應該是你的第一個步驟：

.logopen <filename> (See also .logappend) 
.lastevent    See why the process halted and on what thread 
u      List disassembly near $eip on offending thread 
~      Status of all threads 
Kb      List callstack, including parameters 
.logclose

這些命令通常會給你發生了什麼事，所以你可以進一步深入研究的概述。在處理沒有源代碼的庫的情況下，將生成的日誌文件與二進制庫的構建號一起發送給供應商應該足以讓它們追蹤到已知問題（如果有的話）。

來源

2009-12-03 17:37:24

你可以開始做如下得到異常的概述：

!analyze -v

現在你可以加載異常背景記錄：

.ecxr

而現在......只是來看看在堆棧，寄存器，線程，...

kb  ;will show you the stack trace of the crash. 
dv  ;local variables

根據你得到的線索，你應該遵循一個dif不尋常的方向。如果你想快速參考WinDbg，我建議你this link。

我希望你找到一些這些命令和信息有用。

來源

2009-12-04 09:57:29

在windbg中分析崩潰轉儲

回答

相關問題