Windbg dump分析 学习总结
Windbg核心调试之dump分析
http://www.pediy.com/kssd/pediy08/pediy8-428.htm标 题： Windbg核心调试之dump分析
作 者：Lvg
时 间：2006-11-17 12:56
链 接：http://bbs.pediy.com/showthread.php?threadid=35044
调试环境：winxp sp2+windbg ver:6.6.0007.5+vmware 5.5.2
附件：点击下载
一．Dump文件的产生，意义和类型
当系统发生错误是，最常见的就是蓝屏（Blue screen），这时就会在系统目录下产生一个Dump文件，如MEMORY.DMP 。这个文件的主要意义在于分析系统错误发生的原因，以作出解决的方法。
它可分为三种类型：
1.完全内存转储。这个文件比较大，和物理内存相当，包含了程序崩溃前系统及用户模式下的所有信
息。
2.核心内存转储。这个文件大小约物理内存的三分之一，主要包含崩溃前系统内核的运行情况。一般
为了分析内核错误，就选用这种文件。
3.小内存转储。这个文件小，只有64k，刚好一个页面文件大小。它包含了相对比较少的信息，主要
可用于微软的在线分析。
以上三种形式的文件可以在我的电脑——〉鼠标右键——〉属性——〉高级——〉故障及恢复中设置
。如下图：
二 Dump文件的强迫产生
由于我们也不知道何时会产生一个系统错误，从而得到dump文件，所以当练习分析时，可认为强迫产生一个。一般有以下两个办法。
1.双机联调。这里的双机可以是物理上的两台电脑，也可以是用虚拟机模拟。我想这里的大多数人应
该选择后者，为啥？还不是money的问题~_^。当用windbg把被调试机联上以后，就可以用.crash命令产
生一个蓝屏，当然之前要在被调试机里把dump产生的路径和类型设定好。还有另外一张办法，是通过修
改注册表后，用键盘产生dump，但这种方法哪有第一种来的快，所以就不说了，感兴趣的可以查查
windbg帮助文档看看。
2.单机驱动产生。这种方法，不必用双机联调，在本机上就可以办到。由于驱动深入到了内核，它的
要求非常苛刻，一个简单的除零操作就可引发蓝屏。但是驱动的编写与普通win32 api是有很大不同的，
为了减轻负担，我直接运用一个现成的程序，是《Microsoft Windows Internals》作者写的Notmyfault
（见附件）。它由Notmyfault.exe和Myfault.sys两部分组成。正如名字一样，引发蓝屏的不是
Notmyfault.exe而是由他加载到内核中的Myfault.sys。如图:
我在这里两种方法都同时用了，先在虚拟机里执行Notmyfault，接着windbg立刻检测到了系统崩溃，
并输出相关信息。
三 Dump文件的分析
当按上面的方法运行后，windbg输出了以下内容：*** Fatal System Error: 0x000000d1
(0xE1147008,0x0000001C,0x00000000,0xFBE93403)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
2.BugCheck D1, {e1147008, 1c, 0, fbe93403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
3.Probably caused by : myfault.sys ( myfault+403 )
Followup: MachineOwner
---------
nt!RtlpBreakWithStatusInstruction:
80527da8 cc int 3
Kd:>
上面这一段，有用的信息，如1和2两段，说明的是一个问题，都指明了BugCheck是D1，并给了四个参数
，这里的D1可以在windbg文档的Bug Check Code Reference中查出其具体含义，也可用!analyze –show
D1命令查出。3说明引起的原因是myfault.sys模块。
接着在kd后输入!analyze –v命令，这个命令是详细列出dump文件的信息。
windbg输出如下：
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) //指明Bugcheck D1,我们已看见过了
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses. //解释了错误的原因
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e1147008, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: fbe93403, address which referenced memory
//给出了相应的四个参数，第二列是代号，第三列是解释
Debugging Details:
------------------
READ_ADDRESS: e1147008 Paged pool //上面的Arg1.
CURRENT_IRQL: 1c //上面的Arg2
FAULTING_IP: //指出发生错误时所执行的指令
myfault+403
fbe93403 8b06 mov eax,dword ptr [esi]
DEFAULT_BUCKET_ID: DRIVER_FAULT //指出错误类型，是驱动错误
BUGCHECK_STR: 0xD1 //bugcheck索引，可查windbg文档，也可!analyze –show D1
PROCESS_NAME: NotMyfault.exe //错误所属进程
TRAP_FRAME: f9357b80 --(trap fffffffff9357b80)//错误时各寄存器的内容
ErrCode = 00000000
eax=00000000 ebx=8111f330 ecx=000000d1 edx=0000001c esi=e1147008 edi=00000000
eip=fbe93403 esp=f9357bf4 ebp=f9357c58 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
myfault+0x403:
fbe93403 8b06 mov eax,dword ptr [esi] ds:0023:e1147008=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 804f880d to 80527da8
STACK_TEXT: //反映了错误前堆栈中函数调用情况，最下面的0x7c801671处函数调用ntdll中的
ZwDeviceIoControlFile，接着调用了ntdll中的KiFastSystemCallRet，再接着调用了nt（这里的nt指
Ntoskrnl）中的KiFastCallEntry，一直到myfault+0x403，发生异常。
f9357734 804f880d 00000003 f9357a90 00000000 nt!RtlpBreakWithStatusInstruction
f9357780 804f93fa 00000003 e1147008 fbe93403 nt!KiBugCheckDebugBreak+0x19
f9357b60 80540853 0000000a e1147008 0000001c nt!KeBugCheck2+0x574
f9357b60 fbe93403 0000000a e1147008 0000001c nt!KiTrap0E+0x233
WARNING: Stack unwind information not available. Following frames may be wrong.
f9357c58 805759d1 ffb5c3b0 8111f318 811d9130 myfault+0x403
f9357d00 8056e33c 00000090 00000000 00000000 nt!IopXxxControlFile+0x5e7
f9357d34 8053d808 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f9357d34 7c92eb94 00000090 00000000 00000000 nt!KiFastCallEntry+0xf8
0012f9f0 7c92d8ef 7c801671 00000090 00000000 ntdll!KiFastSystemCallRet
0012f9f4 7c801671 00000090 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
0012fa54 004018c2 00000090 83360018 00000000 0x7c801671
STACK_COMMAND: kb
FOLLOWUP_IP: //反汇编了发生错误指令的代码
myfault+403
fbe93403 8b06 mov eax,dword ptr [esi]
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: myfault
IMAGE_NAME: myfault.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 43774e1d
SYMBOL_NAME: myfault+403
FAILURE_BUCKET_ID: 0xD1_myfault+403
BUCKET_ID: 0xD1_myfault+403
Followup: MachineOwner
//以上几段看名字就知道了，是以上信息的重复没有多大价值。
四 总结
通过以上的分析，知道了蓝屏的原因是Bugcheck D1引起的，是由于驱动程序读操作了过高的IRQL引起的。也知道了这个引发蓝屏的驱动程序是myfault.sys，属于notmyfaulf.exe的进程。还知道了蓝屏前
bug程序myfault.sys的调用情况等多个有用信息，接着就可以在myfault.sys源程序中进行bug修改了。
========
利用windbg分析dump文件
http://blog.163.com/crazywolf_/blog/static/195231413201061794619624/这里主要记录利用windbg来分析windows蓝屏
时所产生的内存转储文件*.dmp。
1，下载：
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
2，配置symbol path：
windows程序在编译生成后，会产生一些.exe,dll文件。同时也会用到一些symbol文件，这些文件包含全
局变量，局部变量等信息。在调试不同的系统的时候，用到的symbol是不同的，而且这些文件会很大，
如果下载安装会占用很大的硬盘空间。如果下载，在上面提供的地址也可以下载。微软还提供了一个网
络上的symbol服务器。其网络地址是：http://msdl.microsoft.com/download/symbols，设置symbol时
可以在打开windbg后，file->symbol file path 设置如下：其d:\temp 是本地缓存的目录：
SRV*d:/temp/*http://msdl.microsoft.com/download/symbols。也可以用命令如下设置：
set _NT_SYMBOL_PATH=srv*DownstreamStore*http://msdl.microsoft.com/download/symbols
利用windbg分析dump文件（二）基本调试
1，打开dump文件，在正确设置了symbol路径后，会有如下的显示：
Microsoft (R) Windows Debugger Version 6.5.0003.7
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\important\document\win系统\debug\Mini121605-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*d:/temp/*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e8f0
Debug session time: Fri Dec 16 13:30:21.203 2005 (GMT+8)
System Uptime: not available
Loading Kernel Symbols
...........................................................................................
.........................
Loading unloaded module list
...................
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 0, 0, 0}
c0000005 Exception in ext.Analyze debugger extension.
PC: 77c16fa3 VA: 01fe8000 R/W: 0 Parameter: 0001003f
2，关于调试窗口：view菜单下面有详细的列表：可以调出对应的窗口，默认的打开窗口是command窗口
3，基本调试命令：
r 可以显示系统崩溃时的寄存器，和最后的命令状态。
dd 显示当前内存地址，dd 参数：显示参数处的内存。
u 可以显示反汇编的指令
！analyze -v 显示分析的详细信息。
kb 显示call stack 内容
kv.bugcheck 可以显示出错的代码
========
WinDBG 技巧：如何生成Dump 文件(.dump 命令)
http://wingeek.blog.51cto.com/1226974/273964程序崩溃（crash）的时候， 为了以后能够调试分析问题， 可以使用WinDBG要把当时程序内存空间数据
都保存下来，生成的文件称为dump 文件。 步骤：
1） 打开WinDBG并将之Attach 到crash的程序进程
2） 输入产生dump 文件的命令
WinDBG产生dump 文件的命令是 .dump ，可以选择不同的参数来生成不同类型的dump文件。
选项(1)： /m
命令行示例：.dump /m C:\dumps\myapp.dmp
注解： 缺省选项，生成标准的minidump， 转储文件通常较小，便于在网络上通过邮件或其他方式传输
。 这种文件的信息量较少，只包含系统信息、加载的模块（DLL）信息、 进程信息和线程信息。
选项(2)： /ma
命令行示例：.dump /ma C:\dumps\myapp.dmp
注解： 带有尽量多选项的minidump（包括完整的内存内容、句柄、未加载的模块，等等），文件很大，
但如果条件允许（本机调试，局域网环境）， 推荐使用这中dump。
选项(3)：/mFhutwd
命令行示例：.dump /mFhutwd C:\dumps\myapp.dmp
注解：带有数据段、非共享的读/写内存页和其他有用的信息的minidump。包含了通过minidump能够得到
的最多的信息。是一种折中方案。
========
WINDBG调试DUMP文件
http://blog.csdn.net/vah101/article/details/5916384对于windows程序员来说，程序运行时蓝屏是最郁闷的事情，如何找到蓝屏的原因则是首要解决的事
情，好在微软提供了一系列的方法，为我们调试蓝屏提供了便利。
首先要用的工具是windbg，可以到微软的官方网站下载
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.402.msi
再需要下载并安装一个符号链接库，微软官方网站也有提供，这个要根据你所调试系统的版本来选
择
http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d
也可以不下载这个符号库，直接让windbg自己去网上下符号链接信息。
工具软件准备好了，就可以开始设置了，首先进入 “我的电脑”->“属性”->“高级”，选择“启
动和故障恢复”选项卡，在“写入调试信息”一栏选择dump文件的转储方式，在“转储文件”中填入
dump文件的保存路径。当出现蓝屏时，系统就会保存现场，将dump时的运行信息保存起来，以便我们用
windbg来分析。有一条要注意，如果选择了完全内存转储，系统将会把内存中的所有信息都存进文件中
，这会相当缓慢，所以你能看到蓝色屏幕上有一个跳动的数字，那就是保存的进度，必须耐心等待它保
存到100%。
当蓝屏再次发生的时候，我们手上就有了dump文件了，通常在windows目录下的MEMORY.DMP，或者
在windows下的miniDump文件夹中，以*.dmp的形式保存。把.dmp文件拷贝出来，就可以用windbg来调试
。
首先，需要设置一下windbg的符号库，进入windbg的"File"->"Symbol File Path"，在对话框的
“symbol path”里面输入刚才下载的符号库的安装目录，最省心的方法是在这里填入
SRV*c:/temp*http://msdl.microsoft.com/download/symbols就可以让windbg自动去下载所需要的符号
信息。
将这里设置完，就可以开始调试.dmp文件了，打开“File”->“Open Crase Dump”，选择一
个.dmp文件，windbg就开始下载符号库并进行初步的分析，当出现
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000007F, {8, f772ffe0, 0, 0}
Probably caused by : bxnd52x.sys ( bxnd52x+365f )
Followup: MachineOwner
---------
就可以在下面的输入框中敲入
!analyze -v;r;kv;lmtn;.logclose;
回车后就可以看到结果，比如我这里看到
BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 3
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from 00000000 to f759a65f
STACK_TEXT:
f78dc000 00000000 00000000 00000000 00000000 bxnd52x+0x365f
STACK_COMMAND: kb
FOLLOWUP_IP:
bxnd52x+365f
f759a65f 53 push ebx
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: bxnd52x+365f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: bxnd52x
IMAGE_NAME: bxnd52x.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 44a55446
FAILURE_BUCKET_ID: 0x7f_8_bxnd52x+365f
BUCKET_ID: 0x7f_8_bxnd52x+365f
Followup: MachineOwner
---------
说明蓝屏可能是由于bxnd52x.sys驱动的问题造成的，上网百度了一下，这个 bxnd52x.sys是网卡驱动
，下载了一个更高版本的驱动重新安装，蓝屏的问题就解决了。
========
使用Windbg解析dump文件
http://blog.csdn.net/xuleilx/article/details/17622627第一章 常用的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 命令设置堆栈回溯显示的默认长度。默认20
⑬k, kb, kd, kp, kP, kv (Display Stack Backtrace) k*命令显示给定线程的调用堆栈，以及其他相
关信息。通常要结合12)使用否则显示出来的东西很少
⑭.reload /i xxx.dll 忽略.pdb 文件版本不匹配的情况。
第二章 Symbol的设置方法
2.1 将远程的系统函数的PDB文件拷贝到本地「D:\mysymbol」目录下SRV*D:\mysymbol*http://msdl.microsoft.com/download/symbols
2.2 加载设置的符号文件
.reload
可以使用菜单中的 Debug -> Modules 查看有没有加载进来
第三章 实例
实例1 如何调查堆被破坏问题。
错误代码：0xc0000374
错误含义：ACTIONABLE_HEAP_CORRUPTION_heap_failure_buffer_overrun
第一步、先用「!analyze -v」分析出错误的地方以及由于什么原因导致程序Dump掉的。
无非是内存溢出，访问非法地址等几种。
0:009> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
GetPageUrlData failed, server returned HTTP status 404
URL requested:
http://watson.microsoft.com/StageOne/ProcessA_exe/1_0_0_1/5134aefd/ntdll_dll/6_1_7601_18229
/51fb164a/c0000374/000c4102.htm?Retriage=1
FAULTING_IP:
ntdll!RtlReportCriticalFailure+62
00000000`777b4102 eb00 jmp ntdll!RtlReportCriticalFailure+0x64
(00000000`777b4104)
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000777b4102 (ntdll!RtlReportCriticalFailure+0x0000000000000062)
ExceptionCode: c0000374
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 000000007782b4b0
PROCESS_NAME: ProcessA.exe
ERROR_CODE: (NTSTATUS) 0xc0000374 -
EXCEPTION_CODE: (NTSTATUS) 0xc0000374 -
EXCEPTION_PARAMETER1: 000000007782b4b0
MOD_LIST:
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
FAULTING_THREAD: 0000000000002f8c
DEFAULT_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_buffer_overrun
PRIMARY_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_buffer_overrun
BUGCHECK_STR: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_buffer_overrun
LAST_CONTROL_TRANSFER: from 00000000777b4746 to 00000000777b4102
STACK_TEXT:
00000000`0548e170 00000000`777b4746 : 00000000`00000002 00000000`00000023 00000000`00000000
00000000`00000003 : ntdll!RtlReportCriticalFailure+0x62
00000000`0548e240 00000000`777b5952 : 00000000`00000000 00000000`00000000 00000000`00000000
00000000`1c01001d : ntdll!RtlpReportHeapFailure+0x26
00000000`0548e270 00000000`777b7604 : 00000000`00c50000 00000000`00c50000 00000000`0000000a
00000000`00000000 : ntdll!RtlpHeapHandleError+0x12
00000000`0548e2a0 00000000`777b79e8 : 00000000`00c50000 00000000`00000000 00000000`00100000
00000000`00000000 : ntdll!RtlpLogHeapFailure+0xa4
00000000`0548e2d0 00000000`7774fad6 : 00000000`00c50000 00000000`00c59e50 00000000`00c50000
00000000`00000000 : ntdll!RtlpAnalyzeHeapFailure+0x3a8
00000000`0548e330 00000000`777434d8 : 00000000`00c50000 00000000`00000003 00000000`000006cc
00000000`000006e0 : ntdll!RtlpAllocateHeap+0x1d2a
00000000`0548e8d0 00000000`777247ea : 00000000`00000003 00000000`00c5ee80 00000000`00c50278
00000000`000006cc : ntdll!RtlAllocateHeap+0x16c
00000000`0548e9e0 00000000`77723ff2 : 00000000`00c50000 00000000`00000003 00000000`00c5ee90
00000000`000006cc : ntdll!RtlpReAllocateHeap+0x648
00000000`0548eca0 00000000`750c712f : 00000000`0548fbe8 00000000`00c5ee90 00000000`00000000
00000000`000005ac : ntdll!RtlReAllocateHeap+0xa2
00000000`0548edb0 00000001`40010f6f : 00000000`00000000 00000000`0548fbe8 00000000`00000000
00000000`00000661 : msvcr80!realloc+0x6f [f:\dd\vctools\crt_bld\self_64_amd64\crt\src
\realloc.c @ 332]
00000000`0548ede0 00000001`4000f63c : ffffffff`ffffffff 00000000`0548ff10 00000000`00c97fd0
00000000`0548fe48 : ProcessA!FunctionA_AnalyzeEventData+0xfcf [e:\ProcessA
\FunctionA_sockserv.cpp @ 1666]
00000000`0548f8a0 00000000`774e652d : 00000000`000002a0 00000000`00000000 00000000`00000000
00000000`00000000 : ProcessA!FunctionA_SockWork+0xe1c [e:\ProcessA\FunctionA_sockserv.cpp @
1102]
00000000`0548ff60 00000000`7771c541 : 00000000`00000000 00000000`00000000 00000000`00000000
00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0548ff90 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000
00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
STACK_COMMAND: !heap ; ~9s; .ecxr ; kb
FOLLOWUP_IP:
msvcr80!realloc+6f [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\realloc.c @ 332]
00000000`750c712f 4885c0 test rax,rax
SYMBOL_STACK_INDEX: 9
SYMBOL_NAME: msvcr80!realloc+6f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: msvcr80
IMAGE_NAME: msvcr80.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4ec3407e
FAILURE_BUCKET_ID:
ACTIONABLE_HEAP_CORRUPTION_heap_failure_buffer_overrun_c0000374_msvcr80.dll!realloc
BUCKET_ID:
X64_APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_buffer_overrun_msvcr80!
realloc+6f
WATSON_STAGEONE_URL:
http://watson.microsoft.com/StageOne/ProcessA_exe/1_0_0_1/5134aefd/ntdll_dll/6_1_7601_18229
/51fb164a/c0000374/000c4102.htm?Retriage=1
Followup: MachineOwner
---------
第二步、使用「!heap」找出出错的堆。分析出错的原因。
0000000000c59c80
0000000000c59e50 ←出错的堆地址。
0000000000c59fd0
大家应该有这样的常识，在使用malloc()或者realloc()分配出来的空间的前面都有
相应的管理情报，用来记录这块分配的内存的大小以及返回的时候用的情报。
从这里很自然的猜想到，在写往0000000000c59c80里面写数据的时候写过了，
写到0000000000c59e50上去了，导致它的管理情报被覆盖了。从而程序dump掉了。
0:009> !heap
**************************************************************
* *
* HEAP ERROR DETECTED *
* *
**************************************************************
Details:
Heap handle: 0000000000c50000
Error type heap_failure_buffer_overrun (6)
Parameter 1: 000000000000000a
Last known valid blocks: before - 0000000000c59c80, after -0000000000c59fd0
Stack trace:
00000000777b79e8: ntdll!RtlpAnalyzeHeapFailure+0x00000000000003a8
000000007774fad6: ntdll!RtlpAllocateHeap+0x0000000000001d2a
00000000777434d8: ntdll!RtlAllocateHeap+0x000000000000016c
00000000777247ea: ntdll!RtlpReAllocateHeap+0x0000000000000648
0000000077723ff2: ntdll!RtlReAllocateHeap+0x00000000000000a2
00000000750c712f: msvcr80!realloc+0x000000000000006f
0000000140010f6f: ProcessA!FunctionA_AnalyzeEventData+0x0000000000000fcf
000000014000f63c: ProcessA!FunctionA_SockWork+0x0000000000000e1c
00000000774e652d: kernel32!BaseThreadInitThunk+0x000000000000000d
000000007771c541: ntdll!RtlUserThreadStart+0x000000000000001d
Index Address Name Debugging options enabled
1: 001f0000
2: 00010000
3: 00020000
4: 00670000
5: 00950000
6: 00c50000
7: 00910000
8: 00bc0000
9: 010e0000
10: 01220000
11: 01420000
12: 00c30000
13: 03660000
14: 00ba0000
15: 037b0000
16: 01340000
17: 039a0000
第三步、使用「!for_each_frame dv /t」打印出错函数的局部变量，找出元凶。
从下面的变量里面找到距离0000000000c59c80地址最近的变量，对了就是它:
char * pData_n = 0x00000000`00c59c90 "SE:Security: ???"
※注意如果变量值指针的指针需要先用dc看一下该指针指向的地址。
之后看代码知道，程序在读取pData_n的数据的时候如果遇到是0a(Windos换行符)就自动在后面
加上
0d变成0a0d。导致pData_n内存越界了。
0:009> !for_each_frame dv /t
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
12 00000000`0548edb0 00000001`40010f6f msvcr80!realloc+0x6f [f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\realloc.c @ 332]
void * pBlock = 0x00000000`00000000
unsigned int64 newsize = 0x548fbe8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
13 00000000`0548ede0 00000001`4000f63c ProcessA!FunctionA_AnalyzeEventData+0xfcf [e:
\ProcessA\FunctionA_sockserv.cpp @ 1666]
void * cd = 0xffffffff`ffffffff
struct _MpEvsHead * Head = 0x00000000`0548ff10
char * pEventData = 0x00000000`00c97fd0 "???"
char ** pNewData = 0x00000000`0548fe48
char * SiteName = 0x00000000`0548fe18 ""
int oval_check = 0n0
char * pszHostIp = 0x00000000`0548fbf0 "192.168.1.1"
int j = 0n469
int NodeName_check = 0n0
char [2068] eventtext = char [2068] "SE:Security: ???"
unsigned long err = 0
int NL_henkan = 0n1
int Evttxt_check = 0n1
char [129] nameWork = char [129] "`_???"
int ret = 0n0
struct NameObject_t * pNameObj_n = 0x00000000`00c5eee8
char * pData_n = 0x00000000`00c59c90 "SE:Security: ???"
long lWork = 0n9
char [257] szTrcBuff = char [257] "safely divided text.([453]bytes --> [469]bytes)"
long nNameNum = 0n44
long nNewLen = 0n1740
struct NameObject_t * pNameObj_o = 0x00000000`00c98028
char * pData_o = 0x00000000`00c984c6 "SE:Security: ???"
char * pt = 0x00000000`00c59e55 "[???"
long i = 0n20
int IpAddr_check = 0n0
int res = 0n1
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
14 00000000`0548f8a0 00000000`774e652d ProcessA!FunctionA_SockWork+0xe1c [e:\ProcessA
\FunctionA_sockserv.cpp @ 1102]
void * ns = 0x00000000`000002a0
char * pRead_str = 0x00000000`00c562f0 ","
int bTableRegisterd = 0n0
unsigned long err = 0
char [3] traceflg = char [3] ""
int ret = 0n0
short sWork = 0n2
int oval_check = 0n0
char * pNewData = 0x00000000`00c5ee90 "???"
char * wk = 0x00000000`0548f930 "192.168.1.1"
char [33] SiteName = char [33] ""
long lWork = 0n2032
char [257] szTrcBuff = char [257] "recv event OK"
int iLastSerchedIndex = 0n0
char [256] HostIp = char [256] "192.168.1.1"
int ret2 = 0n0
struct _MpEvsHead Head = struct _MpEvsHead
long nDataLen = 0n3
char [257] szTrcBuff2 = char [257] ""
char [20] szSendData = char [20] "OK"
struct addrinfo hinst = struct addrinfo
int conv_disc_set = 0n1
long lRc = 0n0
void * conv_disc = 0xffffffff`ffffffff
int res = 0n1
char * pData = 0x00000000`00c97fd0 "???"
long nRead = 0n3726
char [16] evttype = char [16] "Alarm.sys"
char * lpszEventid = 0x00000000`00c5f180 ""
long nSend = 0n12
char [256] ipTmp = char [256] "192.168.1.1"
char [20] szToCode = char [20] "sjis"
char [20] szFromCode = char [20] "sjis"
int bWriteEvent = 0n1
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
实例2 无效参数(STATUS_INVALID_PARAMETER)。
错误代码：0xc000000d
错误含义：STATUS_INVALID_PARAMETER
第一步、先用「!analyze -v」分析出错误的地方以及由于什么原因导致程序Dump掉的。
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** ERROR: Symbol file could not be found. Defaulted to export symbols for user32.dll -
Unable to load image C:\Windows\Odsv.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Odsv.dll
*** ERROR: Module load completed but symbols could not be loaded for Odsv.dll
GetPageUrlData failed, server returned HTTP status 404
URL requested:
http://watson.microsoft.com/StageOne/ProcessB_exe/1_0_0_1/4e362265/msvcr80_dll/8_0_50727_61
95/4dcdd833/c000000d/0001d5fa.htm?Retriage=1
FAULTING_IP:
msvcr80!strncpy_s+10a [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\tcsncpy_s.inl @ 62]
00000000`74e6d5fa b822000000 mov eax,22h
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000074e6d5fa (msvcr80!strncpy_s+0x000000000000010a)
ExceptionCode: c000000d
ExceptionFlags: 00000000
NumberParameters: 0
PROCESS_NAME: ProcessB.exe
ERROR_CODE: (NTSTATUS) 0xc000000d -
EXCEPTION_CODE: (NTSTATUS) 0xc000000d -
MOD_LIST:
NTGLOBALFLAG: 0
LAST_CONTROL_TRANSFER: from 0000000000124250 to 0000000074e5b0ec
FAULTING_THREAD: ffffffffffffffff
DEFAULT_BUCKET_ID: STATUS_INVALID_PARAMETER
PRIMARY_PROBLEM_CLASS: STATUS_INVALID_PARAMETER
BUGCHECK_STR: APPLICATION_FAULT_STATUS_INVALID_PARAMETER
IP_ON_STACK:
+2e32faf01dedf58
00000000`00124250 60 ???
FRAME_ONE_INVALID: 1
STACK_TEXT:
00000000`00124220 00000000`00124250 : 00000000`00000006 00000000`00000000 00000000`00000001
00000000`00000000 : msvcr80!_invalid_parameter+0x6c [f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\invarg.c @ 88]
00000000`00124228 00000000`00000006 : 00000000`00000000 00000000`00000001 00000000`00000000
00000000`00000000 : 0x124250
00000000`00124230 00000000`00000000 : 00000000`00000001 00000000`00000000 00000000`00000000
00000000`00124260 : 0x6
STACK_COMMAND: ~0s; .ecxr ; kb
FOLLOWUP_IP:
msvcr80!strncpy_s+10a [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\tcsncpy_s.inl @ 62]00000000`74e6d5fa b822000000 mov eax,22h
FAULTING_SOURCE_CODE:
No source found for 'f:\dd\vctools\crt_bld\self_64_amd64\crt\src\tcsncpy_s.inl'
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: msvcr80!strncpy_s+10a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: msvcr80
IMAGE_NAME: msvcr80.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4dcdd833
FAILURE_BUCKET_ID: STATUS_INVALID_PARAMETER_c000000d_msvcr80.dll!strncpy_s
BUCKET_ID: X64_APPLICATION_FAULT_STATUS_INVALID_PARAMETER_msvcr80!strncpy_s+10a
WATSON_STAGEONE_URL:
http://watson.microsoft.com/StageOne/ProcessB_exe/1_0_0_1/4e362265/msvcr80_dll/8_0_50727_61
95/4dcdd833/c000000d/0001d5fa.htm?Retriage=1
Followup: MachineOwner
---------
这次运气很不好，从「!analyze -v」打出来的结果来看看不出啥东西来，只知道
在调用strncpy_s的时候dmp掉了，无法定位具体是哪个函数出错的原因很多，有可能
客户采集的不是全dmp文件或者dmp文件中的栈被破坏了。
这的确很伤脑筋，就针对这个我可是花了3个星期一行行的解析栈里面的内容 才解决的。
第二步、先用「!teb」看一下这个程序的栈是从哪里到哪里的。
0:000>!teb
TEB at 000007ffffeee000
ExceptionList: 0000000000000000
StackBase: 0000000008d50000
StackLimit: 0000000008d4d000
SubSystemTib: 0000000000000000
FiberData: 0000000000001e00
ArbitraryUserPointer: 0000000000000000
Self: 000007ffffeee000
EnvironmentPointer: 0000000000000000
ClientId: 0000000000001bdc . 0000000000001868
RpcHandle: 0000000000000000
Tls Storage: 000007ffffeee058
PEB Address: 000007fffffd6000
LastErrorValue: 87
LastStatusValue: c000000d
Count Owned Locks: 0
HardErrorMode: 0
第三步、先用「dps」看一下这个程序的栈中的内存的内容。 下面截取其中比较重要的一段。
-------------------------------------------------------------------------------------------
------------------------------------
00000000`001247d8 00000000`74e6d5fa msvcr80!strncpy_s+0x10a [f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\tcsncpy_s.inl @ 62]
00000000`001247e0 00000000`009c01e0
00000000`001247e8 00000000`030f5810
00000000`001247f0 00000000`0057e310 ProcessB2!work
★「ProcessB2!work」的内容本应该是像这样的数据「DNxxxxxxxx_150_109」
但是现在「ProcessB2!work」中的内容却是「VIP_rtcrx00184-004a/b-y3b-d」这个。
00000000`001247f8 00000000`005782c0 ProcessB2!trcData
▲「ProcessB2!trcData」的内容是「Function:testB call」。
函数List::testB の trace("testB", __FILE__, __LINE__, TRCLV_3);
00000000`00124800 00000000`00000000
00000000`00124808 00000000`00000000
00000000`00124810 00000000`004a3150 ProcessB2!`string'
▲「 ProcessB2!`string'」的内容是「e:\ProcessB\FunctionB.cpp __FILE__」。
00000000`00124818 00000000`00455b65 ProcessB2!List::testB+0x55 [e:\ProcessB\Listset.cpp @
719]
00000000`00124820 00000000`009c01e0
00000000`00124828 00000000`030f5810
00000000`00124830 00000000`0057e310 ProcessB2!work
00000000`00124838 00000000`001249e0
00000000`00124840 32322e35`322e3000
00000000`00124848 30614031`33312e34
00000000`00124850 7097fb8e`bc923730
00000000`00124858 5049565f`5753334c
00000000`00124860 00000000`0000125f
00000000`00124868 000082bd`b1200d5e
00000000`00124870 00000000`009c01e0
00000000`00124878 00000000`00467bda ProcessB2!FunctionB+0x73a [e:\ProcessB\FunctionB.cpp @
181]
-------------------------------------------------------------------------------------------
------------------------------------
这里终于定位到是哪个函数出问题。搞清楚这些函数的功能，然后打印出所有可能打印的内容，发现
函数传递了一个不合法的数据。在这里要说一下为啥传的数据不合法就会Dmp掉。
首先strncpy 这个函数在使用的时候只要有个宏定义(默认是有的)在编译的时候就会使用strncpy_s这个
安全函数。
详情可以参考下面微软的说明文档。
http://msdn.microsoft.com/zh-cn/LIBRARY/ms175759(v=vs.80)
其次说明一下为什么会dmp掉。strncpy在使用的时候如果转化成strncpy_s的时候是这样一种形式。
char dst[5];
strncpy(dst, "a long string", 5); ----> strncpy_s(dst, 5, "a long string", 5);
而这样就会到时报STATUS_INVALID_PARAMETER这个错误这是strncpy_s的特性。具体使用方法可以参考下
面的文档。
http://msdn.microsoft.com/zh-cn/library/5dae5d43(v=vs.90).aspx
节选:
char dst[5];
strncpy_s(dst, 5, "a long string", 5);
means that we are asking strncpy_s to copy five characters into a buffer five bytes long;
this would leave no space for the null terminator, hence strncpy_s zeroes out the string
and calls the invalid parameter handler.
If truncation behavior is needed, use _TRUNCATE or (size – 1):
strncpy_s(dst, 5, "a long string", _TRUNCATE);
strncpy_s(dst, 5, "a long string", 4);
详细的ACTIONABLE_HEAP_CORRUPTION_heap_failure_buffer_overrun方法还可以参考以下的例子:
http://blogs.msdn.com/b/jiangyue/archive/2010/03/16/windows-heap-overrun-monitoring.aspx
========
windbg分析dump文件
http://blog.csdn.net/xiaoshahai/article/details/7284867/前言：WinDbg是微软开发的免费源代码级的调试工具。WinDbg可以用于Kernel模式调试和用户模式调试
，还可以调试Dump文件。本文的讨论是在安装了Debugging Tools for Windows 的前提下进行的，下载
地址可以参考我之前的文章。WinDbg对于dump文件的调试可以通过菜单设置Symbol File Path、Source
File Path ，并可设置多个路径。
1、 打开Dump格式文件
打开WinDbg，通过菜单[File] à [Open Crash dump] 选择dump文件打开，也可通过CMD打开Dos命令窗口
，切换到WinDbg所在目录，利用命令：
WinDbg –z “D:/Lines2009-7-25-22-20-33-900.dmp”
-z表示路径
clip_image001
图1.1 利用WinDbg打开dump文件
本文编写了一个简单能产生除数为0异常的程序，让其运行，产生崩溃，通过drwtsn产生dmp文件，然后
通过windbg分析dmp文件，定位程序bug。
目的:学习windbg基本功能使用。
程序源代码：
void Crash(void)
{
int i = 1;
int j = 0;
i /= j;
}
void main(void)
{
Crash();
}编译环境：vc++6.0
编译器设置：
这一步设置，要求对release版本不使用优化，如果使用优化，上面源代码中Crash(void)函数将不被汇
编。
这一步设置，产生release版本的调试符号表，为后续定位错误准备。
步骤：
1、 安装drwtsn32
用户可以通过drwtsn32命令，查看dmp文件会被保存在何处。
2、 安装windbg,Windbg下载地址：
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
3、 设置windbg
A、符号表路径设置
其中;srv*d:/symbolslocal*http://msdl.microsoft.com/download/symbols设置的目的是下载该程序用
到的操作系统相关的库函数的符号表到本地。
B、源代码路径设置
C、dmp文件导入
载入dump文件显示如图：
clip_image002
图1.2 WinDbg界面
2、 分析dump文件
若生成的dump文件在本机，dump文件中将包含调试需要的PDB文件及源代码路径，若不在本机，可以通过
WinDbg菜单[File] à [Symbol File path] 及 [Source File Path] 分别设置PDB文件路径和源代码路径
。如果程序涉及到DLL，需要将EXE、DLL所有涉及的PDB、源代码路径都包括。使用命令：
!analyze –v
将分析dump文件，并显示程序崩溃处于的代码行：
clip_image003
图1.3 分析dump 文件
========
调试技巧 —— 如何利用windbg + dump + map分析程序异常
http://blog.csdn.net/xiaoshahai/article/details/7285103之前碰到论坛里有几个好友，说程序不时的崩溃，什么xxoo不能read的！ 如果光要是这个内存地址，估
计你会疯掉~~
所以分享一下基本的调试技巧，需要准备的工具有WinDbg + VC6.0，
下面是自己整理的一份自动生成DUMP文件的源代码，只需要添加到工程即可，源代码如下：
MiniDump.h
[cpp] view plaincopy
#include
#include
//#include "dbghelp.h"
//#define DEBUG_DPRINTF 1 //allow d()
//#include "wfun.h"
#pragma optimize("y", off) //generate stack frame pointers for all functions - same as
/Oy- in the project
#pragma warning(disable: 4200) //nonstandard extension used : zero-sized array in
struct/union
#pragma warning(disable: 4100) //unreferenced formal parameter
/*BOOL WINAPI Get_Module_By_Ret_Addr(PBYTE Ret_Addr, PCHAR Module_Name, PBYTE &
Module_Addr);
int WINAPI Get_Call_Stack(PEXCEPTION_POINTERS pException, PCHAR Str);
int WINAPI Get_Version_Str(PCHAR Str);
PCHAR WINAPI Get_Exception_Info(PEXCEPTION_POINTERS pException);
void WINAPI Create_Dump(PEXCEPTION_POINTERS pException, BOOL File_Flag, BOOL Show_Flag);*/
// In case you don't have dbghelp.h.
#ifndef _DBGHELP_
typedef struct _MINIDUMP_EXCEPTION_INFORMATION {
DWORD ThreadId;
PEXCEPTION_POINTERS ExceptionPointers;
BOOL ClientPointers;
} MINIDUMP_EXCEPTION_INFORMATION, *PMINIDUMP_EXCEPTION_INFORMATION;
typedef enum _MINIDUMP_TYPE {
MiniDumpNormal = 0x00000000,
MiniDumpWithDataSegs = 0x00000001,
} MINIDUMP_TYPE;
typedef BOOL (WINAPI * MINIDUMP_WRITE_DUMP)(
IN HANDLE hProcess,
IN DWORD ProcessId,
IN HANDLE hFile,
IN MINIDUMP_TYPE DumpType,
IN CONST PMINIDUMP_EXCEPTION_INFORMATION
ExceptionParam, OPTIONAL
IN PVOID
UserStreamParam, OPTIONAL
IN PVOID
CallbackParam OPTIONAL
);
#else
typedef BOOL (WINAPI * MINIDUMP_WRITE_DUMP)(
IN HANDLE hProcess,
IN DWORD ProcessId,
IN HANDLE hFile,
IN MINIDUMP_TYPE DumpType,
IN CONST PMINIDUMP_EXCEPTION_INFORMATION
ExceptionParam, OPTIONAL
IN PMINIDUMP_USER_STREAM_INFORMATION
UserStreamParam, OPTIONAL
IN PMINIDUMP_CALLBACK_INFORMATION
CallbackParam OPTIONAL
);
#endif //#ifndef _DBGHELP_
// Tool Help functions.
typedef HANDLE (WINAPI * CREATE_TOOL_HELP32_SNAPSHOT)(DWORD dwFlags, DWORD th32ProcessID);
typedef BOOL (WINAPI * MODULE32_FIRST)(HANDLE hSnapshot, LPMODULEENTRY32 lpme);
typedef BOOL (WINAPI * MODULE32_NEST)(HANDLE hSnapshot, LPMODULEENTRY32 lpme);
extern void WINAPI Create_Dump(PEXCEPTION_POINTERS pException, BOOL File_Flag, BOOL
Show_Flag);
extern HMODULE hDbgHelp;
extern MINIDUMP_WRITE_DUMP MiniDumpWriteDump_;
extern CREATE_TOOL_HELP32_SNAPSHOT CreateToolhelp32Snapshot_;
extern MODULE32_FIRST Module32First_;
extern MODULE32_NEST Module32Next_;
MiniDump.cpp
/*
Author: Vladimir Sedach.
Purpose: demo of Call Stack creation by our own means,
and with MiniDumpWriteDump() function of DbgHelp.dll.
*/
#include "StdAfx.h"
#include "MiniDump.h"
#include
#pragma comment(lib,"shlwapi.lib")
HMODULE hDbgHelp;
MINIDUMP_WRITE_DUMP MiniDumpWriteDump_;
CREATE_TOOL_HELP32_SNAPSHOT CreateToolhelp32Snapshot_;
MODULE32_FIRST Module32First_;
MODULE32_NEST Module32Next_;
#define DUMP_SIZE_MAX 8000 //max size of our dump
#define CALL_TRACE_MAX ((DUMP_SIZE_MAX - 2000) / (MAX_PATH + 40)) //max number of traced
calls
#define NL "\r\n" //new line
extern CString GetExePath();
//****************************************************************************************
BOOL WINAPI Get_Module_By_Ret_Addr(PBYTE Ret_Addr, PCHAR Module_Name, PBYTE & Module_Addr)
//****************************************************************************************
// Find module by Ret_Addr (address in the module).
// Return Module_Name (full path) and Module_Addr (start address).
// Return TRUE if found.
{
MODULEENTRY32 M = {sizeof(M)};
HANDLE hSnapshot;
Module_Name[0] = 0;
if (CreateToolhelp32Snapshot_)
{
hSnapshot = CreateToolhelp32Snapshot_(TH32CS_SNAPMODULE, 0);
if ((hSnapshot != INVALID_HANDLE_VALUE) &&
Module32First_(hSnapshot, &M))
{
do
{
if (DWORD(Ret_Addr - M.modBaseAddr) < M.modBaseSize)
{
lstrcpyn(Module_Name, M.szExePath, MAX_PATH);
Module_Addr = M.modBaseAddr;
break;
}
} while (Module32Next_(hSnapshot, &M));
}
CloseHandle(hSnapshot);
}
return !!Module_Name[0];
} //Get_Module_By_Ret_Addr
//******************************************************************
int WINAPI Get_Call_Stack(PEXCEPTION_POINTERS pException, PCHAR Str)
//******************************************************************
// Fill Str with call stack info.
// pException can be either GetExceptionInformation() or NULL.
// If pException = NULL - get current call stack.
{
CHAR Module_Name[MAX_PATH];
PBYTE Module_Addr = 0;
PBYTE Module_Addr_1;
int Str_Len;
typedef struct STACK
{
STACK * Ebp;
PBYTE Ret_Addr;
DWORD Param[0];
} STACK, * PSTACK;
STACK Stack = {0, 0};
PSTACK Ebp;
if (pException) //fake frame for exception address
{
Stack.Ebp = (PSTACK)pException->ContextRecord->Ebp;
Stack.Ret_Addr = (PBYTE)pException->ExceptionRecord->ExceptionAddress;
Ebp = &Stack;
}
else
{
Ebp = (PSTACK)&pException - 1; //frame addr of Get_Call_Stack()
// Skip frame of Get_Call_Stack().
if (!IsBadReadPtr(Ebp, sizeof(PSTACK)))
Ebp = Ebp->Ebp; //caller ebp
}
Str[0] = 0;
Str_Len = 0;
// Trace CALL_TRACE_MAX calls maximum - not to exceed DUMP_SIZE_MAX.
// Break trace on wrong stack frame.
for (int Ret_Addr_I = 0;
(Ret_Addr_I < CALL_TRACE_MAX) && !IsBadReadPtr(Ebp, sizeof(PSTACK)) && !
IsBadCodePtr(FARPROC(Ebp->Ret_Addr));
Ret_Addr_I++, Ebp = Ebp->Ebp)
{
// If module with Ebp->Ret_Addr found.
if (Get_Module_By_Ret_Addr(Ebp->Ret_Addr, Module_Name, Module_Addr_1))
{
if (Module_Addr_1 != Module_Addr) //new module
{
// Save module's address and full path.
Module_Addr = Module_Addr_1;
Str_Len += wsprintf(Str + Str_Len, NL "%08X %s", Module_Addr,
Module_Name);
}
// Save call offset.
Str_Len += wsprintf(Str + Str_Len,
NL " +%08X", Ebp->Ret_Addr - Module_Addr);
// Save 5 params of the call. We don't know the real number of params.
if (pException && !Ret_Addr_I) //fake frame for exception address
Str_Len += wsprintf(Str + Str_Len, " Exception Offset");
else if (!IsBadReadPtr(Ebp, sizeof(PSTACK) + 5 * sizeof(DWORD)))
{
Str_Len += wsprintf(Str + Str_Len, " (%X, %X, %X, %X, %X)",
Ebp->Param[0], Ebp->Param[1], Ebp->Param[2], Ebp->Param[3], Ebp->Param
[4]);
}
}
else
Str_Len += wsprintf(Str + Str_Len, NL "%08X", Ebp->Ret_Addr);
}
return Str_Len;
} //Get_Call_Stack
//***********************************
int WINAPI Get_Version_Str(PCHAR Str)
//***********************************
// Fill Str with Windows version.
{
OSVERSIONINFOEX V = {sizeof(OSVERSIONINFOEX)}; //EX for NT 5.0 and later
if (!GetVersionEx((POSVERSIONINFO)&V))
{
ZeroMemory(&V, sizeof(V));
V.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx((POSVERSIONINFO)&V);
}
if (V.dwPlatformId != VER_PLATFORM_WIN32_NT)
V.dwBuildNumber = LOWORD(V.dwBuildNumber); //for 9x HIWORD(dwBuildNumber) = 0x04xx
return wsprintf(Str,
NL "Windows: %d.%d.%d, SP %d.%d, Product Type %d", //SP - service pack, Product
Type - VER_NT_WORKSTATION,...
V.dwMajorVersion, V.dwMinorVersion, V.dwBuildNumber, V.wServicePackMajor,
V.wServicePackMinor/*, V.wProductType*/);
} //Get_Version_Str
//*************************************************************
PCHAR WINAPI Get_Exception_Info(PEXCEPTION_POINTERS pException)
//*************************************************************
// Allocate Str[DUMP_SIZE_MAX] and return Str with dump, if !pException - just return call
stack in Str.
{
PCHAR Str;
int Str_Len;
int i;
CHAR Module_Name[MAX_PATH];
PBYTE Module_Addr;
HANDLE hFile;
FILETIME Last_Write_Time;
FILETIME Local_File_Time;
SYSTEMTIME T;
Str = new CHAR[DUMP_SIZE_MAX];
if (!Str)
return NULL;
Str_Len = 0;
Str_Len += Get_Version_Str(Str + Str_Len);
Str_Len += wsprintf(Str + Str_Len, NL "Process: ");
GetModuleFileName(NULL, Str + Str_Len, MAX_PATH);
Str_Len = lstrlen(Str);
// If exception occurred.
if (pException)
{
EXCEPTION_RECORD & E = *pException->ExceptionRecord;
CONTEXT & C = *pException->ContextRecord;
// If module with E.ExceptionAddress found - save its path and date.
if (Get_Module_By_Ret_Addr((PBYTE)E.ExceptionAddress, Module_Name, Module_Addr))
{
Str_Len += wsprintf(Str + Str_Len,
NL "Module: %s", Module_Name);
if ((hFile = CreateFile(Module_Name, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL)) != INVALID_HANDLE_VALUE)
{
if (GetFileTime(hFile, NULL, NULL, &Last_Write_Time))
{
FileTimeToLocalFileTime(&Last_Write_Time, &Local_File_Time);
FileTimeToSystemTime(&Local_File_Time, &T);
Str_Len += wsprintf(Str + Str_Len,
NL "Date Modified: %02d/%02d/%d",
T.wMonth, T.wDay, T.wYear);
}
CloseHandle(hFile);
}
}
else
{
Str_Len += wsprintf(Str + Str_Len,
NL "Exception Addr: %08X", E.ExceptionAddress);
}
Str_Len += wsprintf(Str + Str_Len,
NL "Exception Code: %08X", E.ExceptionCode);
if (E.ExceptionCode == EXCEPTION_ACCESS_VIOLATION)
{
// Access violation type - Write/Read.
Str_Len += wsprintf(Str + Str_Len,
NL "%s Address: %08X",
(E.ExceptionInformation[0]) ? "Write" : "Read", E.ExceptionInformation[1]);
}
// Save instruction that caused exception.
Str_Len += wsprintf(Str + Str_Len, NL "Instruction: ");
for (i = 0; i < 16; i++)
Str_Len += wsprintf(Str + Str_Len, " %02X", PBYTE(E.ExceptionAddress)[i]);
// Save registers at exception.
Str_Len += wsprintf(Str + Str_Len, NL "Registers:");
Str_Len += wsprintf(Str + Str_Len, NL "EAX: %08X EBX: %08X ECX: %08X EDX: %08X",
C.Eax, C.Ebx, C.Ecx, C.Edx);
Str_Len += wsprintf(Str + Str_Len, NL "ESI: %08X EDI: %08X ESP: %08X EBP: %08X",
C.Esi, C.Edi, C.Esp, C.Ebp);
Str_Len += wsprintf(Str + Str_Len, NL "EIP: %08X EFlags: %08X", C.Eip, C.EFlags);
} //if (pException)
// Save call stack info.
Str_Len += wsprintf(Str + Str_Len, NL "Call Stack:");
Get_Call_Stack(pException, Str + Str_Len);
if (Str[0] == NL[0])
lstrcpy(Str, Str + sizeof(NL) - 1);
return Str;
} //Get_Exception_Info
//*************************************************************************************
void WINAPI Create_Dump(PEXCEPTION_POINTERS pException, BOOL File_Flag, BOOL Show_Flag)
//*************************************************************************************
// Create dump.
// pException can be either GetExceptionInformation() or NULL.
// If File_Flag = TRUE - write dump files (.dmz and .dmp) with the name of the current
process.
// If Show_Flag = TRUE - show message with Get_Exception_Info() dump.
{
HANDLE hDump_File;
PCHAR Str;
DWORD Bytes;
DWORD nLen = 0;
CString strDir,strTXTFile,strDMPFile;
CString strDate,strTotal;
CTime tm = CTime::GetCurrentTime();
strDir.Format(_T("%s\\Log"),GetExePath());
strTXTFile.Format(_T("%s\\Log\\%04d-%02d-%02d %02d%02d%02d.txt"),GetExePath
(),tm.GetYear(),tm.GetMonth(),
tm.GetDay(),tm.GetHour(),tm.GetMinute(),tm.GetSecond());
strDMPFile.Format(_T("%s\\Log\\%04d-%02d-%02d %02d%02d%02d.dmp"),GetExePath
(),tm.GetYear(),tm.GetMonth(),
tm.GetDay(),tm.GetHour(),tm.GetMinute(),tm.GetSecond());
if(!PathFileExists(strDir))
CreateDirectory(strDir,NULL);
Str = Get_Exception_Info(pException);
//if (Show_Flag && Str)
// MessageBox(NULL, Str, "MiniDump", MB_ICONHAND | MB_OK);
if (File_Flag)
{
if (Str)
{
hDump_File = CreateFile(strTXTFile,
GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
nLen = lstrlen(Str);
Str[nLen] = '\0';
WriteFile(hDump_File, Str, lstrlen(Str) + 1, &Bytes, NULL);
CloseHandle(hDump_File);
}
// If MiniDumpWriteDump() of DbgHelp.dll available.
if (MiniDumpWriteDump_)
{
MINIDUMP_EXCEPTION_INFORMATION M;
M.ThreadId = GetCurrentThreadId();
M.ExceptionPointers = pException;
M.ClientPointers = 0;
hDump_File = CreateFile(strDMPFile,
GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
MiniDumpWriteDump_(GetCurrentProcess(), GetCurrentProcessId(), hDump_File,
MiniDumpNormal, (pException) ? &M : NULL, NULL, NULL);
CloseHandle(hDump_File);
}
} //if (File_Flag)
delete Str;
} //Create_Dump
具体参考方法如下：
1、在CXXDlg::OnInitDialog()中添加这样一段：
SetUnhandledExceptionFilter(CrashReportEx);
HMODULE hKernel32;
// Try to get MiniDumpWriteDump() address.
hDbgHelp = LoadLibrary("DBGHELP.DLL");
MiniDumpWriteDump_ = (MINIDUMP_WRITE_DUMP)GetProcAddress(hDbgHelp, "MiniDumpWriteDump");
// d("hDbgHelp=%X, MiniDumpWriteDump_=%X", hDbgHelp, MiniDumpWriteDump_);
// Try to get Tool Help library functions.
hKernel32 = GetModuleHandle("KERNEL32");
CreateToolhelp32Snapshot_ = (CREATE_TOOL_HELP32_SNAPSHOT)GetProcAddress(hKernel32,
"CreateToolhelp32Snapshot");
Module32First_ = (MODULE32_FIRST)GetProcAddress(hKernel32, "Module32First");
Module32Next_ = (MODULE32_NEST)GetProcAddress(hKernel32, "Module32Next");
测试代码如下：
class CTestDlg : public CDialog
{
// Construction
public:
CTestDlg(CWnd* pParent = NULL); // standard constructor
void Fun1(char *pszBuffer);
void Fun2(char *pszBuffer);
void Fun3(char *pszBuffer);
};
void CTestDlg::Fun1(char *pszBuffer)
{
Fun2(pszBuffer);
}
void CTestDlg::Fun2(char *pszBuffer)
{
Fun3(pszBuffer);
}
void CTestDlg::Fun3(char *pszBuffer)
{
pszBuffer[1] = 0x00;
}
我们在双击确定按钮时的响应代码如下：
void CTestDlg::OnOK()
{
// TODO: Add extra validation here
Fun1(NULL);
}
2、设置VC编译选项，勾选生成MAP和Debug Info:
3、将编译生成的Release目录中的pdb、map文件保存起来，以后调试会用到：
4、运行程序，单击确定按钮出现异常后自动重启，并创建一个Log文件夹，里面生成dump文件:
5、我们打开WinDbg，设置一下pdb路径(File \ Symbol File Path)：
6、用WiinDbg打开dump文件（File \ Open Crash Dump）
7、输入命令!analyze -v，等待几秒后会打印出错误信息，函数调用栈如下图：
OK ，这样我们就能在发布版本的程序中，准确的定位到哪个函数出了问题，所以发布程序时，一定要记
得生成pdb、map文件，不然客户运行出错的话，你不死也残！
测试工程下载地址：
http://download.csdn.NET/source/3575167
========