2. 程式人生 > >VS2010下使用dmp檔案和pdb檔案定位到dll中崩潰位置的方法

VS2010下使用dmp檔案和pdb檔案定位到dll中崩潰位置的方法

阿新 • • 發佈：2019-01-03 
2018-01-15  建立人：Ruo_Xiao
郵箱：[email protected]

一、基礎連結

二、原始碼

1、DLL程式碼（工程1）

#pragma once

#ifdef  __XError_Export__
	#define __XError_DLL__  _declspec(dllexport)  
#else
	#define __XError_DLL__  _declspec(dllimport)  
#endif

class __XError_DLL__ XError
{
public:
	XError(void);
	~XError(void);
public:
	void ErrorFun(int *p);
};
--------------------------------------------------------------
void XError::ErrorFun(int *p)
{
	p[2] = 10;  //崩潰位置，原始碼中顯示第16行
}

2、測試程式碼（工程2）

#include "stdafx.h"
#include "source/ErrorDLL/XError.h"
#include <windows.h>

#include <DbgHelp.h>
#pragma comment(lib,"Dbghelp.lib")

static long  __stdcall CrashInfocallback(_EXCEPTION_POINTERS *pexcp);

int _tmain(int argc, _TCHAR* argv[])
{
	::SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)CrashInfocallback);

	XError X;
	int *p = NULL;
	X.ErrorFun(p);   //呼叫dll中含有崩潰程式碼的函式，原始碼第19行
	return 0;
}

long  __stdcall CrashInfocallback(_EXCEPTION_POINTERS *pexcp)
{
	//建立 Dump 檔案
	HANDLE hDumpFile = ::CreateFile(
		L"MEMORY.DMP",
		GENERIC_WRITE,
		0,
		NULL,
		CREATE_ALWAYS,
		FILE_ATTRIBUTE_NORMAL,
		NULL
		);
	if( hDumpFile != INVALID_HANDLE_VALUE)
	{
		//Dump資訊
		MINIDUMP_EXCEPTION_INFORMATION dumpInfo;
		dumpInfo.ExceptionPointers = pexcp;
		dumpInfo.ThreadId = GetCurrentThreadId();
		dumpInfo.ClientPointers = TRUE;
		//寫入Dump檔案內容
		::MiniDumpWriteDump(
			GetCurrentProcess(),
			GetCurrentProcessId(),
			hDumpFile,
			MiniDumpNormal,
			&dumpInfo,
			NULL,
			NULL
			);
	}
	return 0;
}

三、要點

  1. PE檔案中包含了對應的pdb檔案的校驗碼和路徑，二者必須和pdb檔案保持一致，即：PE檔案和pdb檔案必須同時生成，pdb檔案必須在PE檔案中記錄的路徑下。
  2. pdb檔案中記錄了原始碼的位置，若該位置下有原始碼，則定位時不僅可以定位到行號而且還能顯示對應的原始碼，反之只能顯示行號。通常情況下不方便提供原始碼，故pdb檔案必須在所屬的PE檔案下。

四、定位dll檔案中崩潰位置行號步驟

1、修改工程1的pdb檔案生成目錄，如下所示。
專案 -> 工程名 + 屬性，按照下圖修改
這裡寫圖片描述
將“生成程式資料庫檔案”改為上圖所示，意思是dll對應的pdb檔案的生成路徑為C盤PDB檔案下，名字為工程名.pdb，同時該路徑會被記錄在對應的PE檔案中（重要！！！）。
2、將生成的dll檔案copy到exe所在的目錄下，如下所示：
這裡寫圖片描述


雙擊exe，因為程式崩潰自動生成了“MEMORY.DMP”檔案，如下圖所示：
這裡寫圖片描述
3、開啟WinDbg軟體，操作步驟如下：
（1）File -> Image File Path 下圖所示的框：
這裡寫圖片描述
選中“Browse…”按鈕，選擇TEST1.exe，如下圖所示：
這裡寫圖片描述
（2）File -> Open Crash Dump… 選擇剛才生成的"MEMORY.DMP"檔案。
（3）之後軟體會彈出命令列視窗，如下圖所示：
這裡寫圖片描述
在下面命令列那裡輸入“!analyze -v”，WinDbg會自動根據資訊分析出崩潰的程式碼行數，部分結果如下：


WRITE_ADDRESS:  00000008 

FOLLOWUP_IP: 
ErrorDLL!XError::ErrorFun+6 [d:\errordll\errordll\xerror.cpp @ 16]
70591036 c740080a000000  mov     dword ptr [eax+8],0Ah

MOD_LIST: <ANALYSIS/>

FAULTING_THREAD:  00001dac

BUGCHECK_STR:  APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS:  NULL_CLASS_PTR_DEREFERENCE

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER:  from 01201054 to 70591036

STACK_TEXT:  
0038fab8 01201054 00000000 4546f4ea 01203018 ErrorDLL!XError::ErrorFun+0x6 [d:\errordll\errordll\xerror.cpp @ 16]
WARNING: Stack unwind information not available. Following frames may be wrong.
0038fae0 01201268 00000001 00601ba8 00604150 TEST1+0x1054
0038fb24 74a2336a 7efde000 0038fb70 77039902 TEST1+0x1268
0038fb30 77039902 7efde000 7733d33e 00000000 kernel32!BaseThreadInitThunk+0x12
0038fb70 770398d5 01201389 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63
0038fb88 00000000 01201389 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_SOURCE_CODE:  
    12: }
    13: 
    14: void XError::ErrorFun(int *p)
    15: {
>   16: 	p[2] = 10;
    17: }


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  errordll!XError::ErrorFun+6

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  ErrorDLL.dll

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_c0000005_ErrorDLL.dll!XError::ErrorFun

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/TEST1_exe/0_0_0_0/5a5c1877/ErrorDLL_dll/0_0_0_0/5a5d4b1a/c0000005/00001036.htm?Retriage=1


WRITE_ADDRESS:  00000008    
寫入空指標，違規訪問。
---------------------------------------------------------------
XError::ErrorFun+0x6 [d:\errordll\errordll\xerror.cpp @ 16]
dll原始碼中第16行異常。
---------------------------------------------------------------
STACK_COMMAND:  ~0s; .ecxr ; kb
FAULTING_SOURCE_CODE:  
    12: }
    13: 
    14: void XError::ErrorFun(int *p)
    15: {
>   16: 	p[2] = 10;
    17: }
WinDbg定位到了dll原始碼位置。

任務達成！

五、注意事項

  1. exe、pdb和dmp檔案保持版本一致。
  2. 在dll工程設定的 pdb生成目錄下存在對應的pdb檔案。
  3. 原始碼存在於原來的位置，路徑沒有改動。

六、分析

1、若原始碼位置改動，我這裡把路徑下的工程名改為“ErrorDLL00”，WinDbg的部分分析結果如下：


WRITE_ADDRESS:  00000008 

FOLLOWUP_IP: 
ErrorDLL!XError::ErrorFun+6 [d:\errordll\errordll\xerror.cpp @ 16]
70591036 c740080a000000  mov     dword ptr [eax+8],0Ah

MOD_LIST: <ANALYSIS/>

FAULTING_THREAD:  00001dac

BUGCHECK_STR:  APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS:  NULL_CLASS_PTR_DEREFERENCE

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER:  from 01201054 to 70591036

STACK_TEXT:  
0038fab8 01201054 00000000 4546f4ea 01203018 ErrorDLL!XError::ErrorFun+0x6 [d:\errordll\errordll\xerror.cpp @ 16]
WARNING: Stack unwind information not available. Following frames may be wrong.
0038fae0 01201268 00000001 00601ba8 00604150 TEST1+0x1054
0038fb24 74a2336a 7efde000 0038fb70 77039902 TEST1+0x1268
0038fb30 77039902 7efde000 7733d33e 00000000 kernel32!BaseThreadInitThunk+0x12
0038fb70 770398d5 01201389 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63
0038fb88 00000000 01201389 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_SOURCE_CODE:  
No source found for 'd:\errordll\errordll\xerror.cpp'


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  errordll!XError::ErrorFun+6

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  ErrorDLL.dll

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_c0000005_ErrorDLL.dll!XError::ErrorFun

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/TEST1_exe/0_0_0_0/5a5c1877/ErrorDLL_dll/0_0_0_0/5a5d4b1a/c0000005/00001036.htm?Retriage=1

大家可以發現，雖然WinDbg仍然可以分析出原始碼異常行號，但是不能再顯示出對應的原始碼。
在原始碼對應位置顯示的內容如下：

FAULTING_SOURCE_CODE:  
No source found for 'd:\errordll\errordll\xerror.cpp'

大家可以發現，WinDbg不能在該路徑下發現原始碼檔案，故無法顯示對應的異常原始碼。那麼這個原始碼路徑哪來的呢？之前的文章介紹過，這個原始碼路徑就是儲存在ErrorDLL.dll指定的ErrorDLL.pdb中。
2、若原始碼位置沒有改動，我將ErrorDLL工程中pdb檔案生成目錄下的pdb檔案刪除，部分結果如下：

WRITE_ADDRESS:  00000008 

FOLLOWUP_IP: 
ErrorDLL!XError::ErrorFun+6
70591036 c740080a000000  mov     dword ptr [eax+8],0Ah

MOD_LIST: <ANALYSIS/>

FAULTING_THREAD:  00001dac

BUGCHECK_STR:  APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS:  NULL_CLASS_PTR_DEREFERENCE

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER:  from 01201054 to 70591036

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
0038fab8 01201054 00000000 4546f4ea 01203018 ErrorDLL!XError::ErrorFun+0x6
0038fae0 01201268 00000001 00601ba8 00604150 TEST1+0x1054
0038fb24 74a2336a 7efde000 0038fb70 77039902 TEST1+0x1268
0038fb30 77039902 7efde000 7733d33e 00000000 kernel32!BaseThreadInitThunk+0x12
0038fb70 770398d5 01201389 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63
0038fb88 00000000 01201389 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36


STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  errordll!XError::ErrorFun+6

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  ErrorDLL.dll

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_c0000005_ErrorDLL.dll!XError::ErrorFun

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/TEST1_exe/0_0_0_0/5a5c1877/ErrorDLL_dll/0_0_0_0/5a5d4b1a/c0000005/00001036.htm?Retriage=1

Followup: MachineOwner

大家可以發現，如果pdb檔案不存在的話，WinDbg就無法分析出原始碼位置了。

七、總結

  1. PE檔案中會記錄對應的pdb檔案路徑，pdb檔案中會記錄原始碼位置，若三者路徑都是正確的，即：都存在，WinDbg不僅可以定位到行號，還可以顯示原始碼。
  2. 若沒有原始碼，則只能定位到行號，不能定位到原始碼！
  3. 若PE檔案中記錄的對應的pdb檔案路徑下沒有pdb檔案，則WinDbg就連行號也無法定位了，而且結果也是值得商榷了。

八、原始碼

相關推薦

VS2010下使用dmp檔案和pdb檔案定位到dll中崩潰位置的方法

2018-01-15 建立人：Ruo_Xiao 郵箱：[email protected] 一、基礎連結 二、原始碼 1、DLL程式碼（工程1） #pragma once #ifdef __XError_Export__ #define __

VS2010下使用dmp檔案和pdb檔案定位程式異常程式碼行號的注意事項

2018-01-12 建立人：Ruo_Xiao 2018-01-15 修改人：Ruo_Xiao 新增為dump、exe和pdb版本保持一致的原因。 一、minidump檔案 崩潰轉儲是建立一個應用程式崩潰瞬間的狀態映象。 初代的轉儲檔案是記錄了程序的虛擬

Visual Studio 不生成.vshost.exe和.pdb檔案的方法

使用Visual Studio編譯工程時，預設設定下，即使選擇了「Release」時也會生成副檔名為「.vshost.exe」和「.pdb」的檔案。 一、先解釋一下各個檔案的作用： .pdb檔案： 程式資料庫檔案（Program Database File）。預設

windows下使用gcc完成標頭檔案和目標檔案編譯

環境要求 安裝了gcc  win+r然後輸入cmd ， dos介面輸入 gcc -v 檢視有沒有安裝gcc   進入正題 新建 text.c檔案鍵入如下程式碼: #include <stdio.h> #include ".\\head.h" int main(

VS中Release模式下生成去掉生成pdb檔案

前幾天釋出專案，有時候就釋出那幾個dll，但是一個dll同時還有一個pdb檔案，而且pdb檔案貌似還挺大。全選的話，要複製多一份pdb檔案到伺服器，上傳時間長。不全選，就要按住ctrl，再點選每個dll，每次都麻煩得很呀，我想release下，應該可以去掉pdb檔案生成。然後

linux下.tar.gz和.gz檔案解壓詳解，zip壓縮和unzip解壓縮命令詳解

.tar.gz和.gz檔案是兩種不同的檔案，需要區別對待，解壓命令當然也不同咯，下面來分享一下他們各自的解壓方法。1. .tar.gz檔案，這種檔案是tar檔案的壓縮檔案，可以使用tar命令進行解壓。例如：解壓：tar zxvf pythontab.tar.gztar -xj

在spring boot下如何通過rest 介面 來上傳檔案 和下載檔案 到 hadoop hdfs

本文將用程式碼來演示在spring boot裡面，用hadoop client，通過restful API來上傳檔案 和下載檔案 到 hadoop hdfs。 裡面有一些程式碼依賴坑，注意繞行。 前提： 如果你的程式碼在windows上執行，去連線linux上的hado

在windows下另存為Ascii檔案和unicode檔案的問題

"劉"字                 GBK 編碼為 0xC1F5 UNICODE(小端)編碼為   0x5218 在windowsXP下用記事本寫"劉"字，分別另存為ANSI編碼方式，以及unicode編碼方式。 用ultraedit開啟切換到十六進位制模式，發現 ANSI編碼儲存的檔案第一位元組為

Windows下一個複製和刪除檔案（資料夾）的bat指令碼

:: 指令碼建立時最好選擇GB2312編碼 :: @echo off 表示不回顯執行的命令 @echo off ::設定源路徑和目的路徑，使用該變數時需要用一對%包起來 set SRC_PATH=..

Linux 下磁碟分割槽和建立檔案系統（基於Ubuntu平臺）

Linux系統中對於檔案系統的存在方式和windows完全不相同，對於Linux來說一切皆檔案的思想是其核心，所以對於Linux下的裝置來說，其所對應的裝置檔案都存放在/dev目錄下，linux下硬碟裝置名為（IDE硬碟為hdx（x為a開始的字元一般一塊硬碟裝置對應一個字母

ubuntu下svn多倉庫關於dav_svn.conf檔案和authz檔案的修改

目的：建立兩個獨立倉庫repo1和repo2，並使用同一個authz和passwd分配svn許可權，訪問URL為：http://X.X.X.X/svn/repo1 和http://X.X.X.X/svn/repo2 過程：如果未在ubuntu伺服器下搭建過svn+apac

mysql——在沒有ibdata1檔案的情況下用*.frm和*.ibd檔案恢復資料庫

昨天同學問我阿里雲上的資料庫被盜了 只留下了一個QQ號是不是被盜了，辛辛苦苦手敲的化學相關的知識庫就這樣沒了；然後告訴我之前保留過兩個檔案（frm和ibd），然後就百度、Google…etc；資料庫恢復成功 哈哈！！！ 切記 恢復之前先把備份好的frm和i

Android Studio下新增引用jar檔案和so檔案

部落格： 安卓之家 微博： 追風917 CSDN： 蔣朋的家 簡書： 追風917 部落格園： 追風917 安卓開發中我們常會遇到jar檔案和so檔案的引用，下面介紹下在as下如何新增使用，這裡以百度地圖sdk所需的檔案為例。 新增jar

linux下建立使用者和設定檔案許可權

Linux上建立新使用者：useradd命令 -d: 指定使用者登入的目錄 -g: 指定使用者所屬的使用者組 -G: 指定使用者所屬的附加的使用者組 -m: 自動建立登入目錄 例如： useradd -d /user/jetty  -m jetty   此命令建立了一個使用

關於VS2010的除錯資訊即.pdb檔案

在執行FBX的sample程式時發現提示：debug information of xxx.exe cannot be found or not match ，於是首先在網上找了下相關資料，得到如下建議： 1) Goto Project->HelloWorld Pro

linux下普通檔案和目錄檔案區別

http://my.oschina.net/michaelyuanyuan/blog/109147 檔案許可權一般可認為是0 123 456 789，一共十位： 0：表示該檔案的檔案型別。Windows裡面是使用了一種檔案關聯的技術，通過副檔名來關聯相應的應用程式，使得雙擊

在VS2010下如何使用標頭檔案unistd.h

我在編譯一些老程式時裡面包含了如open、read、write、_exit、getpid等函式。在linux下能夠編譯通過的包含此標頭檔案的程式，在VC下編譯時出現瞭如下問題  fatal error C1083: Cannot open include file: '

MySQL innodb引擎下根據.frm和.ibd檔案恢復表結構和資料

  一次恢復資料庫表結構和資料的實戰，僅以此貼作為記錄。   由於，前幾天我們使用的資料庫被入侵(順便鄙視一下安全管理人員)，資料庫中的表都顯示不存在(僅剩一個黑客自建的----qq_xxxxx的表，但物理檔案都在，例如：.frm、.ibd檔案等)。因此，產生了這次恢復表結

Linux下的hosts檔案和network檔案區別

Linux下有兩種與計算機名相關的配置檔案 1、hosts檔案，路徑：/etc/hosts,此文間是在網路上使用的，用於解析計算機名稱和IP地址的對映關係，功能相當於windows下面的c:\windows\system32\drivers\etc\hosts檔案，如果想使

訪問web_inf下的jsp和html檔案

怎麼樣讓servlet訪問web-inf下的網頁或jsp檔案呢.因為web-inf下,應用伺服器把它指為禁訪目錄,即直接在瀏覽器裡是不能訪問到的.因些,可以讓servlet進行訪問,如web-inf下有a.jsp則可以用request.getRequestDispatcher