dump分析教程

⑴ 如何分析mp文件.vs2005

前言：利用drwtsn32或NTSD進行程序崩潰處理，都可以生成可用於調試的dmp格式文件。使用VS2005打開生成的文件，能很方便的找出BUG所在位置。本文將討論以下內容：
1、 程序編譯選項
2、 利用VS2005 分析mp文件
3、 常見問題討論
一、 程序編譯選項
PDB files contains all debug information like type definition and function prototype. When application crashes, we need the PDB files to analyze the root cause, so make sure these PDB files will be created when building it. You must do the following setting:
C/C++/General/Debug Information Format=Program Database (/Zi).

圖1.1 調試信息格式
Linker/Debugging/Generate Program Database File=」Name and location of your PDB files」

圖1.2 PDB文件輸出路徑
PDB文件路徑最好設置在同一個文件夾中，這樣方便dmp文件調試時調用。
調試時，所有的PDB文件和源文件必須嚴格匹配（the PDB files should be the one generated by build the source code），並存儲在一個安全的位置。當客戶報告了一個錯誤時，你需要這些文件來幫忙以便定位錯誤於源代碼中並解決問題。
二、 VS2005 分析mp文件
In this simple application, there is an unhandled Access Violation Reading exception, because GetNameFromDatabase returns a NULL pointer, and this pointer is passed into IsPrefix and then it』s used directly without NULL pointer checking.

圖1.3 演示代碼

利用Release模式編譯該測試程序，在客戶機上運行該程序，將根據NTSD設置生成相對應的DMP格式文件。
可以使用Visual Studio.Net、NTSD或是其他的調試工具對DMP格式文件進行分析。

Start Visual Studio.Net
Click File/Open Solution and make sure the files of type is *.dmp then click Open.

圖1.3 Open Dump File (GUI)

Set Symbol Path
Click Tools/Options, Debugging/Symbols，增加PDB文件路徑。若調試的程序需要微軟基礎庫的PDB信息，可以增加一個路徑為：
http://msdl.microsoft.com/download/symbols
在界面下方Cache Symbol From symbol…選擇本地存儲這些Symbols的路徑。

圖1.4 Symbol Path
如果DMP文件沒有放入本身PDB文件所在目錄，也可以在此處增加一個本地目錄。點OK後，VS2005將從網路中下載所需要的Symbols，需要等待一段時間。如果是多次調試同一個程序錯誤所生成的DMP文件，可以在對話框中選擇「Search the above locations only when symbols are loaded manually」。從而可以節省網路帶寬。

Set Source code path
Open Solution Property Pages and set the source code path.

圖1.5 屬性菜單

圖1.6 Debug Source Files

Start to Debug the Dump File
Click the Debug menu, it will ask you to save as a solution, save it. Then it will go to the line which caused the crash of your application.

圖1.7 調試窗口，定位到源代碼

三、 常見問題討論
1、 Dump文件放在哪裡？
Dump文件不用非要放在你編譯出來的位置，你完全可以建立一個新的文件夾來放它。但若不是存放在編譯出來的位置，需要將編譯生成的PDB文件拷貝到Dump文件目錄，或是利用VS2005打開Dump文件後，設置PDB文件路徑。參照圖1.4。

2、 如何恢復當時的現場？
可能你要問，怎麼可能，這個mp文件可是用戶發給我的，我不可能去用戶家裡調試吧？這個恢復現場可不是指的非要到那台機器上去，而是要把產生mp文件對應的二進制文件拿到。
但是恢復現場需要所有的二進制文件都要對應，你一定要有導致用戶崩潰的那些Exe和DLL。既然是你發布的程序，Exe文件當然你會有。所以這里只考慮DLL就行了。
Dump文件中記錄了所有DLL文件的版本號和時間戳，所以你一定可以同過某種途徑拿到它。如果你能從用戶那裡拿到最好，如果不方便，用戶不可能用的是我們平常不常用的操作系統，所以找個有對應系統的機器一般都會有。但是記住不僅是文件名稱要一致，還要核對版本和時間戳，如果不同一樣沒有辦法用。
如果客戶用了某個特殊的補丁怎麼辦？
其實這個問題也很好解決，只要它不阻礙閱讀堆棧，就不用管它，調試Dump和運行程序不一樣，缺少一兩個DLL沒有任何問題。

3、 如果真的需要怎麼辦？
符號文件現在主要是指PDB文件。
如果沒有符號文件，那麼調試的時候可能導致堆棧錯誤。
如果你丟失了這個發布版本中你編譯出來的那些exe和DLL的PDB，那麼這個損失是嚴重的，重新編譯出來的版本是不能使用的。
我自己的DLL都有了，可是缺的是系統的DLL的對應PDB文件怎麼辦？圖1.4中已經介紹了方法。微軟在它的符號資料庫上為我們提供了所有的PDB文件，還有部分非關鍵DLL。設置好後程序將自動下載需要的PDB及DLL文件。

4、 拿到需要的文件了，這些文件應該放在哪裡？
符號資料庫中的文件不用動，把其它的exe和DLL、PDB文件放在mp文件目錄里就行了。

5、 我用的是VS2005，明明有源代碼，為什麼顯示不了？
這個是mp調試的最頭痛問題，代碼可能已經改過了，即使你從SVN拿到當時的版本，時間戳也是錯的，VS2005就是不讓你顯示代碼。其實只要在
Tools/Options，Debugging/General中去掉
Require source files to exactly match the original version的復選就行了。

⑵ 如何分析Windows的mp文件

當伺服器掛起,崩潰或者性能底下時,就需要抓取伺服器的線程堆棧(Thread Dump)用於後續的分析.
Thread mp提供了當前活動的線程的快照. 它提供了JVM中所有java線程的棧跟蹤信息
有很多方式可用於獲取Thread Dump, 一些是操作系統特定的命令.
操作系統命令獲取ThreadDump:
Windows:
1. 轉向伺服器的標准輸出窗口並按下Control + Break組合鍵, 之後需要將線程堆棧復制到文件中
UNIX/ Linux
首先查找到伺服器的進程號(process id), 然後獲取堆棧.
1. ps –ef | grep java
2. kill -3 <pid>
注意一定要謹慎, 一步不慎就可能讓伺服器進程被殺死!
JVM 自帶的工具獲取線程堆棧:
JDK自帶命令行工具獲取PID並做ThreadDump:
1. jps
2. jstack <pid>
使用JVisualVM:
Threads 標簽頁àThreadDump按鈕.
WebLogic 自帶的獲取 thread mp的工具:
1. webLogic.Admin 工具
a. 打開命令提示符, 通過運行<DOMAIN_HOME>/bin/setDomain.env設置相關類路徑
b. 執行下面的命令
java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic1 THREAD_DUMP
注意: Thread Dump 會列印到標准輸出, 如nohup日誌或者進程窗口.
2. 使用 Admin Console
a. 登錄 Admin Console , 點擊對應的伺服器
b. 點擊Server à Monitoring àThreads
c. 點擊: Dump Thread Stack 按鈕
3. 使用WLST (WebLogic Scripting Tool)
connect(『weblogic』,'weblogic1』,』t3://localhost:7001』)
cd(『Servers』)
cd(『AdminServer』)
threadDump()
disconnect()
exit()
注意: 線程堆棧將會保存在運行wlst的當前目錄下.
4. 使用utils.ThreadDumper
用法:
C:\bea\wlserver_10.3\server\lib>java -cp weblogic.jar utils.ThreadDumper
Broadcast Thread mps disabled: must specify weblogic.debug.mpThreadAddr and
weblogic.debug.mpThreadPort
Exception in thread "main" java.lang.I llegalArgumentException: Port out of range
:-1
at java.net.DatagramPacket.setPort(Unknown Source)
at java.net.DatagramPacket.<init>(Unknown Source)
at java.net.DatagramPacket.<init>(Unknown Source)
at utils.ThreadDumper.sendDumpMsg(ThreadDumper.java:124)
at utils.ThreadDumper.main(ThreadDumper.java:145)
5. 如果伺服器是作為Windows服務的方式運行, 請運行下列命令:
WL_HOME\bin\beasvc -mp -svcname:service-name

⑶ mp 怎麼分析死鎖

1、首先構造死鎖，代碼如下：

publicclassDeadlocker{

privatestaticObjectlock_1=newint[1];
privatestaticObjectlock_2=newint[1];

{

@Override
publicvoidrun(){
System.out.println("thread1start");
synchronized(lock_1){
try{
Thread.sleep(5000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
System.out.println("thread1getlock1needlock2");
synchronized(lock_2){
}
}
System.out.println("thread1end");
}
}

{

@Override
publicvoidrun(){
System.out.println("thread2start");
synchronized(lock_2){
try{
Thread.sleep(5000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
System.out.println("thread2getlock2needlock1");
synchronized(lock_1){
}
}
System.out.println("thread2end");
}
}

publicstaticvoidmain(String[]args){
Thread1thread1=newDeadlocker().newThread1();
Thread2thread2=newDeadlocker().newThread2();
thread1.start();
thread2.start();
}
}

2、運行結果如下：

thread1start

thread2start

thread1getlock1needlock2

thread2getlock2needlock1

3、分析：

從列印的結果很容易分析線程1和線程2處於死鎖。相互需要對方的持有的鎖；

4、使用：jps查看線程id，再使用：jstack線程id>mpthread命令。部分結果如下（去除各種gc線程。。。）：

第一部分：

"Thread-1"prio=10tid=0x0000000040a49800nid=0x2d1ewaitingformonitorentry[0x00007f50eda98000]

java.lang.Thread.State:BLOCKED(onobjectmonitor)

atDeadlocker$Thread2.run(Deadlocker.java:47)

-waitingtolock<0x00000007d6f97ec8>(a[I)

-locked<0x00000007d6f97ee0>(a[I)

"Thread-0"prio=10tid=0x0000000040a47800nid=0x2d1dwaitingformonitorentry[0x00007f50edb99000]

java.lang.Thread.State:BLOCKED(onobjectmonitor)

atDeadlocker$Thread1.run(Deadlocker.java:28)

-waitingtolock<0x00000007d6f97ee0>(a[I)

-locked<0x00000007d6f97ec8>(a[I)

。。。。。各種其他線程

這里可以看出兩個線程處於BLOCKED狀態，各自在等待各自的鎖（0x00000007d6f97ec8和0x00000007d6f97ee0）

第二部分：

FoundoneJava-leveldeadlock:

=============================

"Thread-1":

(object0x00000007d6f97ec8,a[I),

whichisheldby"Thread-0"

"Thread-0":

(object0x00000007d6f97ee0,a[I),

whichisheldby"Thread-1"

這個一看就更明白了。。說發現一個java死鎖，Thread-1在等待一個lock，而這個鎖被Thread-0持有，

而Thread-0在等待另外一個lock，而這個鎖被Thread-1持有

:

===================================================

"Thread-1":

atDeadlocker$Thread2.run(Deadlocker.java:47)

-waitingtolock<0x00000007d6f97ec8>(a[I)

-locked<0x00000007d6f97ee0>(a[I)

"Thread-0":

atDeadlocker$Thread1.run(Deadlocker.java:28)

-waitingtolock<0x00000007d6f97ee0>(a[I)

-locked<0x00000007d6f97ec8>(a[I)

Found1deadlock.

上面的紅色部分便也可以清楚查詢到死鎖的位置了；

當然據說第二部分只有java5以上版本才有的（未驗證）。

⑷ win7藍屏 mp文件分析

1、Dump文件是進程的內存鏡像，Win7上的mp文件一般保存C:WindowsMinimp目錄下，需要管理員許可權才可以訪問。
2、要分析mp文件，需要安裝windbg，在Windbg中，通過File→Open
Crash
Dump菜單可以打開mp文件進行分析，如下圖所示：
載入mp文件後，在windbg最下面的命令欄中輸入：!analyze
-v
進行分析即可。!表示是windbg的擴展命令，analyze是擴展的命令，
-v是參數。