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

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

阿新 • • 發佈：2019-01-23 
2018-01-12  建立人：Ruo_Xiao
2018-01-15  修改人：Ruo_Xiao
新增為dump、exe和pdb版本保持一致的原因。

一、minidump檔案

  1. 崩潰轉儲是建立一個應用程式崩潰瞬間的狀態映象。
  2. 初代的轉儲檔案是記錄了程序的虛擬空間中全部內容，但是這樣的檔案非常大，而且對於不太熟練使用的人員來說冗餘資訊太多。
  3. xp之後，MicroSoft發明了“minidump”的轉儲技術，即：小型的，只是包含了必要的執行緒呼叫堆疊等資訊檔案。該檔案很小，很容易通過網路傳送，同時也可以定製該檔案記錄的資訊，非常的靈活。
  4. 生成minidump的函式包含在DbgHelp.dll中。

二、pdb檔案

後續加入！

三、注意事項

1、 exe檔案、dmp檔案和pdb檔案必須保持一致！

在上篇部落格中，我們簡單的介紹瞭如何用dmp檔案和pdb檔案定位程式碼中崩潰位置。連結如下：
http://blog.csdn.net/itworld123/article/details/79041500
上述能夠成功定位的一個前提是exe檔案、dmp檔案和pdb檔案都是同時生成的，即：exe檔案和pdb檔案同時生成，dmp檔案是由當前exe生成的。若生成崩潰資訊之後，又重新編譯了exe，與此同時也重新生成了pdb檔案，那麼即使程式碼沒有任何改動，此時WinDbg也沒有辦法進行程式碼行號定位了，顯示的資訊如下：

WRITE_ADDRESS:  0000000c 

FOLLOWUP_IP: 
TEST11+100b
012b100b c7050c00000005000000 mov dword ptr ds:[0Ch],5

MOD_LIST: <ANALYSIS/>

FAULTING_THREAD:  0000139c

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 746b336a to 012b100b

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
0029f934 746b336a 7efde000 0029f980 77139902 TEST11+0x100b
0029f940 77139902 7efde000 7735f926 00000000 kernel32!BaseThreadInitThunk+0x12
0029f980 771398d5 012b132d 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63
0029f998 00000000 012b132d 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36


STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  TEST11+100b

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  TEST11.exe

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_c0000005_TEST11.exe!Unknown

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/TEST11_exe/0_0_0_0/5a58a12a/TEST11_exe/0_0_0_0/5a58a12a/c0000005/0000100b.htm?Retriage=1

Followup: MachineOwner

上述資訊大家可以看到，定位原始碼的功能已經消失了。

2、關閉程式碼優化功能。

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


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

static long  __stdcall CrashInfocallback(_EXCEPTION_POINTERS *pexcp);

void ErrorFun(int *p)
{
	p[2] = 10;  //這裡崩潰
}

int _tmain(int argc, _TCHAR* argv[])
{
	::SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)CrashInfocallback);
	int *pi = NULL;  
	ErrorFun(pi);  
	return 0;
}

long  __stdcall CrashInfocallback( _EXCEPTION_POINTERS *pexcp)
{
	HANDLE hDumpFile = ::CreateFile(
										L"MEMORY.DMP",
										GENERIC_WRITE,
										0,
										NULL,
										CREATE_ALWAYS,
										FILE_ATTRIBUTE_NORMAL,
										NULL
									);
	if( hDumpFile != INVALID_HANDLE_VALUE)
	{
		MINIDUMP_EXCEPTION_INFORMATION dumpInfo;
		dumpInfo.ExceptionPointers = pexcp;
		dumpInfo.ThreadId = ::GetCurrentThreadId();
		dumpInfo.ClientPointers = TRUE;
		::MiniDumpWriteDump(
								::GetCurrentProcess(),
								::GetCurrentProcessId(),
								hDumpFile,
								MiniDumpNormal,
								&dumpInfo,
								NULL,
								NULL
							);
	}
	::CloseHandle(hDumpFile);
	return 0;
}

上述程式碼在沒有關閉程式碼優化功能的情況下，按照上篇部落格的方法，生成的資訊如下：

WRITE_ADDRESS:  00000008 

FOLLOWUP_IP: 
TEST11!wmain+b [d:\huawei\projects\test11\test11\test11.cpp @ 22]
013e100b c705080000000a000000 mov dword ptr ds:[8],0Ah

MOD_LIST: <ANALYSIS/>

FAULTING_THREAD:  00000814

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 013e120c to 013e100b

STACK_TEXT:  
0038f9cc 013e120c 00000001 00032888 00033a40 TEST11!wmain+0xb [d:\huawei\projects\test11\test11\test11.cpp @ 22]
0038fa10 746b336a 7efde000 0038fa5c 77139902 TEST11!__tmainCRTStartup+0x122 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 552]
WARNING: Stack unwind information not available. Following frames may be wrong.
0038fa1c 77139902 7efde000 775e96bf 00000000 kernel32!BaseThreadInitThunk+0x12
0038fa5c 771398d5 013e132d 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63
0038fa74 00000000 013e132d 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_SOURCE_CODE:  
    18: int _tmain(int argc, _TCHAR* argv[])
    19: {
    20: 	::SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)CrashInfocallback);
    21: 	int *pi = NULL;  
>   22: 	ErrorFun(pi);  
    23: 	return 0;
    24: }
    25: 
    26: long  __stdcall CrashInfocallback( _EXCEPTION_POINTERS *pexcp)
    27: {


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  test11!wmain+b

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  TEST11.exe

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_c0000005_TEST11.exe!wmain

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/TEST11_exe/0_0_0_0/5a58a3c4/TEST11_exe/0_0_0_0/5a58a3c4/c0000005/0000100b.htm?Retriage=1

Followup: MachineOwner

大家可以發現，WinDbg確實定位到了原始碼位置，但是僅僅是函式外面，沒有進去。
後來上網查了很多資料，最後隱約感覺到可能是Release程式碼優化的原因，所以當我關閉程式碼優化的時候，成功地定位到了真正的位置。資訊如下：

WRITE_ADDRESS:  00000008 

FOLLOWUP_IP: 
TEST11!ErrorFun+6 [d:\huawei\projects\test11\test11\test11.cpp @ 15]
00df1006 c740080a000000  mov     dword ptr [eax+8],0Ah

MOD_LIST: <ANALYSIS/>

FAULTING_THREAD:  000013ac

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 00df102f to 00df1006

STACK_TEXT:  
0028fbfc 00df102f 00000000 00000000 0028fc50 TEST11!ErrorFun+0x6 [d:\huawei\projects\test11\test11\test11.cpp @ 15]
0028fc0c 00df1232 00000001 003b2888 003b3a40 TEST11!wmain+0x1f [d:\huawei\projects\test11\test11\test11.cpp @ 22]
0028fc50 746b336a 7efde000 0028fc9c 77139902 TEST11!__tmainCRTStartup+0x122 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 552]
WARNING: Stack unwind information not available. Following frames may be wrong.
0028fc5c 77139902 7efde000 77413872 00000000 kernel32!BaseThreadInitThunk+0x12
0028fc9c 771398d5 00df1353 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x63
0028fcb4 00000000 00df1353 7efde000 00000000 ntdll!RtlInitializeExceptionChain+0x36


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_SOURCE_CODE:  
    11: static long  __stdcall CrashInfocallback(_EXCEPTION_POINTERS *pexcp);
    12: 
    13: void ErrorFun(int *p)
    14: {
>   15: 	p[2] = 10;  //?a¨¤?¡À¨¤¨¤¡ê
    16: }
    17: 
    18: int _tmain(int argc, _TCHAR* argv[])
    19: {
    20: 	::SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)CrashInfocallback);


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  test11!ErrorFun+6

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  TEST11.exe

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_c0000005_TEST11.exe!ErrorFun

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/TEST11_exe/0_0_0_0/5a58a4b0/TEST11_exe/0_0_0_0/5a58a4b0/c0000005/00001006.htm?Retriage=1

Followup: MachineOwner

拓展：VS2010關閉程式碼優化的方法：
專案 -> 工程名 + 屬性
彈出如下圖所示的框：
這裡寫圖片描述
對“優化”選擇“已禁用”，預設為“使速度最大化”，確定之後，重新編譯程式即可。

四、總結

  1. 禁用程式優化功能。
  2. exe、pdb和dmp檔案保持一致。
    解釋：exe檔案和pdb檔案同時生成，dmp檔案是由當前exe生成的。

五、原始碼

相關推薦

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

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

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

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

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

Windows下的lib檔案和dll檔案

一個軟體執行，通常需要一些必備的靜態庫和動態庫。靜態庫和動態庫本身，其實可以作為軟體執行所必需的環境來理解。靜態庫是指靜態的，一般在程式連結時早已放到程式中。動態庫是連結時告訴程式此環境存在，在執行時才呼叫和載入。在Windows下，靜態庫的檔名為lib，動態庫為dll。

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   此命令建立了一個使用

Cuda學習筆記（四）——在vs2010中配置.cpp和.cu檔案

　　Cuda-c極大程度的方便了我們利用GPU並行處理來加快自己程式的執行速度，但是大多情況下我們的程式是一個極為龐大的工程專案，在這個專案中我們只需要利用cuda來加快其中某一塊演算法的執行效率，所以很多情況下利用cpp檔案來呼叫cu中的kernel函式，從而

關於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檔案等)。因此，產生了這次恢復表結