dump文件定位程序崩溃代码行

转载自:https://blog.csdn.net/lizheng308/article/details/6866284

1.dump文件

2.程序对应的pdb

步骤一:安装windbg

步骤二:通过windbg打开crash dump文件

步骤三:设置pdb文件路径,即符号表路径

步骤四:运行命令!analyze -v,这是windbg提供的一个自动分析命令,正常情况下,会显示出导致崩溃的行为,其所在文件,以及其在文件中的具体行数

0:254> !analyze -v

..............(一些warnning信息)
FAULTING_IP: 
GDrvStd!memcpy+b6
007642b6 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 007642b6 (GDrvStd!memcpy+0x000000b6)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 2b680000
Attempt to read from address 2b680000

PROCESS_NAME:  IOServer.exe

MODULE_NAME: GDrvStd

FAULTING_MODULE: 7c930000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP:  4cbbd7a5

ERROR_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

READ_ADDRESS:  2b680000

EXCEPTION_DOESNOT_MATCH_CODE:  This indicates a hardware error.
Instruction at 007642b6 does not read/write to 2b680000

FAULTING_THREAD:  00005fe8

BUGCHECK_STR:  APPLICATION_FAULT_CODE_ADDRESS_MISMATCH_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS:  CODE_ADDRESS_MISMATCH

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS

LAST_CONTROL_TRANSFER:  from 00758cd5 to 007642b6

STACK_TEXT:  
2b67f5dc 00758cd5 4c540026 2b67f76a 0e2f122a GDrvStd!memcpy+0xb6//导致崩溃的操作
2b67fd30 0075be78 00000033 4c540020 2b67fe18 GDrvStd!DrvIE::IEReceiveEx+0xc5 [d:\install-disk\macs6.1.5_release\plant_view\ͨÐÅ\´úÂë\macsgateway\drvstd\drvie.cpp @ 633]//定位出导致崩溃的memcpy操作是在drvie.cpp文件的633行
2b67ff2c 00755d3a 00000000 0eeafcd0 0eeafcd0 GDrvStd!DrvIE::ReceiveMessage+0x128 [d:\install-disk\macs6.1.5_release\plant_view\ͨÐÅ\´úÂë\macsgateway\drvstd\drvie.cpp @ 1245]
2b67ff84 00764f23 113fe008 00000000 00000000 GDrvStd!RecvThread+0x1a [d:\install-disk\macs6.1.5_release\plant_view\ͨÐÅ\´úÂë\macsgateway\drvstd\drvie.cpp @ 38]
2b67ffb8 7c824829 0eeafcd0 00000000 00000000 GDrvStd!_beginthread+0xce
WARNING: Stack unwind information not available. Following frames may be wrong.
2b67ffec 00000000 00764ecc 0eeafcd0 00000000 kernel32+0x24829


FOLLOWUP_IP: 
GDrvStd!memcpy+b6
007642b6 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  GDrvStd!memcpy+b6

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  GDrvStd.dll

STACK_COMMAND:  ~254s; .ecxr ; kb

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  CODE_ADDRESS_MISMATCH_c0000005_GDrvStd.dll!base_address

Followup: MachineOwner
---------

步骤五:根据错误代码行,分析可能错误原因,解决之

windbg功能很多,命令很多,上面只是介绍了一般的崩溃简单分析步骤与方法。

注:

windbg常用命令:

!analyze -v

崩溃智能分析,可以简单定位到崩溃代码行

 

!for_each_frame dv /t
通常想查看调用栈上每一个函数的信息,可以用'!for_each_frame dv /t'命令(/t选项要求'dv'显示有用的类型信息)。(当然,我们必须记住,使用优化编译时,在函数的整个生存期中,局部变量有可能会被取消,重注册或被重用来保存其它的数据,因此,可能会导致'dv'命令输出错误的值)。

 

.ecxr

要求调试器把当前的内容切换到保存在故障转储里的异常信息。我们执行这条命令后,将能访问异常抛出时调用栈和局部变量的值。

 

~*kb
打印所有线程的调用栈

 

.cls (Clear Screen)
清屏
--------------------- 
作者:lizheng308 
来源:CSDN 
原文:https://blog.csdn.net/lizheng308/article/details/6866284 
版权声明:本文为博主原创文章,转载请附上博文链接!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
定位崩溃问题是在软件开发和故障排除过程中非常重要的一步。通过分析dump文件可以帮助我们确定崩溃的原因和位置。 首先,dump文件是一个二进制文件,记录了程序崩溃时的内存快照。我们可以通过不同的方式生成dump文件,比如在崩溃发生时自动生成dump文件,或者手动将程序崩溃时的内存状态保存为dump文件。 一旦我们获得了dump文件,可以使用调试工具来分析。常用的调试工具有微软的WinDbg和Visual Studio,这些工具提供了强大的调试功能。 首先,我们需要加载dump文件到调试工具中。然后,通过查看调用堆栈信息,可以确定正在执代码位置。调用堆栈中的最顶层函数常常是导致崩溃的函数。 接下来,我们可以查看异常信息,比如异常代码和异常参数。这些信息可以帮助我们确定崩溃的原因,比如内存访问错误或者空指针异常。 此外,我们还可以查看程序的内存状态。通过查看变量的值、内存地址和内存区域的内容,可以获取更多的信息来定位崩溃问题。 如果我们对代码比较熟悉,可以结合崩溃位置和异常信息来分析代码中的潜在问题。例如,可能存在未经检查的空指针引用、内存泄漏或者不正确的内存操作。 综上所述,通过dump文件定位崩溃是一个非常有价值的过程。通过分析调用堆栈、异常信息和内存状态,我们能够确定崩溃的原因和位置,从而进相应的修复或者改进工作。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值