windgb分析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分析高内存占用问题

Windbg分析高内存占用问题阿里巴巴首席工程师经验分享，物超所值。

这样的后果是很严重的，接到反馈，第一时间想到的是加内存吧，这样最快。

但是客户从8G-->16G-->32G，只是延长了每次奔溃的时间，但是并没有解决系统卡顿的问题。

到这里，也基本猜测了问题所在了，肯定是什么东西一直在吃内存且得不到释放。

这种问题，也就只能打Dump分析了。

远程客户应用服务器，32G内存占用已经消耗了78%，而现场已经反馈收银系统接近奔溃了，要求先强制回收内存。

反正也要奔溃了，先打Dump再说吧。

（PS：打Dump会挂起进程，导致应用无法响应！而打Dump的耗时，也是根据当时进程的内存占用有关，内存占用越大，耗时越久。

）打开任务管理器，选择对应的IIS进程，右键创建转储文件（Dump）。

结果，Dump文件是生成的，结果当分析的时候，发现Windbg提示Dump无效。

说明Dump文件创建的有问题。

观察任务管理器，发现内存占用一下就降下来了，原来是之前的进程直接奔溃了，重启了一个W3WP进程。

既然直接从任务管理器无法创建，就使用第三方工具收集Dump吧。

经过Goggle，找到一款很好用的Dump收集工具ProcDump，是一个命令行应用，其主要用途是监视应用程序的CPU或内存峰值并在峰值期间生成Dump。

因为是高内存占用问题，我们使用以下命令来抓取dump：（PS：可以使用进程名称，也可以使用进程ID来指定要创建Dump的进程。

当有多个相同名称的进程时，必须使用进程ID来指定！）procdump w3wp -m 20480 -o D:\Dumps （当内存超过20G时抓取一个w3wp进程的MiniDump）上面就是我踩得第一个坑，因为默认抓取的是MiniDump，很快就抓下来，文件也很小，正在我得意的时候，Windbg加载Dump分析的时候，发现包含的信息很少，根本无法进行进一步的分析。

调整创建Dump的命令，添加-ma参数即可创建完整Dump。

使用Windbg生成dump文件

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.

Windbg常用命令

Windbg常用命令1.创建dump文件:.dump /ma path\filename.dmp2.可以显示系统崩溃时的寄存器，和最后的命令状态: r3.显示当前内存地址，dd 参数：显示参数处的内存: dd4.可以显示反汇编的指令:u5.显示分析的详细信息:！analyze -v6.显示call stack 内容:kb7.显示堆栈的信息:kp8.设置断点:bp [Kernel!SetLastError] [value]9.显示断点信息:bl10.可以显示出错的代码:.bugcheck11.显示异常信息:!analyze -v;.ecxr;!for_each_frame dv /t 12.显示虚拟内存图:!address 0x000a248013.分析:!analyze14.列出加载的模块:lm15.列出锁的信息:!locks16.列出句柄的信息:!handle17.列出并打印句柄信息:!htrace -enable18.物理内存使用情况:!memusage19.虚拟内存使用情况:!vm20.显示进程信息:!process21.列出当前进程所有线程信息:~22.列出当前进程中所有线程的详细信息: ~*23.设置源码文件路径:.srcpath24.显示当前堆栈:k25.显示当前所有线程的堆栈信息:~*kb26.设置缺省显示的框架数:.kframe27.切换当前的框架:.frame28.显示当前局部变量:dv29.显示xxx的数据结构:dt xxx30.显示当前线程的最后错误:!gle/!error31.显示当前线程环境信息:!teb32.显示当前进程环境信息:!peb33.查看命令帮助.hh 如: .hh !peb 34.退出q。

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) 异常触发当应用程序出现错误导致崩溃时，操作系统会捕获这个错误，并生成一个异常。

windbg使用方法

windbg使用方法Windbg是一款由微软公司开发的调试工具，它可以帮助开发人员分析和诊断Windows操作系统和应用程序的问题。

本文将介绍Windbg的基本使用方法，希望能够帮助读者更好地利用这个工具进行调试和分析。

首先，我们需要了解如何安装Windbg。

通常情况下，Windbg是作为Windows驱动程序开发工具包（Windows Driver Kit）的一部分发布的，也可以在微软的官方网站上下载到独立安装包。

安装完成后，我们可以在开始菜单或者安装目录中找到Windbg的可执行文件。

接下来，我们需要了解如何打开并配置Windbg。

在打开Windbg 后，我们可以通过“文件”菜单中的“符号文件路径”选项来设置符号文件的路径，以便Windbg能够正确地加载符号文件。

符号文件对于调试非常重要，它包含了源代码和可执行文件之间的映射关系，能够帮助我们更好地理解程序的运行状态。

在Windbg中，我们可以通过“文件”菜单中的“打开转储文件”选项来打开需要分析的转储文件（dump file）。

转储文件是程序崩溃时生成的一种内存快照，包含了程序崩溃时的内存状态和调用栈信息。

通过分析转储文件，我们可以找出程序崩溃的原因，并进行相应的调试和修复。

除了分析转储文件外，我们还可以通过“调试”菜单中的“附加到进程”选项来附加到正在运行的进程，以实时地监视和分析程序的运行状态。

这对于调试一些无法通过转储文件分析的问题非常有帮助，比如内存泄漏、死锁等问题。

在Windbg中，我们可以使用各种命令来进行调试和分析。

比如，通过“!analyze”命令可以自动分析转储文件，并给出可能的崩溃原因；通过“kb”命令可以查看当前线程的调用栈信息；通过“!heap”命令可以查看进程的堆内存分配情况等等。

熟练掌握这些命令对于高效地进行调试和分析非常重要。

除了命令之外，Windbg还提供了丰富的调试工具，比如内存窗口、寄存器窗口、线程窗口等，这些工具可以帮助我们更直观地了解程序的运行状态。

使用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的常用命令--强大常用

如何手工抓‎取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。

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)一、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文件。

利用Windows Dump文件排除故障

利用Windows Dump文件排除故障最近有个同事联系我，说他那个项目中，某台Windows服务器三天两头的蓝屏，客户坚称自己已经装了杀毒软件，也升级了Windows各种补丁，不可能有事。

然后赖到我们的开发人员写的程序不稳定。

他试图向客户解释我们都是用Java开发的，最多引起JVM崩溃，不可能让OS蓝屏。

可惜客户维护人员属于那种半懂不懂的，始终坚持自己的观点，而且说反正没有多余的服务器，就算不是你们问题，你们不解决也没法开发下去。

我让他把Windows Dump文件发过来再说。

收到Dump文件之后，用Windbg分析了一下，最后得出结论，就是客户自己装的反病毒软件版本不够新，某个驱动有问题才导致系统蓝屏。

最后连同报告附带帮客户下载的升级软件发过去，就皆大欢喜了。

通过这事我了解到，我周围大部分人尽管成天和Windows打交道，也很鄙视Linux，但居然都不知道这个Dump文件是干什么的，有人还按照那些扯淡的优化指南禁用内存转储功能。

即使知道Dump文件是怎么回事的人，也对它表示诚惶诚恐，认为除非通晓C++和Windows内幕才能读懂它里面的天书。

其实，使用M$提供的Windbg工具分析dump文件，从而判断系统蓝屏的原因是非常简单的，根本用不到什么高深知识。

在M$的网站上下载windbg并安装：/whdc/devtools/debugging/default.mspx启动Windbg，选择 File–Symbol File Path…. (选择符号库，根据OS类型决定)，这一步不做也没关系，我就偷懒没下载Symbol Packages。

然后打开：File–Open Crash Dump…选择你收集的dump文件等分析完后，前面都可以忽略，直接看倒数第二行：Probably caused by : xxxxxx.sys一般来说，这个文件就是引起系统崩溃的元凶。

如果不知道它是干什么的，上Google查一下也就知道了。

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文件查看器使用方法

Windbg-分析Windows蓝屏原因利器[转]下载地址先声明下，虽然用windbg诊断蓝屏之前网络上已经有人发过教程了，但就我而言，学会使用windbg来诊断蓝屏也算是自己的原创吧。

以前看一个微软专家的视频（微软专家张银奎老师的《如何诊断和调试蓝屏错误》），专家提到可以用windbg来调试dump文件，当时我就想能不能只关注是什么文件导致的系统崩溃，然后对症下药。

后来通过一系列的实验，自己摸索出了用windbg诊断蓝屏的方法，成功解决了包括KIS7.0插件、QQ插件、迅雷插件导致的蓝屏。

废话就不多说了，本文没什么高深的技术，只是一些简单的操作，但应该可以让身陷蓝屏困扰中的朋友带来些变化，起码能让你知道是谁在捣乱！直观地说，蓝屏是系统崩溃。

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

好了，大家跟我一起设置吧。

第一步，打开电脑的dump文件存储功能。

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

（建议在该文件夹上点右键——属性——发送到——桌面快捷方式，以后就能在桌面上找到该文件夹了）第二步，下载安装windbg/whdc/devtools/debugging/installx86.mspx#a这个过程就不说了，随便选一个下载，安装时，一路“下一步”就行了。

第三步，使用windbg诊断蓝屏错误上面两步设好后，就想办法开始“制造”蓝屏吧，平时怎么用会出现蓝屏就拼命用直到出现蓝屏，嘿嘿。

蓝屏后重启，在minidump文件夹下会出现一个以日期为文件名的东东，那就是我们要的了。

接下来打开windbg，点屏幕左下的“开始”，如下图：软件启动点File——Open Crash Dump,如图：然后找到你的minidump文件夹，dump文件一般是"时间.dmp"如图：打开后就会自动分析了。

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是一款由微软开发的强大的调试工具，它可以用来分析和调试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文件，通常位于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。

最简单的是在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 的常用命令--强大!常用!

!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 加载调试模块

蓝屏Dump文件分析方法

蓝屏Dump⽂件分析⽅法WinDbg使⽤有点⿇烦，还要符号表什么的。

试了下，感觉显⽰很乱，分析的也不够全⾯。

试试其他的吧！今天电脑蓝屏了，就使⽤其dump⽂件测试，如下：1、⾸先，最详细的，要属Osr Online这个在线分析⽹站了：打开其分析地址：下拉，找到上传按钮(上图)，将需要分析的dump⽂件浏览上传即可。

dump⽂件⼀般在C:\Windows\minidump下分析完成后⽣成的内容⾮常多：主要看第⼀个Primary Analysis就好了：Crash Dump Analysis provided by OSR Open Systems Resources, Inc. ()Online Crash Dump Analysis ServiceSee for more informationWindows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64Product: WinNt, suite: TerminalServer SingleUserTSBuilt by: 7601.18741.amd64fre.win7sp1_gdr.150202-1526Machine Name:Kernel base = 0xfffff800`04606000 PsLoadedModuleList = 0xfffff800`0484a890Debug session time: Sun Mar 1307:26:48.1292016 (UTC - 4:00)System Uptime: 12 days 22:27:09.972******************************************************************************** ** Bugcheck Analysis ** ********************************************************************************SYSTEM_SERVICE_EXCEPTION (3b)An exception happened while executing a system service routine.Arguments:Arg1: 00000000c0000005, Exception code that caused the bugcheckArg2: fffff960000c7237, Address of the instruction which caused the bugcheckArg3: fffff88006e6e9d0, Address of the context record for the exception that caused the bugcheckArg4: 0000000000000000, zero.Debugging Details:------------------TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".FAULTING_IP:win32k!HmgLockEx+a3fffff960`000c7237 0fb7430c movzx eax,word ptr [rbx+0Ch]CONTEXT: fffff88006e6e9d0 -- (.cxr 0xfffff88006e6e9d0)rax=fffff900c0210000 rbx=0000000000000000 rcx=fffffa800cc05b50rdx=fffff900c0210000 rsi=0000000000000000 rdi=fffff900c0210000rip=fffff960000c7237 rsp=fffff88006e6f3b0 rbp=0000000000000000r8=0000000000000001 r9=0000000000000000 r10=0000000000000000r11=fffff88006e6f418 r12=000000006601ac00 r13=0000000000000000r14=0000000000000001 r15=0000000000000001iopl=0 nv up ei pl zr na po nccs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010246win32k!HmgLockEx+0xa3:fffff960`000c7237 0fb7430c movzx eax,word ptr [rbx+0Ch] ds:002b:00000000`0000000c=????Resetting default scopeCUSTOMER_CRASH_COUNT: 2DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULTBUGCHECK_STR: 0x3BPROCESS_NAME: dwm.exeCURRENT_IRQL: 0LAST_CONTROL_TRANSFER: from fffff9600028dc00 to fffff960000c7237STACK_TEXT:fffff880`06e6f3b0 fffff960`0028dc00 : fffff900`cddb1320 000006ff`31355348 fffff900`c00cd010 fffff900`d3bc6010 : win32k!HmgLockEx+0xa3fffff880`06e6f420 fffff960`001e3a4c : fffff900`cddb1320 fffff900`cddb1320 fffff900`c00cd010 fffff900`c00cd070 : win32k!SFMLOGICALSURFACE::OwnsSurfaceCleanup+0x40 fffff880`06e6f450 fffff960`001570f9 : fffff900`00000001 fffff900`d3bc6028 00000000`0000000000000029`00000029 : win32k!GreTransferDwmStateToSpriteState+0xf4fffff880`06e6f540 fffff960`0015768d : 00000000`0000000100000000`0000000000000000`00000001 fffff960`00000000 : win32k!zzzDecomposeDesktop+0x139fffff880`06e6f5d0 fffff960`0012c40b : fffffa80`0c132690 fffff880`06e6fae0 00000000`0000000100000000`00000000 : win32k!xxxDwmStopRedirection+0x69fffff880`06e6f620 fffff960`000cad71 : 00000000`0000000000000000`00000000 fffff900`c04010e0 fffffa80`0cc05b00 : win32k!xxxDwmProcessShutdown+0x3bfffff880`06e6f650 fffff960`000ef8d3 : fffff900`c2197c48 fffff900`c2197c20 fffff900`c2197c20 fffff900`c2197c20 : win32k!xxxDestroyThreadInfo+0x5a9fffff880`06e6f720 fffff960`000c6c10 : 00000000`00000000 fffffa80`0cc05b50 fffffa80`0cc05b50 00000000`00000001 : win32k!UserThreadCallout+0x93fffff880`06e6f750 fffff800`04952615 : 00000000`0000000000000000`0000000000000000`00000000 fffffa80`0cc05b00 : win32k!W32pThreadCallout+0x78fffff880`06e6f780 fffff800`04938a75 : 00000000`c0000005 00000000`0000000000000000`7845730000000000`00000000 : nt!PspExitThread+0x285fffff880`06e6f880 fffff800`0466e6fa : 00000000`00000002 fffffa80`0cc05c58 fffff880`06e6fa10 fffff800`047f7e80 : nt!PsExitSpecialApc+0x1dfffff880`06e6f8b0 fffff800`0466ea40 : 00000000`000ff530 fffff880`06e6f930 fffff800`049389e8 00000000`00000001 : nt!KiDeliverApc+0x2cafffff880`06e6f930 fffff800`0467a1f7 : fffffa80`0cc05b50 00000000`000ff418 fffff880`06e6fa88 00000000`00000000 : nt!KiInitiateUserApc+0x70fffff880`06e6fa70 00000000`76e0186a : 00000000`0000000000000000`0000000000000000`0000000000000000`00000000 : nt!KiSystemServiceExit+0x9c00000000`000ff3f8 00000000`00000000 : 00000000`0000000000000000`0000000000000000`0000000000000000`00000000 : 0x76e0186aFOLLOWUP_IP:win32k!HmgLockEx+a3fffff960`000c7237 0fb7430c movzx eax,word ptr [rbx+0Ch]SYMBOL_STACK_INDEX: 0SYMBOL_NAME: win32k!HmgLockEx+a3FOLLOWUP_NAME: MachineOwnerMODULE_NAME: win32kIMAGE_NAME: win32k.sysDEBUG_FLR_IMAGE_TIMESTAMP: 54ee9222STACK_COMMAND: .cxr 0xfffff88006e6e9d0 ; kbFAILURE_BUCKET_ID: X64_0x3B_win32k!HmgLockEx+a3BUCKET_ID: X64_0x3B_win32k!HmgLockEx+a3Followup: MachineOwner---------Primary Analysis⾥⾯提到的重点就是dwm.exe和win32k.sys。