預期的LdrDoDebuggerBreak（），獲得NtWaitForWorkViaWorkerFactory（）

在調試研討會期間，其中一位參與者無法遵循示例。預期的LdrDoDebuggerBreak（），獲得NtWaitForWorkViaWorkerFactory（）

在Windows 10機器上的WinDbg 10.0.15603.137下運行可執行文件時，調試器第一次在NtWaitForWorkViaWorkerFactory()處破壞，而不是在LdrDoDebuggerBreak()中的初始斷點。

當試圖用g運行可執行文件時，它表示沒有可運行的可執行文件。問題是什麼？

這裏是什麼樣子：

應用程序的源代碼很簡單：

#include "stdafx.h" 
#include <exception> 

int _tmain(int /*argc*/, _TCHAR* /*argv*/[]) 
{ 
    throw std::exception(); 
}

注：我幾乎不能提供更多的信息，因爲我沒有更多的訪問客戶的個人電腦，它不會發生在我的。

來源

2017-06-01 Thomas Weller

嗯，它並沒有真正的突破。這是一個關於已經退出的過程的謊言。我不知道發生了什麼，但我可以告訴你你應該做什麼。在創建進程時中斷，而不是在最初的斷點和step/trace/go /從那裏開始。我在這個答案中描述瞭如何做到這一點：https://stackoverflow.com/a/42046071/306930 – conio

@conio：通常，初始斷點對於我想要做的分析已經足夠了。有趣的方法。如果我有機會用你的方法分析這個問題，我可能會發現它在初始斷點之前爲什麼會終止。 –

好吧，當然。我不建議讓它成爲默認行爲。你是對的，通常你不需要它。在ibp之前的流程終止幾乎是您爲什麼需要它的教科書示例。 :) – conio

不可能肯定地說出問題是什麼，但我們可以說問題可能已經出現了什麼問題。幸運的是，這就是你問的。

我不能給這個確切的概率，但很可能是一個隱式鏈接的DLL加載失敗。這是在初始斷點之前發生的主要事情。

爲什麼DLL加載失敗？也許某種資源問題，但是 - 特別是假設您在重新啓動後嘗試運行「新鮮」機器 - 更有可能是在有問題的機器上加載了額外的DLL。也許一個AVRF DLL，也許是一個AppInit DLL，可能是將DLL注入未知和不願意進程的其他一百種方法之一。

正如我在我的評論中所說的，確定的方法是讓WinDBG在創建進程時而不是在初始斷點上進行分解，然後從那裏開始調試。

做到這一點的方法是用-xe cpr啓動NTSD/CDB，在WinDbg中的事件過濾窗口（通過調試菜單訪問）設置這個，或者使用sxe cpr並在WinDbg中.restart，假設你啓動的進程在WinDBG（而不是附加到它），這是最好的easiets和我認爲最好的，但這是一個品味問題。

我覺得TLS回調的主要模塊的初始斷點前還執行，但隨着項目配置或CRT庫添加一個問題TLS回調的機會打亂某人是什麼？（隱式鏈接的DLL的TLS回調包含在「DLL加載」中）。

但同樣，更加邪惡和聰明的技巧不那麼常見，因此不太可能。

來源

2017-06-03 21:24:46 conio

謝謝。通過這些信息，我將ModLoad事件與「正常」運行進行比較，「運行」並停在最初的斷點處。除了我的截圖之外，我還可以在模塊列表中看到'C：\ Windows \ SysWOW64 \ MSVCR110.dll'。對我來說，聽起來參與者並沒有自己編譯源代碼，而是運行了一個他沒有安裝C運行庫的可執行文件。這聽起來似乎合理嗎？ –

@ThomasWeller：這是可能的，但在這種情況下，我想我會期望[MessageBox關於缺少導入]（https://i.stack.imgur.com/85ZJM.png）。我還假設參與者使用同一臺機器來構建和運行，但也許我應該沒有。 :) – conio

好點...我會盡量弄清楚 –

預期的LdrDoDebuggerBreak（），獲得NtWaitForWorkViaWorkerFactory（）

回答

相關問題