使用Windbg生成dump文件

合集下载

使用WinDbg分析dump文件

使用WinDbg分析dump文件

使⽤WinDbg分析dump⽂件步骤⼀: ⽣成dump⽂件。

#include <Windows.h>#include <iostream>#include <DbgHelp.h>#include <tchar.h>using namespace std;#pragma comment(lib, "dbghelp.lib")LONG WINAPI TopLevelExceptionFilter(struct _EXCEPTION_POINTERS *pExceptionInfo){cout << "Enter TopLevelExceptionFilter Function" << endl;HANDLE hFile = CreateFile( _T("project.dmp"),GENERIC_WRITE,0,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL); //创建dmp⽂件 MINIDUMP_EXCEPTION_INFORMATION stExceptionParam;stExceptionParam.ThreadId = GetCurrentThreadId();stExceptionParam.ExceptionPointers = pExceptionInfo;stExceptionParam.ClientPointers = FALSE;MiniDumpWriteDump(GetCurrentProcess(),GetCurrentProcessId(),hFile,MiniDumpWithFullMemory,&stExceptionParam,NULL,NULL); //写dmp⽂件 CloseHandle(hFile);getchar();return EXCEPTION_EXECUTE_HANDLER;}int main(){cout<<"Enter Main Function"<<endl;SetUnhandledExceptionFilter(TopLevelExceptionFilter); //设置异常捕获函数 TopLevelExceptionFilterint *pValue = NULL;//int a = 1;//pValue = &a;//*pValue = 2;//cout<<*pValue<<endl;cout<<"Invalid Access"<<endl;*pValue = 1; //写 0地址,程序崩溃cout<<"Finish Main Function"<<endl;getchar();return 0;} 1. 把dbghelp.dll 放置在⽣成的exe路径下: 2. 执⾏exe,⽣成dmp⽂件:步骤⼆: 使⽤ WinDbg 分析 dmp ⽂件。

windbg dump 实现原理

windbg dump 实现原理

Windbg Dump 实现原理详解什么是Windbg Dump?Windbg 是一款由微软开发的强大的调试工具,它主要用于分析和调试 Windows 操作系统和应用程序。

在进行调试过程中,可以使用 Windbg 生成所谓的“dump” 文件,也称为“crash dump” 或“memory dump”。

这个 dump 文件包含了程序在崩溃时的内存状态和信息。

通过分析这个 dump 文件,可以帮助开发人员定位并解决软件问题。

Dump 文件的作用Dump 文件是一个二进制文件,它记录了程序在崩溃时的内存状态、寄存器值、线程堆栈等信息。

通过分析这些信息,可以还原出程序崩溃时的环境和状态,从而帮助开发人员找到导致崩溃的原因。

Dump 文件有以下几个主要作用:1.调试:通过加载 dump 文件到 Windbg 中,可以重现程序崩溃时的环境,并进行调试操作。

可以查看当前线程堆栈、寄存器值、变量值等信息,帮助定位问题。

2.分析:通过分析 dump 文件中的线程堆栈和内存状态,可以确定导致崩溃的具体代码位置,并找到可能存在的 bug。

3.修复:通过定位问题并找到导致崩溃的原因,可以进行代码修复,解决软件问题。

Windbg Dump 实现原理Windbg Dump 的实现原理涉及到操作系统的异常处理机制和调试器的功能。

下面将详细介绍 Windbg Dump 的实现过程。

1. 异常处理机制在操作系统中,当一个应用程序出现错误导致崩溃时,操作系统会捕获这个错误,并生成一个异常。

异常是一种特殊的事件,它指示了应用程序发生了错误,并提供了一些相关信息,如异常类型、错误代码等。

当发生异常时,操作系统会按照事先设定好的规则来处理异常。

其中一个重要的处理方式就是生成 dump 文件。

2. 生成Dump文件生成 dump 文件的过程可以分为以下几个步骤:(1) 异常触发当应用程序出现错误导致崩溃时,操作系统会捕获这个错误,并生成一个异常。

WinDug分析DMP文件方法完全

WinDug分析DMP文件方法完全

WinDbg分析DMP文件方法完全攻略(2012-07-17 20:49:35)转载▼标签:前言:在C++实际开发过程中,开发出来的程序,一般情况下由开发人员进行单元测试,然后移交给测试人员进行测试。

在开发人员测试出现的bug,我们可以直接在本地进行调试。

如果测试人员测试出崩溃级别的bug,如果我们需要调试往往借助于vs提供的Remote Debugger工具进行远程调试(关于vs2010远程调试的方法,请参考/s/blog_a459dcf5010153o7.html),然是当程序在用户手中出现崩溃此时我们可以采用Remote Debugger进行调试,但是如果此时开发人员无法直接去用户现场调试,此时就需要用户生成DMP文件,以便开发人员使用DMP文件进行分析。

本文主要介绍C++开发过程中出现程序崩溃后,如何进行分析定位bug(基于xp系统)。

一、DMP文件获取设置(1)在运行窗口中输入drwtsn32 -i ,并且点击确定(2)在(1)确定后弹出如下对话框(3)在(2)弹出的确定框后点击确定按钮完成,将Dr.Watson设置为默认应用程序调试程序。

Dr.Watson系统自带的程序。

(4)再次在运行窗口中输入:drwtsn32,如下图:(5)点击确定按钮,在弹出的对话框中按照下列方式设置(6) 点击确定按钮完成DMP文件设置。

二、关闭Dr.Watson方法(1)打开注册表(2)在注册表中进入主键[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AeDebug],然后将“AUTO”键值设置为0如下图:三、Windbg下载地址/en-us/windows/hardware/gg463009.aspx,下载完成后安装四、DMP文件获取(1) 用vs2010创建一个基于win32的程序,其源码如下:(2)我们知道在学习C++中整数不能跟0进行除运算,否则会引起程序崩溃。

使用Windbg解析dump文件

使用Windbg解析dump文件

使⽤Windbg解析dump⽂件WinDbgOllyDbgSoftICE (已经停⽌更新)虽说WinDbg在⽆源码调试⽅⾯确实⽐较困难,但在调试内核⽅⾯却真的有独到之处。

使⽤Windbg解析dump⽂件1 常⽤的Windbg指令①!analyze -v②kP 可以看函数的⼊参③!for_each_frame dv /t 可以看函数中的局部变量④dc , db 产看某⼀内存中的值可以直接接变量名不过可能需要回溯栈⑤!threads 显⽰所有线程⑥~0s , ~1s 进⼊某个线程⑦!frame ProcessA!FunctionA 查看某⼀变量有时需要。

回溯栈⑧!uniqstack 扩展命令显⽰当前进程中所有线程的调⽤堆栈,除开重复的那些。

⑨!teb 扩展以的格式化后的形式显⽰线程环境块(TEB)的信息。

⑩s-sa 和 s-su 命令搜索未指定的 ASCII 和 Unicode 字符串。

这在检查某段内存是否包含可打印字符时有⽤。

dds、dps 和 dqs 命令显⽰给定范围内存的内容。

该内存被假定为符号表中的⼀连串地址。

相应的符号也会被显⽰出来。

命令显⽰给定范围内存的内容,它们是把内存区域转储出来, 并把内存中每个元素都视为⼀个符号对其进⾏解析,dds是四字节视为⼀个符号,dqs是每8字节视为⼀个符号,dps是根据当前处理器架构来选择最合适的长度.kframes 命令设置堆栈回溯显⽰的默认长度。

默认20k, kb, kd, kp, kP, kv (Display Stack Backtrace) k*命令显⽰给定线程的调⽤堆栈,以及其他相关信息。

通常要结合12)使⽤否则显⽰出来的东西很少.reload /i xxx.dll 忽略.pdb ⽂件版本不匹配的情况。

2 Symbol的设置⽅法2.1 将远程的系统函数的PDB⽂件拷贝到本地「D:\mysymbol」⽬录下SRV*D:\mysymbol*/download/symbols2.2 加载设置的符号⽂件.reload可以使⽤菜单中的 Debug -> Modules 查看有没有加载进来第三章实例实例1 如何调查堆被破坏问题。

windbg的常用命令--强大常用

windbg的常用命令--强大常用

如何手工抓‎取dump‎文件在生‎产环境下进‎行故障诊断‎时,为了不‎终止正在运‎行的服务或‎应用程序,‎有两种方式‎可以对正在‎运行的服务‎或应用程序‎的进程进行‎分析和调试‎。

首先‎一种比较直‎观简洁的方‎式就是用W‎i nDbg‎等调试器直‎接atta‎c h到需要‎调试的进程‎,调试完毕‎之后再de‎t ach即‎可。

但是这‎种方式有个‎缺点就是执‎行debu‎g ger命‎令时必须先‎b reak‎这个进程,‎执行完de‎b ug命令‎之后又得赶‎紧F5让他‎继续运行,‎因为被你b‎r eak住‎的时候意味‎着整个进程‎也已经被你‎挂起。

另外‎也经常会由‎于Firs‎tCha‎n ce E‎x cetp‎i on而自‎动brea‎k,你得时‎刻留意避免‎长时间br‎e ak整个‎进程。

所以‎这样的调试‎方式对时间‎是个很大的‎考验,往往‎没有充裕的‎时间来做仔‎细分析。

‎另一种方‎式则是在出‎现问题的时‎候,比如C‎P U持续长‎时间100‎%,内存突‎然暴涨等非‎正常情况下‎,通过对服‎务进程sn‎a psho‎t抓取一个‎d ump文‎件,完成d‎u mp之后‎先deat‎c h,让进‎程继续运行‎。

然后用w‎i ndbg‎等工具来分‎析这个抓取‎到的dum‎p文件。

‎那么如何‎在不终止进‎程的情况下‎抓取dum‎p文件呢?‎D ebug‎g ing ‎T ools‎for ‎W indo‎w s 里提供‎了一个非常‎好的工具,‎a dplu‎s.vbs‎。

从名字可‎以看出,实‎际上是一个‎v b脚本,‎只是对cd‎b调试器作‎的一个包装‎脚本。

‎其路径与D‎e bugg‎i ng T‎o ols ‎f or W‎i ndow‎s的安装路‎径相同,使‎用的方法也‎很简单,如‎下所示:‎adpl‎u s.vb‎s -ha‎n g -p‎1234‎-o d‎:\dum‎p其中‎-hang‎指明使用h‎a ng模式‎,亦即在进‎程运行过程‎中附加上去‎s naps‎h ot抓取‎一个dum‎p文件,完‎成之后de‎t ach。

dump文件的函数参数

dump文件的函数参数

dump文件的函数参数一、什么是dump文件?dump文件是程序在运行过程中,将内存中的数据以二进制的形式保存到磁盘上的一种文件格式。

它包含了程序在运行过程中的所有内存信息,包括变量的值、函数的调用栈、堆栈信息等。

通过分析dump文件,可以了解程序在运行过程中的状态,帮助程序员快速定位和解决问题。

二、为什么需要使用dump文件?在程序开发过程中,经常会遇到各种各样的bug和崩溃问题。

当程序出现崩溃时,我们通常无法立即找到问题的原因,这时候使用dump文件就非常有帮助了。

通过分析dump文件,可以还原出程序在崩溃时的内存状态,帮助我们定位问题所在。

三、如何生成dump文件?生成dump文件的方法有很多种,下面介绍两种常用的方法:1. 使用操作系统提供的工具:在Windows操作系统中,可以通过配置系统参数或使用命令行工具来生成dump文件。

例如,在Windows 7及以上版本中,可以通过配置系统参数来指定在程序崩溃时自动生成dump文件。

2. 使用调试工具:在程序调试过程中,可以使用调试工具生成dump文件。

例如,在Visual Studio中,可以通过在代码中插入调试断点或使用异常处理机制来生成dump文件。

dump文件的函数参数是指在生成dump文件时,对相关函数的调用所传递的参数信息。

这些参数信息对于分析问题和定位错误非常重要。

下面介绍几个常见的dump文件函数参数:1. 栈指针(Stack Pointer):栈指针是指向程序当前栈帧的指针,它指向了当前函数的返回地址和函数的局部变量。

通过栈指针,可以获取函数的调用栈信息,从而了解函数的调用关系和参数传递。

2. 堆指针(Heap Pointer):堆指针是指向堆内存区域的指针,堆内存是动态分配的内存,例如通过malloc()函数分配的内存。

通过堆指针,可以获取堆内存的状态信息,帮助我们分析内存泄漏等问题。

3. 函数参数(Function Arguments):函数参数是指函数在调用时传递的参数值。

windbg用法

windbg用法

windbg用法Windbg是微软官方的调试工具,主要用于Windows操作系统和Microsoft Windows应用程序内核级别的调试。

以下是一些Windbg的基本用法:1. 启动Windbg:打开Windbg>文件>打开进程>选择需要调试的进程>打开。

2. 设置符号路径:Windbg默认不会自动找到包含符号信息的pdb文件,需要手动设置符号路径,否则可能出现无法识别符号的问题。

3. 设置断点:Windbg有多种设置断点的方法,包括使用命令行设置、使用界面设置等。

例如,可以使用“bu(break on access)”或“bp(break on process)”设置断点。

4. 执行程序:Windbg在程序执行过程中可以进行单步调试,可以使用“g(go)”命令继续执行代码,也可以使用“p(step into)”、“t(step over)”、“u(step out)”等命令逐行执行代码。

5. 查看调试信息:在Windbg中可以查看程序的调试信息,包括堆栈、寄存器、变量值、汇编代码等。

可以使用“!analyze”命令查看程序崩溃信息,还可以使用“!heap”、“!locks”等命令查看程序运行时的内存信息和锁定信息。

6. 输出调试信息:Windbg可以输出调试信息到文本文件中,可以使用“logopen”、“logappend”、“logclose”等命令将调试信息输出到指定的文件中。

7. 导出内存快照:在Windbg中可以使用“.dump”命令导出内存快照,也可以使用“!writecrashdump”命令将调试信息和内存快照导出到指定的文件中。

8. 反汇编代码:Windbg可以反汇编代码,可以使用“u”、“uf”、“uc”、“ud”等命令查看汇编代码。

以上是Windbg最基本的用法,更多高级用法请查看Windbg相关文档或其他相关资料。

利用WinDbg找出程序崩溃的代码行号

利用WinDbg找出程序崩溃的代码行号

利⽤WinDbg找出程序崩溃的代码⾏号之前碰到论坛⾥有⼏个好友,说程序不时的崩溃,什么xxoo不能read的!如果光要是这个内存地址,估计你会疯掉~~所以分享⼀下基本的调试技巧,需要准备的⼯具有WinDbg + VC6.0,下⾯是⾃⼰整理的⼀份⾃动⽣成DUMP⽂件的源代码,只需要添加到⼯程即可,源代码如下:MiniDump.hMiniDump.cpp<具体请参考附件SRC中,太⼤就不贴了>1、在CXXDlg::OnInitDialog()中添加这样⼀段:1. BOOL CTestDlg::OnInitDialog()2. {3. CDialog::OnInitDialog();4.5. // ......6. SetUnhandledExceptionFilter(CrashReportEx);7. HMODULE hKernel32;8.9. // Try to get MiniDumpWriteDump() address.10. hDbgHelp = LoadLibrary("DBGHELP.DLL");11. MiniDumpWriteDump_ = (MINIDUMP_WRITE_DUMP)GetProcAddress(hDbgHelp, "MiniDumpWriteDump");12. // d("hDbgHelp=%X, MiniDumpWriteDump_=%X", hDbgHelp, MiniDumpWriteDump_);13.14. // Try to get Tool Help library functions.15. hKernel32 = GetModuleHandle("KERNEL32");16. CreateToolhelp32Snapshot_ = (CREATE_TOOL_HELP32_SNAPSHOT)GetProcAddress(hKernel32,"CreateToolhelp32Snapshot");17. Module32First_ = (MODULE32_FIRST)GetProcAddress(hKernel32, "Module32First");18. Module32Next_ = (MODULE32_NEST)GetProcAddress(hKernel32, "Module32Next");19. }复制代码下⾯是⼯程中的测试代码:1. class CTestDlg : public CDialog2. {3. // Construction4. public:5. CTestDlg(CWnd* pParent = NULL); // standard constructor6.7. void Fun1(char *pszBuffer);8. void Fun2(char *pszBuffer);9. void Fun3(char *pszBuffer);10. };复制代码1. void CTestDlg::Fun1(char *pszBuffer)2. {3. Fun2(pszBuffer);4. }5.6. void CTestDlg::Fun2(char *pszBuffer)7. {8. Fun3(pszBuffer);9. }10.11. void CTestDlg::Fun3(char *pszBuffer)12. {13. pszBuffer[1] = 0x00;14. }复制代码我们在双击确定按钮时的响应代码如下:1. void CTestDlg::OnOK()2. {3. // TODO: Add extra validation here4. Fun1(NULL);5. }复制代码2、设置VC编译选项,勾选⽣成MAP和Debug Info、Progma Datebase:1.jpg1.JPG3、将编译⽣成的Release⽬录中的pdb、map⽂件保存起来,以后调试会⽤到:2.jpg4、运⾏程序,单击确定按钮出现异常后⾃动重启,并创建⼀个Log⽂件夹,⾥⾯⽣成dump⽂件:3.jpg5、我们打开WinDbg,设置⼀下相关路径A、设置pdb路径(File \ Symbol File Path)PDBPath.jpgB、设置源代码路径( File \ Source File Path )SourcePath.jpgC、设置Exe路径( File \ Image File Path )ExePath.jpg6、⽤WiinDbg打开dump⽂件(File \ Open Crash Dump)5.jpg7、输⼊命令!analyze -v,等待⼏秒后会打印出错误信息,函数调⽤栈如下图:1.2. Microsoft (R) Windows Debugger Version 6.11.0001.404 X863. Copyright (c) Microsoft Corporation. All rights reserved.4.5.6. Loading Dump File [C:\Test\Release\Log\2012-05-29 160059.dmp]7. User Mini Dump File: Only registers, stack and portions of memory are available8.9. Symbol search path is: C:\Test\Release10. Executable search path is: C:\Test\Release11. Windows XP Version 2600 (Service Pack 3) MP (4 procs) Free x86 compatible12. Product: WinNt, suite: SingleUserTS13. Machine Name:14. Debug session time: Tue May 29 16:00:59.000 2012 (GMT+8)15. System Uptime: not available16. Process Uptime: 0 days 0:00:01.00017. ...................................18. This dump file has an exception of interest stored in it.19. The stored exception information can be accessed via .ecxr.20. (1710.1450): Access violation - code c0000005 (first/second chance not available)21. eax=00a80000 ebx=00157ea8 ecx=00000007 edx=7c92e514 esi=00157e80 edi=00157ed822. eip=7c92e514 esp=0012e830 ebp=0012e840 iopl=0 nv up ei pl zr na pe nc23. cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=0000024624. *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -25. ntdll!KiFastSystemCallRet:26. 7c92e514 c3 ret27. 0:000> !analyze -v28. *******************************************************************************29. * *30. * Exception Analysis *31. * *32. *******************************************************************************33.34. *** ERROR: Symbol file could not be found. Defaulted to export symbols for mfc42.dll -35. *** ERROR: Symbol file could not be found. Defaulted to export symbols for user32.dll -36. ***** OS symbols are WRONG. Please fix symbols to do analysis.37.38. *** ERROR: Symbol file could not be found. Defaulted to export symbols for kernel32.dll -39. *************************************************************************40. *** ***41. *** ***42. *** Your debugger is not using the correct symbols ***43. *** ***44. *** In order for this command to work properly, your symbol path ***45. *** must point to .pdb files that have full type information. ***46. *** ***47. *** Certain .pdb files (such as the public OS symbols) do not ***48. *** contain the required information. Contact the group that ***49. *** provided you with these symbols if you need this command to ***50. *** work. ***51. *** ***52. *** Type referenced: IMAGE_NT_HEADERS32 ***53. *** ***54. *************************************************************************55. *** ERROR: Symbol file could not be found. Defaulted to export symbols for ole32.dll -56. *** ERROR: Symbol file could not be found. Defaulted to export symbols for advapi32.dll -57. *************************************************************************58. *** ***59. *** ***60. *** Your debugger is not using the correct symbols ***61. *** ***62. *** In order for this command to work properly, your symbol path ***63. *** must point to .pdb files that have full type information. ***64. *** ***65. *** Certain .pdb files (such as the public OS symbols) do not ***66. *** contain the required information. Contact the group that ***67. *** provided you with these symbols if you need this command to ***68. *** work. ***69. *** ***70. *** Type referenced: kernel32!pNlsUserInfo ***71. *** ***72. *************************************************************************73. *************************************************************************74. *** ***75. *** ***76. *** Your debugger is not using the correct symbols ***77. *** ***78. *** In order for this command to work properly, your symbol path ***79. *** must point to .pdb files that have full type information. ***80. *** ***81. *** Certain .pdb files (such as the public OS symbols) do not ***82. *** contain the required information. Contact the group that ***83. *** provided you with these symbols if you need this command to ***84. *** work. ***85. *** ***86. *** Type referenced: kernel32!pNlsUserInfo ***87. *** ***88. *************************************************************************89.90. FAULTING_IP:91. Test!CTestDlg::Fun3+6 [C:\Test\TestDlg.cpp @ 141]92. 00401ca6 c6400100 mov byte ptr [eax+1],093.94. EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)95. ExceptionAddress: 00401ca6 (Test!CTestDlg::Fun3+0x00000006)96. ExceptionCode: c0000005 (Access violation)97. ExceptionFlags: 0000000098. NumberParameters: 299. Parameter[0]: 00000001100. Parameter[1]: 00000001101. Attempt to write to address 00000001102.103. PROCESS_NAME: Test.exe104.105. ADDITIONAL_DEBUG_TEXT:106. Use '!findthebuild' command to search for the target build information.107. If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.108.109. MODULE_NAME: Test110.111. FAULTING_MODULE: 7c920000 ntdll112.113. DEBUG_FLR_IMAGE_TIMESTAMP: 4fc48236114.115. ERROR_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"116.117. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"118.119. EXCEPTION_PARAMETER1: 00000001120.121. EXCEPTION_PARAMETER2: 00000001122.123. WRITE_ADDRESS: 00000001124.125. FOLLOWUP_IP:126. Test!CTestDlg::Fun3+6 [C:\Test\TestDlg.cpp @ 141]127. 00401ca6 c6400100 mov byte ptr [eax+1],0128.129. FAULTING_THREAD: 00001450130.131. BUGCHECK_STR:APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE_WRONG_SYMBOLS 132.133. PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE134.135. DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE136.137. LAST_CONTROL_TRANSFER: from 00401c9c to 00401ca6138.139. STACK_TEXT:140. 0012f89c 00401c9c 00000000 0012f8b4 00401c8c Test!CTestDlg::Fun3+0x6 [C:\Test\TestDlg.cpp @ 141]141. 0012f8a8 00401c8c 00000000 0012f8cc 00401f27 Test!CTestDlg::Fun2+0xc [C:\Test\TestDlg.cpp @ 137]142. 0012f8b4 00401f27 00000000 73d323eb 73dcf07c Test!CTestDlg::Fun1+0xc [C:\Test\TestDlg.cpp @ 132]143. 0012f8bc 73d323eb 73dcf07c 00000111 0012f8fc Test!CTestDlg::OnOK+0x7 [C:\Test\TestDlg.cpp @ 242]144. WARNING: Stack unwind information not available. Following frames may be wrong.145. 0012f8cc 73d322fd 0012fe94 00000001 00000000 mfc42!Ordinal567+0xa2146. 0012f8fc 73d976e5 00000001 00000000 00000000 mfc42!Ordinal4424+0x108147. 0012f920 73d33094 00000001 00000000 00000000 mfc42!Ordinal4431+0x1b148. 0012f970 73d31b58 00000000 0014120e 0012fe94 mfc42!Ordinal4441+0x51149. 0012f9f0 73d31b07 00000111 00000001 0014120e mfc42!Ordinal5163+0x2f150. 0012fa10 73d31a78 00000111 00000001 0014120e mfc42!Ordinal6374+0x22151. 0012fa70 73d319d0 0012fe94 00000000 00000111 mfc42!Ordinal1109+0x91152. 0012fa90 73dbe47c 0018124c 00000111 00000001 mfc42!Ordinal1578+0x34153. 0012fabc 77d18734 0018124c 00000111 00000001 mfc42!Ordinal1579+0x39154. 0012fae8 77d18816 73dbe443 0018124c 00000111 user32!GetDC+0x6d155. 0012fb50 77d2927b 00000000 73dbe443 0018124c user32!GetDC+0x14f156. 0012fb8c 77d292e3 006d5120 007101c8 00000001 user32!GetParent+0x16c157. 0012fbac 77d4ff7d 0018124c 00000111 00000001 user32!SendMessageW+0x49158. 0012fbc4 77d465d2 007156c0 00000000 007156c0 user32!CreateMDIWindowA+0x1bd159. 0012fbe0 77d25e94 001530ec 00000001 00000000 user32!DeregisterShellHookWindow+0x6312160. 0012fc64 77d3b082 007156c0 00000202 00000000 user32!IsDlgButtonChecked+0x109a161. 0012fc84 77d18734 0014120e 00000202 00000000 user32!SoftModalMessageBox+0xda3162. 0012fcb0 77d18816 77d3b036 0014120e 00000202 user32!GetDC+0x6d163. 0012fd18 77d189cd 00000000 77d3b036 0014120e user32!GetDC+0x14f164. 0012fd78 77d18a10 00404314 00000000 0012fdac user32!GetWindowLongW+0x127165. 0012fd88 77d274ff 00404314 00404314 0040431c user32!DispatchMessageW+0xf166. 0012fdac 77d3c6d3 0018124c 007156c0 00404314 user32!IsDialogMessageW+0xdb167. 0012fdcc 73d45202 0018124c 00404314 0012fe94 user32!IsDialogMessage+0x4a168. 0012fddc 73d39be0 00404314 73d451ce 00404314 mfc42!Ordinal4047+0x2f169. 0012ff00 73d3c1cf 006f0072 00142373 00000000 mfc42!Ordinal5278+0x29170. 004034c0 00401c20 004019f0 00401a00 00401a10 mfc42!Ordinal1576+0x47171. 004034c4 004019ef 00401a00 00401a10 00402130 Test!CTestDlg::`scalar deleting destructor'172. 004034c8 004019ff 00401a10 00402130 0040212a Test!CTestDlg::~CTestDlg+0xf173. 004034cc 00401a0f 00402130 0040212a 0040203a Test!CObject::Serialize+0xf174. 004034d0 00402130 0040212a 0040203a 00402034 Test!CObject::AssertValid+0xf175. 004034d4 0040212a 0040203a 00402034 0040202e Test!CDialog::OnCmdMsg176. 004034d8 0040203a 00402034 0040202e 00402028 Test!CWnd::OnFinalRelease177. 004034dc 00402034 0040202e 00402028 00402022 Test!CCmdTarget::IsInvokeAllowed178. 004034e0 0040202e 00402028 00402022 00401c70 Test!CCmdTarget::GetDispatchIID179. 004034e4 00402028 00402022 00401c70 0040201c Test!CCmdTarget::GetTypeInfoCount180. 004034e8 00402022 00401c70 0040201c 00402016 Test!CCmdTarget::GetTypeLibCache181. 004034ec 00401c6f 0040201c 00402016 00402010 Test!CCmdTarget::GetTypeLib182. 004034f0 0040201c 00402016 00402010 0040200a Test!CTestDlg::_GetBaseMessageMap+0xf183. 004034f4 00402016 00402010 0040200a 00402004 Test!CCmdTarget::GetCommandMap184. 004034f8 00402010 0040200a 00402004 00401ffe Test!CCmdTarget::GetDispatchMap185. 004034fc 0040200a 00402004 00401ffe 00401ff8 Test!CCmdTarget::GetConnectionMap186. 00403500 00402004 00401ffe 00401ff8 00401ff2 Test!CCmdTarget::GetInterfaceMap187. 00403504 00401ffe 00401ff8 00401ff2 00401fec Test!CCmdTarget::GetEventSinkMap188. 00403508 00401ff8 00401ff2 00401fec 00402124 Test!CCmdTarget::OnCreateAggregates189. 00403608 004022fc 00402310 00000000 19930520 Test!CCmdTarget::GetInterfaceHook190. 0040360c 00402310 00000000 19930520 00000008 Test!WinMainCRTStartup+0x13e191. 00403610 00000000 19930520 00000008 00403638 Test!WinMainCRTStartup+0x152192.193.194. STACK_COMMAND: ~0s; .ecxr ; kb195.196. FAULTING_SOURCE_CODE:197. 137: }198. 138:199. 139: void CTestDlg::Fun3(char *pszBuffer)200. 140: {201. > 141: pszBuffer[1] = 0x00;202. 142: }203. 143:204. 144: BOOL CTestDlg::OnInitDialog()205. 145: {206. 146: CDialog::OnInitDialog();207.208.209. SYMBOL_STACK_INDEX: 0210.211. SYMBOL_NAME: Test!CTestDlg::Fun3+6212.213. FOLLOWUP_NAME: MachineOwner214.215. IMAGE_NAME: Test.exe216.217. BUCKET_ID: WRONG_SYMBOLS218.219. FAILURE_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE_c0000005_Test.exe!CTestDlg::Fun3220.221. WATSON_STAGEONE_URL:/StageOne/Test_exe/1_0_0_1/4fc48236/Test_exe/1_0_0_1/4fc48236/c0000005/00001ca6.htm?Retriage=1222.223. Followup: MachineOwner224. ---------复制代码OK ,这样我们就能在发布版本的程序中,准确的定位到哪个函数出了问题,所以发布程序时,⼀定要记得⽣成pdb、map⽂件,不然客户运⾏出错的话,你不死也残!测试⼯程下载地址:原⽂链接:。

WinDbg分析DUMP文件

WinDbg分析DUMP文件

WinDbg分析DUMP⽂件1. 如何⽣成dump⽂件?原理:通过SetUnhandledExceptionFilter设置捕获dump的⼊⼝,然后通过MiniDumpWriteDump⽣成dump⽂件; SetUnhandledExceptionFilter:MiniDumpWriteDump:⽰例:1 #ifndef _DUMP_GENERATE_H_2#define _DUMP_GENERATE_H_34 #include <Windows.h>5 #include <DbgHelp.h>6#pragma comment(lib, "DbgHelp.lib")78 LONG WINAPI MyUnhandledExceptionFilter(_In_ struct _EXCEPTION_POINTERS *ExceptionInfo);9void MyDumpGenerate();1011void MyDumpGenerate()12 {13 SetUnhandledExceptionFilter(MyUnhandledExceptionFilter);14 }1516 LONG WINAPI MyUnhandledExceptionFilter(_In_ struct _EXCEPTION_POINTERS *ExceptionInfo)17 {18 MessageBox(0,L"DumpGenerate",0,0);1920 HANDLE lhDumpFile = CreateFile(L"D:\\test.dmp", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL, NULL); 2122 MINIDUMP_EXCEPTION_INFORMATION loExceptionInfo;23 loExceptionInfo.ExceptionPointers = ExceptionInfo;24 loExceptionInfo.ThreadId = GetCurrentThreadId();25 loExceptionInfo.ClientPointers = TRUE;26 MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), lhDumpFile, MiniDumpNormal, &loExceptionInfo, NULL, NULL);2728 CloseHandle(lhDumpFile);2930/*31 * EXCEPTION_CONTINUE_SEARCH:将异常传给调试器32 * EXCEPTION_EXECUTE_HANDLER:不显⽰错误信息33*/34return EXCEPTION_EXECUTE_HANDLER;35 }3637#endif// _DUMP_GENERATE_H_3839////////////////40// main.cpp41int main()42 {43 MyDumpGenerate();44int* p = NULL;45 *p = 1;46// 这⾥异常后,会⾃动调⽤MyUnhandledExceptionFilter接⼝,⽣成dump⽂件:test.dmp。

蓝屏dump分析教程(使用WinDbg)

蓝屏dump分析教程(使用WinDbg)

蓝屏dump分析教程(使用WinDbg)一、WinDbg是什么?它能做什么?WinDbg是在windows平台下,强大的用户态和内核态调试工具。

它能够通过dmp文件轻松的定位到问题根源,可用于分析蓝屏、程序崩溃(IE崩溃)原因,是我们日常工作中必不可少的一个有力工具,学会使用它,将有效提升我们的问题解决效率和准确率。

二、WinDbg6.12.0002.633下载:x86位版本下载:【微软官方安装版】蓝屏Dump分析工具WinDbg(x86).rar (13.2 MB, 11,437 次)x64位版本下载:【微软官方安装版】蓝屏Dump分析工具WinDbg(x64).rar (12.4 MB, 9,498 次)三、设置符号表:符号表是WinDbg关键的“数据库”,如果没有它,WinDbg基本上就是个废物,无法分析出更多问题原因。

所以使用WinDbg设置符号表,是必须要走的一步。

1、运行WinDbg软件,然后按【Ctrl+S】弹出符号表设置窗2、将符号表地址:SRV*C:\Symbols*/download/symbols粘贴在输入框中,点击确定即可。

注:红色字体为符号表本地存储路径,建议固定路径,可避免符号表重复下载。

四、学会打开第一个dmp文件!当你拿到一个dmp文件后,可使用【Ctrl+D】快捷键来打开一个dmp文件,或者点击WinDbg界面上的【File=>Open Crash Dump...】按钮,来打开一个dmp文件。

第一次打开dmp文件时,可能会收到如下提示,出现这个提示时,勾选“Don't ask again in this WinDbg session”,然后点否即可。

当你想打开第二个dmp文件时,可能因为上一个分析记录未清除,导致无法直接分析下一个dmp文件,此时你可以使用快捷键【Shift+F5】来关闭上一个dmp分析记录。

至此,简单的WinDbg使用你已经学会了!五、通过简单的几个步骤学会分析一些dmp文件。

windbg诊断蓝屏错误

windbg诊断蓝屏错误

Windows蓝屏是比较严重的系统错误,常常令初学者束手无策,就是对于老鸟们,往往也只能根据蓝屏错误信息给出方向性的判断,很少能直接找出蓝屏的根源。

其实,微软早就出台一款工具---Windbg,高手们也常常用来分析解决蓝屏问题,只不过这款工具还不被更多的人所认识。

下面我们就来介绍一下它。

操作系统在遇到致命错误导致崩溃时,并不是直接挂掉,而是会记录下当时内存中的数据,将其存储成为dump文件,并用一串蓝屏代码向用户做出提示,但这需要用户进行设置。

这样做:第一步,打开电脑的dump文件存储功能。

在“我的电脑”上右键——属性——高级---选好后点确定,下次再出现蓝屏时,系统就会存储下dump文件,一般存放位置在系统盘的minidump文件夹下。

(我们可以从上图查看到该文件夹的目录路径)第二步,下载安装windbg/whdc/devtools/debugging/installx86.mspx#a 这个过程就不说了,随便选一个下载,安装时,一路“下一步”就行了。

第三步,使用windbg诊断蓝屏错误蓝屏后,我们通过重启电脑、或进入安全模式、或使用“最后一次正确配置”等方式进入系统,在minidump文件夹下会出现一个以日期为文件名的东东,那就是我们要的了。

接下来,打开windbg,点File——Open Crash Dump,如图:点File----Symbol File Path。

,在打开的对话框中输入SRV*DownstreamStore*/download/symbols后点”OK”按钮即可,点击”File”菜单,选择“Save Workspace” 来保存当前的设置。

点File——Open Crash Dump,如图:然后找到你的minidump文件夹,dump文件一般是"时间.dmp"如图:打开后就会自动分析了。

分析完后,看最下面,找到3.probably caused by 这一行,如图:看出来了吧?那个myfault.sys文件就是罪魁祸首!好了,到这里相信大家已经学会怎么找到导致系统蓝屏的文件了,接下来怎么办呢?上网查资料,把导致蓝屏的那个文件名在网上搜索,基本就知道是什么文件了,一般网上也有相关的解决办法,看看要删除些什么插件、打什么补丁或者重装软件等等。

windows生成dump文件并分析

windows生成dump文件并分析

1、设置方式A、2003及以下系统:输入drwtsn32命令,设置相关数值:然后输入:drwtsn32 –i设置成默认调试器B、win7及以上系统I、设置dump路径命令行输入regedit,调出注册表,到指定路径:新建项LocalDumps对应的项新建一下这个就是设置dump文件路径这个表示设置的是mini dumpII、屏蔽错误报告设置完自动生成dump后,紧跟着要检查是否关闭了错误报告:注册表依次展开HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting按下图所示操作,将DontshowUI设置为1,这样程序崩溃时系统将不会弹窗,直接生成DUMP2、提取崩溃dump点击TestDump,如下所示:程序崩溃了,点击关闭程序,系统将自动生成dump因为是win7系统,到我们之前设置的目录:N:\dump,可以看到文件:3、准备相关文件:编译之前编译器做如下设置记得同时勾选下面复选框然后编译,生成如下三个重要文件:收集起来,把它放到目录:N:\dump 4、分析dump打开工具,windbg.exe,点击如下菜单:设置symbol路径:点击如下菜单:设置:然后open crash dump打开,得到:输入命令: !analyze –v得到调用栈回溯,此次回溯指向错误地方A、打开windbg.exe,选择file->attach to process:B、选择tdxtc50.exe,点击ok:这个时候,进入windbg界面:C、选择window->command,进入命令行界面:D、输入命令:.dump /ma C:\tdxtc50_exception.dmp在对应路径下面查找对应文件:文件比较大,压缩一下很小,提取出来,可以关闭windbg了小贴士:如果开启有多个tdxtc50,这个时候attach to process会看到多个,这个时候如果无从选择,当事人可以切换到任务管理器,找到所有的tdxtc50.exe的进程,依次右键菜单选择打开文件位置,跟据位置判定当前任务管理器中tdxtc50.exe是否属于崩溃的tc50。

dump文件分析2篇

dump文件分析2篇

dump文件分析2篇第一篇:Windows dump文件分析Windows dump文件是一种用来记录系统崩溃信息的文件。

当Windows操作系统遇到蓝屏或其他严重错误时,会自动生成一个dump文件,其中包含系统状态和运行时数据,这对于问题诊断和修复非常重要。

在本文中,我们将介绍如何分析Windows dump文件,以帮助用户解决系统故障和崩溃问题。

一、获取dump文件通常,当Windows发生蓝屏或停机错误时,会在系统重启时自动生成一个dump文件,将其保存在C:\Windows\Minidump文件夹中。

如果用户没有设置该文件夹位置,则dump文件通常位于系统根目录的MEMORY.DMP文件中。

如果没有自动创建dump文件,则可以手动启用Windows内存转储(crash dump)功能,以生成dump文件。

二、分析dump文件通过分析Windows dump文件,我们可以得到以下信息:1、错误代码:告诉我们这次崩溃的是哪种类型的问题。

例如,错误代码0x0000007B表示硬盘损坏或驱动程序异常。

2、异常地址:崩溃时发生错误的代码位置,帮助我们确定问题来自哪个程序或驱动程序。

3、堆栈跟踪:程序崩溃时调用栈的状态。

从最后一个函数返回地址开始,逐个跟踪函数调用过程,以确定程序崩溃的原因。

以下是我们分析dump文件的步骤:1、使用Debugging Tools for Windows工具(例如WinDbg)打开dump文件。

2、在WinDbg中输入“!analyze -v”命令,以查看错误代码和异常地址。

3、使用“kb”命令查看堆栈跟踪,确定哪个驱动程序或应用程序导致崩溃。

4、在Google或Microsoft的搜索引擎中,输入发生错误代码的十六进制值,以查找可能的解决方案和修复。

例如,如果错误代码为0x0000007B,则可能是硬件设备或磁盘问题。

5、根据分析结果采取相应措施。

例如,更新所有驱动程序、检查硬件问题或升级操作系统。

windbg dump 实现原理

windbg dump 实现原理

windbg dump 实现原理Windbg是一款由微软开发的强大的调试工具,它可以用来分析和调试Windows操作系统和应用程序的崩溃、故障和性能问题。

其中最重要的功能之一就是通过生成dump文件来实现故障现场的复现和分析。

本文将介绍Windbg dump实现的原理。

dump文件,也称为转储文件,是指在应用程序或操作系统发生崩溃时,将当前的内存状态和相关信息保存到硬盘上的文件。

这个文件中包含了崩溃时的堆栈信息、寄存器的值、线程信息、内存分配信息等,可以作为故障现场的快照,为后续的分析提供了重要的依据。

Windbg通过以下几个步骤来生成dump文件:1. 选择dump类型:当应用程序或操作系统发生崩溃时,Windbg 可以通过设置不同的dump类型来决定生成的dump文件包含的信息的多少。

常见的dump类型包括完全内存转储(Full Memory Dump)、小内存转储(Mini Memory Dump)和活动内存转储(Active Memory Dump)等。

不同类型的dump适用于不同的故障场景,选择合适的dump类型对于问题的分析和解决非常重要。

2. 配置符号路径:符号是在代码和调试信息之间建立联系的重要工具,可以帮助我们准确定位到具体的函数和行号。

Windbg可以通过设置符号路径来加载符号文件,从而在分析dump文件时能够正确地解析函数名和行号等信息。

符号路径可以是本地文件路径,也可以是远程服务器地址。

3. 打开dump文件:在Windbg中,可以通过命令行参数或者菜单选项来打开指定的dump文件。

打开dump文件后,Windbg 会加载文件中的数据,并准备好用于分析的环境。

4. 分析dump文件:一旦打开了dump文件,就可以开始进行具体的分析工作了。

Windbg提供了丰富的命令和调试扩展,可以帮助我们查看线程的调用栈、内存的状态、寄存器的值等。

通过分析这些信息,可以找出导致崩溃的原因,比如访问非法内存、死锁、资源泄漏等。

dump文件分析

dump文件分析

dump文件分析Dump文件是一种记录电脑系统状态的文件,通常被用于分析系统崩溃或错误的原因。

通过分析dump文件,可以帮助我们确定问题的根源,并采取相应的措施来解决它们。

在本文中,我将详细介绍如何进行dump文件分析,包括导出和读取dump文件中的信息,以及如何利用这些信息诊断和解决问题。

首先,我们需要了解如何导出一个dump文件。

当系统遇到错误或崩溃时,会自动生成一个dump文件,通常位于Windows系统的Minidump文件夹中。

要导出dump文件,可以按照以下步骤进行操作:1. 打开“控制面板”,选择“系统和安全”。

2. 选择“系统”,然后点击“高级系统设置”。

3. 在“高级”选项卡下,点击“设置”。

4. 在“启动和故障恢复”部分,点击“设置”按钮。

5. 在“系统故障”部分,将“写入调试信息”设置为“小型内存转储”。

6. 点击“确定”来保存更改。

一旦dump文件生成,我们可以使用调试工具来读取和分析它。

Windows操作系统提供了一个名为WinDbg的调试工具,可以用来分析和调试dump文件。

以下是一些基本的WinDbg命令,帮助我们读取和分析dump文件中的信息:1. 打开WinDbg工具,选择“文件”->“打开转储文件”。

2. 导航到dump文件的位置,选择并打开它。

3. 使用“!analyze -v”命令来执行自动分析。

这将提供有关崩溃的基本信息,如错误代码和崩溃地址。

4. 使用其他命令如“!thread”,“!process”,“!stacks”等来获取更详细的信息,如线程、进程和堆栈信息。

通过分析dump文件中的信息,我们可以确定崩溃的原因。

常见的dump文件分析包括以下几个方面:1. 异常信息分析:通过查看异常代码和异常地址,我们可以了解到底发生了什么类型的异常,以及它是在哪个模块中发生的。

这可以帮助我们锁定问题的范围,并有针对性地解决。

2. 线程堆栈分析:通过查看线程的堆栈信息,我们可以定位到代码中引起问题的具体位置。

各种dump方法

各种dump方法

各种dump⽅法dump的⽅法很多,各有特点,都应该掌握。

dump分为两种:⽤户进程dump、系统dump。

先说⽤户进程的dump。

最简单的是在Win7的任务管理器中右键点击进程,选择Create Dump File。

完成之后会弹出对话框说明dump⽂件的位置。

这对于死锁进程的调试有帮助。

⽤WinDbg也很⽅便。

WinDbg是绿⾊版,直接拷贝整个⽬录即可使⽤。

可以Attach到任意的进程中,然后⽤命令.dump xxx.dmp即可。

WinDbg提供了⼀个⽅便的脚本,可以直接取运⾏中进程的dump,完成后⾃动detach,尽量减少对运⾏中进程的影响,⽅便分析CPU 占⽤过⾼、死锁等问题:adplus.vbs -hang -p 1234 -o d:\dump另外⼏个⽤法:adplus -crash -pn w3wp -quiet 抓w3wp进程,crash模式,当那个进程崩溃结束的时候⾃动抓取当时的内存adplus -hang -iis -quiet 抓IIS相关进程,包括其上host的web应⽤,以及iis⾃⾝WinDbg本⾝也是查看分析dump⽂件的最常见⼯具,直接打开dump⽂件即可。

分析dump的常⽤命令:!analyze -v 显⽰所有分析所需的常⽤信息。

k/kb 显⽰调⽤堆栈。

.ecxr 显⽰当前执⾏状态。

.lastevent 查看上⼀个事件(异常也是事件的⼀种)执⾏WinDbg.exe -I会把WinDbg安装成默认的异常处理程序。

如果某个程序崩溃,则⾃动调⽤WinDbg进⼊调试状态。

这时候可以⽅便的取dump。

如果安装了VS2005、VS2008,也可以作为默认的debugger,在Option⾥⾯可以设置。

进程崩溃启动VS后,可以从菜单中选取dump 功能。

以上都是⽤户进程的dump⽅法,下⾯介绍系统dump(摘抄):Dump⽂件有三种:完整内存转储,内核内存转储,⼩内存转储。

System Properties中的⾼级选项中可以看到这些设置。

windbg 的常用命令--强大!常用!

windbg 的常用命令--强大!常用!
!name2ee TestClass.exe TestClass.Program.test //显示test方法相关的地址
!dumpmt -md 00976d48 //得到类的成员函数详细信息
!dumpil 00973028 // 显示这个方法被编译器编译之后的IL代码
1、使用VS2005 + sos.dll
2、使用Windbg + sos.dll
第二种方式功能更加强大,下面我就通过实际操作展示一下怎么使用这种方法得到运行时ArrayList内部的值。
有人可能会说:我直接用Visual Studio的单步调试岂不是更快?当然,这个只是一个演示,通过这个演示是为以后的高级调试打下基础
=======================
在.NET下开发时,最基本的调试方法就是使用Visual Studio的单步调试。但是对于一些特殊情况,特别是涉及到CLR内部的时候使用这种方式就达不到目的了。
如果要查看运行时内存使用情况,IL代码,CLR信息等可以使用以下两种方式:
MethodTable: 790fcb30
EEClass: 790fca90
Size: 26(0x1a) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
在操作之前,先熟悉一下基本知识:
A、使用VS2005 + sos.dll调试
1、需要在项目->属性->调试-〉启用非托管代码调试
2、打开调试-〉窗口-〉即时
3、在即时窗口中输入 !load sos 加载调试模块
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
h Adds data about the handles associated with the target application to the minidump.
u Adds unloaded module information to the minidump. This is available only in Windows Server 2003 and later versions of Windows.
选项(3):/mFhutwd
命令行示例:.dump /mFhutwd C:\dumps\myapp.dmp
注解:带有数据段、非共享的读/写内存页和其他有用的信息的minidump。包含了通过minidump能够得到的最多的信息。是一种折中方案。
--------------------------------------------------------------------------------
我们所说的crash或者exception包括各种各样的情况,比如系统某个进程占用大量资源,某个进程low performance,某个程序crash等等。为了获得发生crash或者exception的process的context, 我们必须得到发生exception的时候,该process的context。那么可以给该process进行捕捉一个snapshot。捕捉发生exception时刻的snapshot所用的方法就是dump当时该process的内存。
i Adds secondary memory to the minidump. Secondary memory is any memory referenced by a pointer on the stack or backing store, plus a small region surrounding this address.
/m[MiniOptions]
Creates a small memory dump (in kernel mode) or a minidump (in user mode). If neither /f nor /m is specified, /m is the default.
In user mode, /m can be followed with additional MiniOptions specifying extra data that to be included in the dump. If no MiniOptions are included, the dump will include module, thread, and stack information, but no additional data. You can add any of the following MiniOptions to change the contents of the dump file; they are case-sensitive.
t Adds additional thread information to the minidump. This includes thread times, which can be displayed by using the !runaway extension or the .ttime (Display Thread Times) command when debugging the minidump.
使用Windbg生成dump文件WinDBG
2010-10-21 23:19:50 阅读145 评论0 字号:大中小 订阅
Windbg生成dump文件的方法:
程序崩溃(crash)的时候, 为了以后能够调试分析问题, 可以使用WinDBG要把当时程序内存空间数据都保存下来,生成的文件称为dump 文件。 步骤:
f Adds full memory data to the minidump. All accessible committed pages owned by the target application will be included.
F Adds all basic memory information to the minidump. This adds a stream to the minidump that contains all basic memory information, not just information about valid memory. This allows the debugger to reconstruct the complete virtual memory layout of the process when the minidump is being debugged.
1) 打开WinDBG并将之Attach 到crash的程序进程
2) 输入产生dump 文件的命令
WinDBG产生dump 文件的命令是 .dump ,可以选择不同的参数来生成不同类型的dump文件。
选项(1): /m
命令行示例:.dump /m C:\dumps\myapp.dmp
R Deletes the full module paths from the minidump. Only the module names will be included. This is a useful option if you want to protect the privacy of the user's directory structure.
2.dump内存的方法
这里介绍一种dump内存的方法,就是windbg中的.dump。当程序发生异常时,我们可以通过该方法snapshot该process在发生exception的时候的context。
具体做法就是:
当program发生exception的时候,或者发生之前,我们可以将windbg attach to a specific process in which en exception will occur. 然后在windbg command window中,type g or press F5 to let the program execute.如果不出意外的话,会出现exception,然后我们我们可以用.dump command来capture the snapshot。the following section is the usage about command .dump.
p Adds process environment block (PEB) and thread environment block (TEB) data to the minidump. This can be useful if you need access to Windows system information regarding the application's processes and threads.
Options
Represents one or more of the following options
/o
Overwrites an existing dump file with the same name. If this is option not used and the there is a file with the same file name, the dump file is not written.
r Deletes from the minidump those portions of the stack and store memory that are not useful for recreating the stack trace. Local variables and other data type values are deleted as well. This option does not make the minidump smaller (because these memory sections are simply zeroed), but it is useful if you want to protect the privacy of other applications.
/f
(Kernel mode:) Creates a complete memory dump.
(User mode:) Creates a full user-mode dump. Despite their names, the largest minidump file actually contains more information than a full user-mode dump. For example, .dump /mf or .dump /ma creates a larger and more complete file than .dump /f. In user mode, .dump /m[MiniOptions] is always preferable to .dump /f.
w Adds all committed read-write private pages to the minidump.
d Adds all read-write data segments within the executable image to the minidump.
c Adds code sections within images.
1.为什么需要dump 内存
相关文档
最新文档