今天QA發現在他一臺機器上啟動我們的軟件的時會提示某個DLL(a.dll)找不到(a.dll是b.dll內部用到的一個DLL, 我們軟件直接用的是b.dll)。 

    剛開始我們懷疑是不是a.dll沒有下載下來或是沒有下載完整，但是到安裝目錄下看了，a.dll在那邊，用dependency看了下，DLL的導出函數也都是正常的。既然DLL本身沒有問題，那就是搜索路徑的問題了，可以修改的搜索路徑一般包括當前路徑(current directory)和DLL路徑(dll directory), 正好我們這2項在我們的Trace中都有記錄。通過查看Trace，發現dll directory在后面確實被修改成了我們另外一個軟件的路徑。

    那么究竟是誰改了這個路徑? 這就需要借助Windbg了。我們知道修改DLL路徑的API是SetDllDirectory，所以我們可以通過設置API斷點，然后查看堆棧就可以了。因為我們這個程序這里是由其他程序調用啟動的，所以我們可以通過子進程的方式來調試。

    在QA的機器上安裝windbg, 首先將Windbg Attach到父進程，輸入命令 .childdbg 1, 表示允許調試子進程，然后F5,繼續運行。接下來觸發父進程創建子進程的動作，我們可以看到Windbg會中斷下來， 我們可以通過命令|. 查看是不是我們的目標進程建立起來了，接下來輸入斷點命令bp Kernel32!SetDllDirectoryA 和 bp Kernel32!SetDllDirectoryW, 然后F5運行。果然很快Windbg又被中斷下來了，通過命令kv查看堆棧，我們可以看到果然有人調用SetDllDirectoryA，原來是我們的底層通訊模塊觸發的， 另外我們可以通過da poi(esp+4)查看SetDllDirectory傳入路徑的值。

     那么是不是只要我們把DLL路徑改回原來的NULL，就不會有這個Bug了呢？我們可以在調用SetDllDirectory中斷時，直接輸入ed esp+4 0修改傳入參數成0，然后F5運行，果然后面dll的加載就都正常了。

    找到原因后，接下來就是讓QA給對應的模塊開發人員報Bug，讓他們把DLL路徑用完后改回來。
    
    可以看到無論對于開發還是測試人員，windbg很多時候可以幫我們快速的定位問題， 如果借助符號文件，Windbg完全可以實現比VC IDE更強大的調試供功能， 并且有時候我們不需要源代碼，不需要重新編譯，直接就可以通過windbg調試和解決問題。