windbg 调试崩溃实例

 

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文件信息 0:008> lm v m test* start end module name 00400000 00526000 test (deferred) Image path: C:\Program Files (x86)\test\test.exe Image name: test.exe Timestamp: Wed Dec 10 17:29:43 2008 (493F8C07) CheckSum: 0012ACC3 ImageSize: 00126000 File version: 2008.12.10.34 Product version: 1.0.1126.34 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0000.04b0 InternalName: test ProductVersion: 1,0,1126,34 FileVersion: 2008,12,10,34 3）加载对应符号pdb，根据Timestamp: Wed Dec 10 17:29:43 2008 (493F8C07)，找到对应的pdb文件，选择file--symble file path 将pdb文件路径加入。 4）分析 0:008> ~*k 看所有线程的堆栈 0 Id: 990.c38 Suspend: 1 Teb: 7efdd000 Unfrozen ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0017d878 75ae81c8 user32!WaitMessage+0x15 0017d8ac 75af478a user32!GetCursorFrameInfo+0x7c 0017d958 75af46f5 user32!SetMessageQueue+0x4e8 0017dab0 75b2d2c3 user32!SetMessageQueue+0x453 0017db0c 75b2d342 user32!MessageBoxTimeoutW+0x52 0017db40 75b2d390 user32!MessageBoxTimeoutA+0x76 0017db60 75b2d3d5 user32!MessageBoxExA+0x1b 0017db7c 718f986e user32!MessageBoxA+0x18 0017dbc0 718f1c2c msvcr80!__crtMessageBoxA+0x1b4 0017dbe4 718f2217 msvcr80!_NMSG_WRITE+0x162 0017dc20 718f2348 msvcr80!__p__winver+0x13c 0017dc30 776dfcc0 msvcr80!_CRTDLL_INIT+0x1d 0017dc50 776e9b28 ntdll!RtlReleasePebLock+0x28 0017dd48 776e95ae ntdll!LdrFindResourceDirectory_U+0x9bf 0017dfcc 777029db ntdll!LdrFindResourceDirectory_U+0x445 0017e250 765e4d50 ntdll!RtlDestroyQueryDebugBuffer+0x48d5 0017e2b4 765e4dca kernel32!LoadLibraryExW+0x112 0017e2c8 004265e9 kernel32!LoadLibraryW+0x11 此处为程序到系统程序的一个临界点。分析首先从这里分析起。 0017e524 00426e43 test!KLoadDllUtility::AutoSearchLoadLibrary+0x5f [e:\kloaddllutility.h @ 32] 0017e554 00426877 test!KPopSupport::InitializeKPopSystem+0x29 [e:\popimport.cpp @ 1037] …………………… 分析线程堆栈，一般情况下，出现messagebox都是不正常的。由于此次崩溃系统有弹出messagebox，而刚好第一个线程堆栈有messagebox相关字眼，所以怀疑是第一个线程堆栈出现问题。 0:008> dd 0017e2c8 dd (dd表示以四个字节的方式查看ebp信息。) 0017e2c8 0017e524 004265e9 0017e314 004d3578 （0017e524表示上一个函数的ebp； 004265e9 表示函数返回地址 0017e314 表示函数的参数 查看msdn，loadlibary只有一个参数，并且参数是一个字符串，所以只有0017e314有效，并且表示一个地址。） 0017e2d8 02724fd8 00000000 00000000 00000000 0017e2e8 00000000 026fc1a8 00000000 00000000 0017e2f8 00000000 00000008 0000000f 00000000 0017e308 00000000 00000000 00000000 003a0063 0017e318 0050005c 006f0072 00720067 006d0061 0017e328 00460020 006c0069 00730065 00280020 0017e338 00380078 00290036 004b005c 006e0069 0:008> db 0017e314 （db以字节的方式查看参数内容) 0017e314 63 00 3a 00 5c 00 50 00-72 00 6f 00 67 00 72 00 c.:.\.P.r.o.g.r. 0017e324 61 00 6d 00 20 00 46 00-69 00 6c 00 65 00 73 00 a.m. .F.i.l.e.s. 0017e334 20 00 28 00 78 00 38 00-36 00 29 00 5c 00 4b 00 .(.x.8.6.).\.e. 0017e344 69 00 6e 00 67 00 73 00-6f 00 66 00 74 00 5c 00 i.r.g.s.o.f.t.\. 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. 0017e364 20 00 49 00 6e 00 74 00-65 00 72 00 6e 00 65 00 .I.n.t.e.r.n.e. 0017e374 74 00 20 00 53 00 65 00-63 00 75 00 72 00 69 00 t. .h.e.c.u.r.i. 0017e384 74 00 79 00 20 00 32 00-30 00 30 00 38 00 5c 00 t.y. .2.0.0.8.\. 0:008> db （db继续显示,使内容显示完全） 0017e394 53 00 43 00 4f 00 4d 00-2e 00 64 00 6c 00 6c 00 S.C.O.M...d.l.l. 0017e3a4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0017e3b4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0017e3c4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0017e3d4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0017e3e4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 0017e3f4 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 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进程内部未设定。