windbg 调试崩溃实例

转自:http://issf.blog.163.com/blog/static/194129082201002534895/

1、崩溃发生过程

 程序执行过程中,崩溃,弹出mssagebox,提示R6034错误。查看r6034错误:表示运行库的manifest设置不正确,

2、提取dump过程

1)查看任务管理器,崩溃的进程还在。判定可以用Windbg截获dump

2)打开windbg,file--attach to a process,选择崩溃进程如test.exe;

3)使用命令 .dump /mf d:\test.dmp 

4)确认提取成功:查看在d盘根目录下是否有test.dmp文件。

3、分析崩溃原因

1) 打开windbg,file--open crash dump ,打开dump文件test.dmp

2) 查看崩溃文件版本:使用lm v m test*  获得崩溃进程文件test.exe文件信息

 

  1. 0:008> lm v m test*
  2. start    end        module name
  3. 00400000 00526000   test     (deferred)             
  4.     Image path: C:\Program Files (x86)\test\test.exe
  5.     Image name: test.exe
  6.     Timestamp:        Wed Dec 10 17:29:43 2008 (493F8C07)
  7.     CheckSum:         0012ACC3
  8.     ImageSize:        00126000
  9.     File version:     2008.12.10.34
  10.     Product version:  1.0.1126.34
  11.     File flags:       0 (Mask 3F)
  12.     File OS:          40004 NT Win32
  13.     File type:        2.0 Dll
  14.     File date:        00000000.00000000
  15.     Translations:     0000.04b0
  16.     InternalName:     test
  17.     ProductVersion:   1,0,1126,34
  18.     FileVersion:      2008,12,10,34

3)加载对应符号pdb,根据Timestamp: Wed Dec 10 17:29:43 2008 (493F8C07),找到对应的pdb文件,选择file--symble file path 将pdb文件路径加入。

4)分析

 

  1. 0:008> ~*k  看所有线程的堆栈
  2.    0  Id: 990.c38 Suspend: 1 Teb: 7efdd000 Unfrozen
  3. ChildEBP RetAddr  
  4. WARNING: Stack unwind information not available. Following frames may be wrong.
  5. 0017d878 75ae81c8 user32!WaitMessage+0x15
  6. 0017d8ac 75af478a user32!GetCursorFrameInfo+0x7c
  7. 0017d958 75af46f5 user32!SetMessageQueue+0x4e8
  8. 0017dab0 75b2d2c3 user32!SetMessageQueue+0x453
  9. 0017db0c 75b2d342 user32!MessageBoxTimeoutW+0x52
  10. 0017db40 75b2d390 user32!MessageBoxTimeoutA+0x76
  11. 0017db60 75b2d3d5 user32!MessageBoxExA+0x1b
  12. 0017db7c 718f986e user32!MessageBoxA+0x18  
  13. 0017dbc0 718f1c2c msvcr80!__crtMessageBoxA+0x1b4
  14. 0017dbe4 718f2217 msvcr80!_NMSG_WRITE+0x162
  15. 0017dc20 718f2348 msvcr80!__p__winver+0x13c
  16. 0017dc30 776dfcc0 msvcr80!_CRTDLL_INIT+0x1d
  17. 0017dc50 776e9b28 ntdll!RtlReleasePebLock+0x28
  18. 0017dd48 776e95ae ntdll!LdrFindResourceDirectory_U+0x9bf
  19. 0017dfcc 777029db ntdll!LdrFindResourceDirectory_U+0x445
  20. 0017e250 765e4d50 ntdll!RtlDestroyQueryDebugBuffer+0x48d5
  21. 0017e2b4 765e4dca kernel32!LoadLibraryExW+0x112
  22. 0017e2c8 004265e9 kernel32!LoadLibraryW+0x11 此处为程序到系统程序的一个临界点。分析首先从这里分析起
  23. 0017e524 00426e43 test!KLoadDllUtility::AutoSearchLoadLibrary+0x5f [e:\kloaddllutility.h @ 32]
  24. 0017e554 00426877 test!KPopSupport::InitializeKPopSystem+0x29 [e:\popimport.cpp @ 1037]
  25. ……………………

分析线程堆栈,一般情况下,出现messagebox都是不正常的。由于此次崩溃系统有弹出messagebox,而刚好第一个线程堆栈有messagebox相关字眼,所以怀疑是第一个线程堆栈出现问题。

 

  1. 0:008> dd 0017e2c8 dd  (dd表示以四个字节的方式查看ebp信息。)
  2. 0017e2c8  0017e524 004265e9 0017e314 004d3578  (0017e524表示上一个函数的ebp; 004265e9 表示函数返回地址 0017e314 表示函数的参数 查看msdn,loadlibary只有一个参数,并且参数是一个字符串,所以只有0017e314有效,并且表示一个地址。)
  3. 0017e2d8  02724fd8 00000000 00000000 00000000
  4. 0017e2e8  00000000 026fc1a8 00000000 00000000
  5. 0017e2f8  00000000 00000008 0000000f 00000000
  6. 0017e308  00000000 00000000 00000000 003a0063
  7. 0017e318  0050005c 006f0072 00720067 006d0061
  8. 0017e328  00460020 006c0069 00730065 00280020
  9. 0017e338  00380078 00290036 004b005c 006e0069
  10. 0:008> db 0017e314   (db以字节的方式查看参数内容)
  11. 0017e314  63 00 3a 00 5c 00 50 00-72 00 6f 00 67 00 72 00  c.:.\.P.r.o.g.r.
  12. 0017e324  61 00 6d 00 20 00 46 00-69 00 6c 00 65 00 73 00  a.m. .F.i.l.e.s.
  13. 0017e334  20 00 28 00 78 00 38 00-36 00 29 00 5c 00 4b 00   .(.x.8.6.).\.e.
  14. 0017e344  69 00 6e 00 67 00 73 00-6f 00 66 00 74 00 5c 00  i.r.g.s.o.f.t.\.
  15. 0017e354  4b 00 69 00 6e 00 67 00-73 00 6f 00 66 00 74 00  e.i.n.g.s.o.f.t.
  16. 0017e364  20 00 49 00 6e 00 74 00-65 00 72 00 6e 00 65 00   .I.n.t.e.r.n.e.
  17. 0017e374  74 00 20 00 53 00 65 00-63 00 75 00 72 00 69 00  t. .h.e.c.u.r.i.
  18. 0017e384  74 00 79 00 20 00 32 00-30 00 30 00 38 00 5c 00  t.y. .2.0.0.8.\.
  19. 0:008> db (db继续显示,使内容显示完全)
  20. 0017e394  53 00 43 00 4f 00 4d 00-2e 00 64 00 6c 00 6c 00  S.C.O.M...d.l.l.
  21. 0017e3a4  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  22. 0017e3b4  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  23. 0017e3c4  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  24. 0017e3d4  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  25. 0017e3e4  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  26. 0017e3f4  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  27. 0017e404  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ...............

4、分析结果总结

  分析发现 :调用了scom.dll.根据对产品功能的了解,test不会调用该dll,说明调用出错,调错了文件,接下来需要做的是理清test调用流程,修改bug啦。

  至于为啥错误id为r6034,是因为scom.dll需要运行库,而test进程内部未设定。


你可能感兴趣的:(windbg 调试崩溃实例)