看雪論壇作者id：comor
注意：如果你要找的是微軟符號伺服器，不用往下看了……
當發生應用異常崩潰、驅動藍屏時，無論是測試環境，還是生產環境，分析dump檔案通常是快速定位問題的乙個最佳選擇(前提是生成了dump檔案)。特別是在生產環境時，既沒有原始碼又沒有偵錯程式，這時只有將日誌檔案、dump檔案拷貝回慢慢分析了。
一般常規分析步驟：使用windbg開啟dump檔案，設定符號路徑、原始碼路徑，輸入!analyze -v，完事！
注：必須使用與產生dump檔案的exe相對應的pdb檔案(同時生成)才能進行分析！
但是，重點的兩個要素往往不能快速準備完成：原始碼檔案和符號檔案。特別是，當交付的應用或者驅動已經過去了好幾個版本迭代，怎麼辦？常規做法：從svn或者git中checkout當初的原始碼和符號檔案版本，繼續常規分析(你最好儲存了符號檔案)。
當崩潰次數不是很經常時，常規做法並不是很麻煩。但是，當你維護的應用或者驅動很多，手邊活兒又很多時，這樣一邊檢視版本，一邊扒拉原始碼，既耗時，又勞心。特別當你忘了備份pdb檔案時，撓頭去吧……
0x00. 常規分析示例
**見附件。開啟dump檔案，直接!analyze -v：
並不知道是出錯在**。配置pdb路徑後，再次!analyze -v：
這裡需要注意，如果是在原開發機器上分析，如果之前的原始碼還在原路徑，即使沒有配置原始碼路徑，也會和有原始碼的情況一樣。此時，如果原始碼版本不對應，可能會顯示錯誤的**行。配置原始碼路徑後，再次!analyze -v：
0x01. 原理為什麼有了pdb和原始碼便可以分析dump呢？不用說，dump檔案中肯定有一些與pdb檔案的資訊，而pdb檔案中儲存了一些資訊用於分析dump的資料，從上面分析過程可以看出，除了一些用於分析的資料外，肯定還包括原始碼路徑、行數等資訊。
首先看dump檔案資訊，使用文字工具開啟，搜尋.pdb，可以找到：
「在某些情況下，pdb就是你的原始碼」。這裡說一種情況，當你拷貝回了dump檔案，也備份了pdb，但是忘了pdb和發
布版本的對應關係了(沒有放一起，例如，為了防止萬一不小心發布應用的時候，把pdb也一併打包出去了，而將原始碼和pdb分開儲存)。
怎麼辦？——pdb和exe也有對應關係，找到了對應的exe，對應的原始碼版本也就知道了(如果把發布的版本和對應的原始碼對應也搞混了……猜吧)。
在exe中也有乙個guid，使用dumpbin工具可以檢視，這個guid便是和pdb檔案的guid對應的，如果不對應，說明兩者並不是同時生成的：
而pdb檔案中的guid可以使用pdb inspector檢視，如圖中所示，它們的對應關係即：guid+age。
發布版本眾多，每次dump對應的pdb，pdb對應的原始碼均要手動查詢對應；
隨時隨地方便地分析dump。
參考**
pdb檔案解析：
看雪id：comor
推薦文章++++
* linux kernel pwn_0_kernel rop與驅動除錯
* 使用frida分析動態註冊jni函式繫結流程
* onefuzz踩坑教程
* 最右sign-v2簽名演算法追蹤及逆向還原
官方微博：看雪安全
商務合作：[email protected]求分享
求點贊
求在看
命令執行順序
在執行某個命令的時候，有時需要依賴於前乙個命令是否執行成功。例如，假設你希望將乙個目錄中的檔案全部拷貝到另外乙個目錄中後，然後刪除源目錄中的全部檔案。在刪除之前，你希望能夠確信拷貝成功，否則就有可能丟失所有的檔案。如果希望在成功地執行乙個命令之後再執行另乙個命令，或者在乙個命令失敗後再執行另乙個命令...
命令執行順序
1.使用 使用 的一般形式為 命令1 命令2 這個命令需要命令1返回為真才能執行命令2。即要命令1執行成功才能夠執行命令2。如果這個命令執行成功 那麼執行這個命令 例 cp test1 test2 if you seeing this then cp was ok 2.使用 使用 的一般形式為 命令...
Unix命令執行順序
使用 使用 用 和 將命令結合在一起 格式 命令1 命令2 說明 用來將多個命令結合在一起,依次執行,其中 表示相應的命令將在子shell而不是當前shell中作為乙個整體被執行,只有在 中所有命令的輸出作為乙個整體被重定向時,其中的命令才被放到子shell中執行,否則在當前shell執行 例子 m...