关于分析DUMP文件的一些想法:
在分析一个驱动蓝屏的时候,如果有驱动的PDB文件就很容易找到出错的地方,然是如果没有PDB文件,往往比较麻烦,只能给出个大题的东西,今天调试了一下DUMP文件,有点感触,先来分析一下,(ProbeForWrite(bb,10,10);bb为NULL指针)
双机调试的方法不说了,直接开始调试:加载驱动文件,直接蓝屏了,这个时候WINDBG给出了一下提示:
FOLLOWUP_IP: 
HelloDDK+5ae
f7c455ae 8be5            mov     esp,ebp

BUGCHECK_STR:  0x7E

DEFAULT_BUCKET_ID:  NULL_DEREFERENCE

LAST_CONTROL_TRANSFER:  from f7c455ae to 8060d589

STACK_TEXT:  
f7a01c54 f7c455ae 00000000 0000000a 0000000a nt!ProbeForWrite+0x39
WARNING: Stack unwind information not available. Following frames may be wrong.
f7a01c74 f7c45504 f7a01d4c 805777f1 864d2b10 HelloDDK+0x5ae
f7a01c7c 805777f1 864d2b10 860cd000 00000000 HelloDDK+0x504
f7a01d4c 80577901 800008a8 00000001 00000000 nt!IopLoadDriver+0x66d
f7a01d74 80535c32 800008a8 00000000 865b4020 nt!IopLoadUnloadDriver+0x45
f7a01dac 805c71e0 f7a69cf4 00000000 00000000 nt!ExpWorkerThread+0x100
f7a01ddc 80542e12 80535b32 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  HelloDDK+5ae

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: HelloDDK

IMAGE_NAME:  HelloDDK.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4d60d8a6

STACK_COMMAND:  .cxr 0xfffffffff7a01880 ; kb

FAILURE_BUCKET_ID:  0x7E_HelloDDK+5ae

BUCKET_ID:  0x7E_HelloDDK+5ae

这里我只给出其中的一部分代码。
其中有用的信息大家可以自己分析,今天主要想找找出错位置,看其中的一部分
HelloDDK+5ae
f7c455ae 8be5            mov     esp,ebp

主要看HelloDDK+5ae,也就是出错在加载地址的5ae偏移处。
然后从新打开虚拟机,挂上调试,这个时候先加载驱动,(先别启动驱动,也就是别让你的驱动蓝),然后再WINDBG中BREAK一下,然后下bp          nt!IopLoadDriver+0x66a,这个是SP3的(P2的为bp          nt!IopLoadDriver+0x669),然后再启动驱动,这个时候断下来了,如果所示:

 
然后单布进入(F11)
得到如下图:
 

这个时候就能得到HelloDDK的基址为f7c0d000然后加上5ae得到f7c0d5ae
然后反汇编f7c0d5ae得到

 
看到没有事这个地方或者上面出错了,然后咱往上面看得到

 
这里就能判断出来时这个CALL出问题了,实际上是第三个push 0的问题
在分析一下

 
这里就知道是ProbeForWrite出了问题了,可以用IDA在分析一下,然后用二进制工具改,也可以直接用WINDBG修改
如下eb f7c0d5a0 90 90 90 90 90 90 90 90 90 90 90 90 90 90
然后再反汇编看一下

 
确定好后运行即可
当然,这里是最简单的东西,实际上好多NOP掉了也会出错,不过嘛,往往很多只需要改成JMP 或直接JZ或JNZ就能实现你想要的东西,希望对你有帮助。

  • 标 题:答复
  • 作 者:prince
  • 时 间:2011-02-21 11:04:08

引用:
最初由 无泪城发布 查看帖子
能更加详细一些吗?分析一个未知的驱动,啥都没有,就一个驱动,咋样才能快速找到蓝屏的代码及原因啊?
1. Load symbol
2. kp
咋搞啊?我也感觉我那听繁琐!
蓝屏代码在你用WinDbg加载dump文件的时候,一般就会显示出来,每个蓝屏代码所代表的意义在WinDbg的help文件中会有所介绍。但是并不是这些蓝屏代码就能够直接给出真正的原因。像类似“Bug Check 0xC000021A: STATUS_SYSTEM_PROCESS_TERMINATED”这种蓝屏代码我们一看就知道是什么原因引起的;但是类似像“Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL”这样的蓝屏代码,我们只能够看到蓝屏的直接原因,而为什么memory 或者 system pool会corrupted,还是要具体问题具体分析,很可能这个pool或者memory早就被某个driver给破坏掉了,但是过了N久系统才touch到这个损坏的pool,这种问题,基本除了排除法,没有什么好的办法能够直接找到root cause。

对于lz上面提到的情况,配置好系统symbol之后,直接kp命令就可以看到详细的调用堆栈信息,包括传入的参数,一目了然。

代码:
The k* commands display the stack frame of the given thread, together with related information..


p 
Displays all of the parameters for each function that is called in the stack trace. The parameter list includes each parameter's data type, name, and value. The p option is case sensitive. This parameter requires full symbol information. 

  • 标 题:答复
  • 作 者:无泪城
  • 时 间:2011-02-21 11:43:42

引用:
最初由 prince发布 查看帖子
蓝屏代码在你用WinDbg加载dump文件的时候,一般就会显示出来,每个蓝屏代码所代表的意义在WinDbg的help文件中会有所介绍。但是并不是这些蓝屏代码就能够直接给出真正的原因。像类似“Bug Check 0xC000021A: STATUS_SYSTEM_PROCESS_TERMINATED”...

恩,我这电脑没有双机调试,回去测试一下,顺便问一个问题,蓝屏的时候给出了一系列代码,其中有一项是STACK_TEXT:里面罗列了蓝屏的时候堆栈调用情况,不知道用Kp命令得到的是不是和这个一致?例如:
/////////////////////////
////////////////////////
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