windbg调试实例（3）

2023-09-11 18:19| 来源: 网络整理| 查看: 265

windbg调试实例（3）——崩溃蓝屏之内核堆栈溢出 1、崩溃发生背景一个系统内核驱动程序运行过程中导致蓝屏。 2、提取dump文件 a) Dump可用前提：崩溃存储为核心内存存储，该项设置在：系统属性–高级–启动和故障恢复–设置–写入调试信息 b) 找到系统windows目录下memory.dmp 3、分析蓝屏原因 1)windbg打开dump 2)!analyze -v 分析挂掉线程的详细情形，错误原因。 [code]01 0: kd> !analyze -v 02 UNEXPECTED_KERNEL_MODE_TRAP (7f) 03 This means a trap occurred in kernel mode, and it's a trap of a kind 04 that the kernel isn't allowed to have/catch (bound trap) or that 05 is always instant death (double fault). The first number in the 06 bugcheck params is the number of the trap (8 = double fault, etc) 07 Consult an Intel x86 family manual to learn more about what these 08 traps are. Here is a *portion* of those codes: 09 If kv shows a taskGate 10 use .tss on the part before the colon, then kv. 11 Else if kv shows a trapframe 12 use .trap on that value 13 Else 14 .trap on the appropriate frame will show where the trap was taken 15 (on x86, this will be the ebp that goes with the procedure KiTrap) 16 Endif 17 kb will then show the corrected stack. 18 Arguments: 19 Arg1: 00000008, EXCEPTION_DOUBLE_FAULT 20 Arg2: 80148000 21 Arg3: 00000000 22 Arg4: 00000000 [/code] UNEXPECTED_KERNEL_MODE_TRAP (7f)表示这个问题发生在内核模式。一个线程的内核栈只有12K大小，在栈的末端有一页无效的页面进行保护。当使用的栈大小超过12K，访问到那个无效页面的时候，处理器就会触发一个页错误，然后试图把寄存器压入栈中，结果造成了第二个页错误。这就是double fault的含义。这里可以猜测这个内核驱动程序访问了12k以外的内存。因为!analyze -v显示的堆栈信息不完全，所以要加个数字比如100 来完全显示，同时用f需要显示栈上每个部分使用了多少字节： [code]01 0: kd> kf 100 02 24 951e5f84 84d7ea91 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x22a 03 4c 951e5fd0 81827ecf fltmgr!FltpCreate+0x2a1 04 18 951e5fe8 8c383125 nt!IofCallDriver+0x63 05 c 951e5ff4 8c385142 Lanman+0x1125 06 aa4 951e6a98 8c384eca Lanman+0x3142 07 20 951e6ab8 8c3839ac Lanman+0x2eca 08 10 951e6ac8 81827ecf Lanman+0x19ac 09 18 951e6ae0 81996f5c nt!IofCallDriver+0x63 10 b8 951e6b98 819eef0d nt!IopParseDevice+0xcff 11 90 951e6c28 819ec6b9 nt!ObpLookupObjectName+0x615 12 60 951e6c88 819839e0 nt!ObOpenObjectByName+0x13c 13 74 951e6cfc 819833ca nt!IopCreateFile+0x5ec 14 5c 951e6d58 84d85516 nt!IoCreateFileEx+0x9d 15 98 951e6df0 84d85891 fltmgr!FltpExpandFilePathWorker+0x162 16 18 951e6e08 84d85ada fltmgr!FltpExpandFilePath+0x19 17 1c 951e6e24 84d86129 fltmgr!FltpGetNormalizedFileNameWorker+0x160 18 18 951e6e3c 84d8351f fltmgr!FltpGetNormalizedFileName+0x19 19 18 951e6e54 84d6eb71 fltmgr!FltpCreateFileNameInformation+0x81 20 20 951e6e74 84d6ecbe fltmgr!HandleStreamListNotSupported+0x125 21 30 951e6ea4 84d6f37c fltmgr!FltpGetFileNameInformation+0xc6 22 28 951e6ecc 8c396a8a fltmgr!FltGetFileNameInformation+0x120 23 3c 951e6f08 84d69843 PROCMON12+0x2a8a 24 5c 951e6f64 84d6bf10 fltmgr!FltpPerformPreCallbacks+0x2e5 25 14 951e6f78 84d7e292 fltmgr!FltpPassThroughInternal+0x32 26 14 951e6f8c 84d7ea7f fltmgr!FltpCreateInternal+0x24 27 44 951e6fd0 81827ecf fltmgr!FltpCreate+0x28f 28 18 951e6fe8 8c383125 nt!IofCallDriver+0x63 29 c 951e6ff4 8c385142 Lanman+0x1125 30 aa4 951e7a98 8c384eca Lanman+0x3142 31 20 951e7ab8 8c3839ac Lanman+0x2eca 32 10 951e7ac8 81827ecf Lanman+0x19ac 33 18 951e7ae0 81996f5c nt!IofCallDriver+0x63 34 b8 951e7b98 819eef0d nt!IopParseDevice+0xcff 35 90 951e7c28 819ec6b9 nt!ObpLookupObjectName+0x615 36 60 951e7c88 819839e0 nt!ObOpenObjectByName+0x13c 37 74 951e7cfc 819900f5 nt!IopCreateFile+0x5ec 38 48 951e7d44 8188c96a nt!NtOpenFile+0x2a 39 0 951e7d44 77020f34 nt!KiFastCallEntry+0x12a 40 0006f7c0 00000000 0x77020f34 [/code] 看一下两处红色标示，使用字节很大并且都来自lanman这个程序，达到5448byte，这就已经接近12k的一半了，所以后面猜测是耗尽、溢出了。再此开发也应该知道问题在哪里了,使用这12k内存不小心,所以开发人员须注意尽量不要在栈上分配超过1K的内存，不能递替调用，但是如果调用太深的话，还是会溢出的，这个就要遇到看怎么解决了.

实例二

1、程序崩溃发生过程这是一个对文件进行处理的模块，而处理模块在处理之前，需查询被处理的文件是否值得处理。这个任务执行过程中发生了崩溃，问题就发生在查询模块。 2、提取dump文件 3、分析dump： 1）启动windbg，file–open crash dump 配置符号库，reload完成。 2）使用命令：.ecxr获得进程崩溃时寄存器的内容 [code]1 0:021> .ecxr (意指恢复崩溃时所有寄存器的内容，包括堆栈等) 2 eax=0532d414 ebx=00000fec ecx=000003fb edx=00000000 esi=0532c428 edi=00000000 3 eip=750f53ea esp=0490f22c ebp=0490f234 iopl=0 nv up ei pl nz na pe nc 4 cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 5 msvcr80!memmove+0x5a: 6 750f53ea f3a5 rep movs dword ptr es:[edi],dword ptr [esi] es:002b:00000000=???????? ds:002b:0532c428=00000000 [/code] 3)使用命令：k 显示堆栈 [code]01 0:021> k (.ecxr不能直接显示堆栈,需使用k显示堆栈) 02 *** Stack trace for last set context - .thread/.cxr resets it 03 ChildEBP RetAddr 04 WARNING: Stack unwind information not available. Following frames may be wrong. 05 0490f234 03ba4806 msvcr80!memmove+0x5a(kxewfsys调用memmove,memmove是个字符串操作函数,能把字符串的一部分复制到另一部分,这里出问题,可能是复制时传递的指针有问题,或者字符串的大小有问题) 06 0490f25c 03ba2547 kxewfsys!__ovfl_get+0xa6 (调用memmove之前内部的一些处理) 07 0490f27c 03ba4a74 kxewfsys!__bt_cmp+0x77 08 0490f2a8 03ba2679 kxewfsys!__bt_search+0x74 09 0490f2c4 03ba1409 kxewfsys!__bt_get+0x49 10 0490f2d8 03ba7448 kxewfsys!IKBDBImpl::Get+0x19 11 0490f2f8 03ba750d kxewfsys!CFdbFileInfo::Search+0x28 [e:\eingsoft_euba\build\build_src\kice\kice_kxewhite\src\kxewfssys\fdbfileinfo.cpp @ 483] 12 0490f338 03ba9c63 kxewfsys!CFdbFileInfo::QueryFileInfo+0x4d [e:\eingsoft_euba\build\build_src\kice\kice_kxewhite\src\kxewfssys\fdbfileinfo.cpp @ 546] 13 0490f380 028210d1 kxewfsys!CFdbManager::QueryFileInfo+0xa3 [e:\eingsoft_euba\build\build_src\kice\kice_kxewhite\src\kxewfssys\fdbmanager.cpp @ 370] （kxewfsys 是处理查询模块） 14 *** ERROR: Symbol file could not be found. Defaulted to export symbols for kspfeng.dll 15 0490f390 03b1323c kxewhite!kxe_white_query_file_info+0x21 [e:\eingsoft_euba\build\build_src\kice\kice_kxewhite\src\kxewfssdk\kxewfs.cpp @ 103] (将文件提交进行查询.) 16 0490f45c 03b13442 kspfeng!KSEGetAddonEntries+0x21fbc （kspfeng.dll是文件处理模块用到的公共功能的封装文件） 17 *** ERROR: Symbol file could not be found. Defaulted to export symbols for ksecore.dll 18 0490f498 03abcaa4 kspfeng!KSEGetAddonEntries+0x221c2 19 0490f4c8 03b07fd5 ksecore+0x1caa4 20 0490f52c 03b1c52b kspfeng!KSEGetAddonEntries+0x16d55 21 0490f860 5019dd7c kspfeng!KSEGetAddonEntries+0x2b2ab 22 0490f864 01c95695 0x5019dd7c 23 0490f868 1a77217c 0x1c95695 24 0490f86c 01c95693 0x1a77217c 25 0490f870 1a7982dc 0x1c95693 26 0490f874 01c95693 0x1a7982dc [/code] 4、总结崩溃原因查询模块，对文件路径的处理存在bug。

实例1

这个系列的文章是vivilisa写的，但是前几天去他的博客看貌似没有这几篇文章了，原来把这系列文章存在

了电脑里，现在拿出来跟大家分享，不知道vivilisa是不是同意。暂时先发表了再说，不成的话就了。感觉他写

的这几篇调试文章很好，称赞下。

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文件信息。 01 0:008> lm v m test* 02 start end module name 03 00400000 00526000 test (deferred) 04 Image path: C:”Program Files (x86)”test”test.exe 05 Image name: test.exe 06 Timestamp: Wed Dec 10 17:29:43 2008 (493F8C07) 07 CheckSum: 0012ACC3 08 ImageSize: 00126000 09 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）分析 01 0:008> ~*k 看所有线程的堆栈 02 0 Id: 990.c38 Suspend: 1 Teb: 7efdd000 Unfrozen 03 ChildEBP RetAddr 04 WARNING: Stack unwind information not available. Following frames may be wrong. 05 0017d878 75ae81c8 user32!WaitMessage+0×15 06 0017d8ac 75af478a user32!GetCursorFrameInfo+0x7c 07 0017d958 75af46f5 user32!SetMessageQueue+0x4e8 08 0017dab0 75b2d2c3 user32!SetMessageQueue+0×453 09 0017db0c 75b2d342 user32!MessageBoxTimeoutW+0×52 10 0017db40 75b2d390 user32!MessageBoxTimeoutA+0×76 11 0017db60 75b2d3d5 user32!MessageBoxExA+0x1b 12 0017db7c 718f986e user32!MessageBoxA+0×18 13 0017dbc0 718f1c2c msvcr80!__crtMessageBoxA+0x1b4 14 0017dbe4 718f2217 msvcr80!_NMSG_WRITE+0×162 15 0017dc20 718f2348 msvcr80!__p__winver+0x13c 16 0017dc30 776dfcc0 msvcr80!_CRTDLL_INIT+0x1d 17 0017dc50 776e9b28 ntdll!RtlReleasePebLock+0×28 18 0017dd48 776e95ae ntdll!LdrFindResourceDirectory_U+0x9bf 19 0017dfcc 777029db ntdll!LdrFindResourceDirectory_U+0×445 20 0017e250 765e4d50 ntdll!RtlDestroyQueryDebugBuffer+0x48d5 21 0017e2b4 765e4dca kernel32!LoadLibraryExW+0×112 22 0017e2c8 004265e9 kernel32!LoadLibraryW+0×11 //此处为程序到系统程序的一个临界点。分析首先从这里分析起。 23 0017e524 00426e43 test!KLoadDllUtility::AutoSearchLoadLibrary+0x5f [e:"kloaddllutility.h @ 32] 24 0017e554 00426877 test!KPopSupport::InitializeKPopSystem+0×29 [e:"popimport.cpp @ 1037] 分析线程堆栈，一般情况下，出现messagebox都是不正常的。由于此次崩溃系统有弹出messagebox，而刚好第一个线程堆栈有messagebox相关字眼，所以怀疑是第一个线程堆栈出现问题。 01 0:008> dd 0017e2c8 dd (dd表示以四个字节的方式查看ebp信息。) 02 0017e2c8 0017e524 004265e9 0017e314 004d3578 （0017e524表示上一个函数的ebp； 004265e9 表示函数返回地址 0017e314 表示函数的参数查看msdn，loadlibary只有一个参数，并且参数是一个字符串，所以只有0017e314有效，并且表示一个地址。） 03 0017e2d8 02724fd8 00000000 00000000 00000000 04 0017e2e8 00000000 026fc1a8 00000000 00000000 05 0017e2f8 00000000 00000008 0000000f 00000000 06 0017e308 00000000 00000000 00000000 003a0063 07 0017e318 0050005c 006f0072 00720067 006d0061 08 0017e328 00460020 006c0069 00730065 00280020 09 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进程内部未设定。

【本文地址】

公司简介

联系我们