下沙论坛

 找回密码
 注册论坛(EC通行证)

用新浪微博连接

一步搞定

QQ登录

QQ登录

下沙大学生网QQ群8(千人群)
群号:6490324 ,验证:下沙大学生网。
用手机发布本地信息严禁群发,各种宣传贴请发表在下沙信息版块有问必答,欢迎提问 提升会员等级,助你宣传
新会员必读 大学生的论坛下沙新生必读下沙币获得方法及使用
查看: 3295|回复: 0
打印 上一主题 下一主题

Windbg核心调试之dump分析

[复制链接]
  • TA的每日心情
    擦汗
    昨天 17:14
  • 签到天数: 2366 天

    [LV.Master]伴坛终老

    跳转到指定楼层
    1
    发表于 2008-11-26 10:52:26 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    文章标题:Windbg核心调试之dump分析
    我的邮箱:Lvg2008@gmail.com
    调试环境:winxp sp2+windbg ver:6.6.0007.5+vmware 5.5.2
    一.Dump文件的产生,意义和类型
        当系统发生错误是,最常见的就是蓝屏(Blue screen),这时就会在系统目录下产生一个Dump文件,如MEMORY.DMP 。这个文件的主要意义在于分析系统错误发生的原因,以作出解决的方法。
       它可分为三种类型:
       1.完全内存转储。这个文件比较大,和物理内存相当,包含了程序崩溃前系统及用户模式下的所有信息。
       2.核心内存转储。这个文件大小约物理内存的三分之一,主要包含崩溃前系统内核的运行情况。一般为了分析内核错误,就选用这种文件。
       3.小内存转储。这个文件小,只有64k,刚好一个页面文件大小。它包含了相对比较少的信息,主要可用于微软的在线分析。
       以上三种形式的文件可以在我的电脑――〉鼠标右键――〉属性――〉高级――〉故障及恢复中设置。如下图:
    0 Y* e. O9 E7 n' q2 s2 l; Q

    /Hacker/UploadFiles_7054/200801/200812151413461.jpg

    9 w- D3 M- ]7 A8 V) i

     

    " [6 g% x2 [* N1 p


    二。Dump文件的强迫产生

    ( f% j5 q) R0 n+ O- D) `; d* }


       由于我们也不知道何时会产生一个系统错误,从而得到dump文件,所以当练习分析时,可认为强迫产生一个。一般有以下两个办法。
       1.双机联调。这里的双机可以是物理上的两台电脑,也可以是用虚拟机模拟。我想这里的大多数人应该选择后者,为啥?还不是money的问题~_^。当用windbg把被调试机联上以后,就可以用.crash命令产生一个蓝屏,当然之前要在被调试机里把dump产生的路径和类型设定好。还有另外一张办法,是通过修改注册表后,用键盘产生dump,但这种方法哪有第一种来的快,所以就不说了,感兴趣的可以查查windbg帮助文档看看。
       2.单机驱动产生。这种方法,不必用双机联调,在本机上就可以办到。由于驱动深入到了内核,它的要求非常苛刻,一个简单的除零操作就可引发蓝屏。但是驱动的编写与普通win32 api是有很大不同的,为了减轻负担,我直接运用一个现成的程序,是《Microsoft Windows Internals》作者写的Notmyfault(见附件)。它由Notmyfault.exe和Myfault.sys两部分组成。正如名字一样,引发蓝屏的不是Notmyfault.exe而是由他加载到内核中的Myfault.sys。如图:

    3 q$ S1 l9 g& y; d

    /Hacker/UploadFiles_7054/200801/200812151413415.jpg

    ) @! r# l! O2 r' q: ?0 A1 ?: B

     
       我在这里两种方法都同时用了,先在虚拟机里执行Notmyfault,接着windbg立刻检测到了系统崩溃,并输出相关信息。 

    ' f* @0 K/ p' d! y% ^1 {


    三。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.

    *******************************************************************************
    *     

    + {( E6 _% ]* Y1 @

    nbsp;   *
    *                        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 aged 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
    //以上几段看名字就知道了,是以上信息的重复没有多大价值。

    2 l& w) L( u0 h# }


    四。总结
        通过以上的分析,知道了蓝屏的原因是Bugcheck D1引起的,是由于驱动程序读操作了过高的IRQL引起的。也知道了这个引发蓝屏的驱动程序是myfault.sys,属于notmyfaulf.exe的进程。还知道了蓝屏前bug程序myfault.sys的调用情况等多个有用信息,接着就可以在myfault.sys源程序中进行bug修改了。           

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏 分享分享 顶 踩 转发到微博

    本版积分规则

    关闭

    下沙大学生网推荐上一条 /1 下一条

    快速回复 返回顶部 返回列表