码迷,mamicode.com
首页 > 其他好文 > 详细

如何重建一个损坏的调用堆栈(callstack)

时间:2017-05-02 22:08:17      阅读:624      评论:0      收藏:0      [点我收藏+]

标签:count   ant   can   single   com   文件中   解析   转储   proc   

原文作者:Aaron Ballman
原文时间:2011年07月04日
原文地址:http://blog.aaronballman.com/2011/07/reconstructing-a-corrupted-stack-crawl/

翻译:magictong

时间:2014年05月29日夜

后记:可惜原始的DUMP文件作者并没有上传



        在我的日常工作中。我经常阅读来之微软WinQual(译注:https://sysdev.microsoft.com/ http://en.wikipedia.org/wiki/Winqual)的报告。

这些报告里面一般包括着dump文件(译注:崩溃转储文件,我们一般都是叫dump文件。是一种软件崩溃之后产生的文件,可用于事后调试)。从这些dump文件中面我能够分析出一些经常使用的软件里面究竟出了什么问题,造成它崩溃了。

总而言之。这是一个超赞的系统,我强烈建议各个独立软件开发商(原文:ISV)去上面注冊(尤其是这个系统对不论什么人都是免费的,仅仅要你的可运行文件是正确签名的)。

近期我拿到了一个堆栈已经被严重破坏了的dump文件,我想和大家讨论一下怎么使用Windbg工具来重建它的调用堆栈(callstack)。

        在開始之前,让我们先看看一个原始的调用堆栈是什么样子的。在Windbg里面运行“k”命令就可以。


        0:000> k
        ChildEBP RetAddr  
        028b89cc 77c75350 ntdll!KiFastSystemCallRet
        028b89d0 77c4b208 ntdll!ZwTerminateProcess+0xc
        028b89e0 763e41ec ntdll!RtlExitUserProcess+0x7a
        028b89f4 10056386 kernel32!ExitProcess+0x12
        WARNING: Stack unwind information not available. Following frames may be wrong.
        028b89fc 100565a0 EyeOneIO!I1_SynchronizeWhitebases+0xf0f6
        028b8a0c 10054803 EyeOneIO!I1_SynchronizeWhitebases+0xf310
        00000000 00000000 EyeOneIO!I1_SynchronizeWhitebases+0xd573

        从上面的调用堆栈来看,有几个特征表明这个堆栈已经被破坏了。首先,调用堆栈的基址不可能从0x00000000開始。通常情况下。它从main函数的入口地址開始,或者从一个线程的入口地址開始,可是从上面的调用堆栈来看我们没看看到这个特征。另外,Windbg也发出了“Stack unwind information not available. Following frames may be wrong.”的警告(译注:这句警告的意思就是说。以下的栈帧可能是错误的)。

        第一步。既然堆栈已经错误了。我们当然须要重建当前运行现成的堆栈,并找到当前现成堆栈的起始位置。

这里有个简单的扩展命令能够查看,使用!teb就可以(译注:!teb用于查看当前线程运行环境):

        0:000> !teb
        TEB at 7ffdb000
            ExceptionList:        028b8a28
            StackBase:            028c0000
            StackLimit:           028b6000
            SubSystemTib:         00000000
            FiberData:            00001e00
            ArbitraryUserPointer: 00000000
            Self:                 7ffdb000
            EnvironmentPointer:   00000000
            ClientId:             00000a4c . 00000e3c
            RpcHandle:            00000000
            Tls Storage:          7ffdb02c
            PEB Address:          7ffdf000
            LastErrorValue:       14007
            LastStatusValue:      c0150008
            Count Owned Locks:    0
            HardErrorMode:        0

        看上面!teb命令显示的结果里面,StackBase和StackLimit告诉了我们当前线程的堆栈在内存中的范围,因此我们如今能够转储这个范围内的地址。然后从里面寻找一些有意义和实用的东西(译注:就是把内存地址和相应的符号地址相应起来,然后寻找和当前的线程有关的调用堆栈)。

Windbg里面有个专门的dds命令就是用来做这个事情的,dds命令须要你指定一个起始地址,然后它从给定的起始地址開始转储一定范围内的地址。而且尝试把每一个地址里面的内容和符合(symbol)相应起来(译注:假如能够相应的话)。

dds转储的内容包括三列数据。第一列显示的是顺序递增的地址,第二列是显示地址里面的数据,第三列是符号名称,假设地址里面的数据能够被成功解析为一个符号的话。否则第三列就是显示的空白。

把真实的栈转储出来看看(省略了一些无关项):
(译注:使用命令 dds 028b6000,要显示更后面的内容能够在028b6000的后面加上一个偏移之后再对新地址使用 dds 命令)

        028b6000  00000000
        ...
        028bf9d8  00000000
        028bf9dc  00000000
        028bf9e0  79035b7f
        028bf9e4  028bfa1c
        028bf9e8  6e760b5b i1IO!i1IO::measureOneStrip+0xbb
        028bf9ec  42b840fc
        ...
        028bfa18  00000000
        028bfa1c  028bfd98
        028bfa20  6e763387 i1IO!i1IO::_measureSingleRowScanThreaded+0x1467
        028bfa24  42b840fc
        ...
        028bfd94  00000006
        028bfd98  028bfe2c
        028bfd9c  6e761062 i1IO!i1IO::_advancedMeasureThreaded+0x222
        028bfda0  013a8520
        028bfda4  79035e2e
        ...
        028bfe28  00000000
        028bfe2c  028bfe38
        028bfe30  763ed0e9 kernel32!BaseThreadInitThunk+0xe
        028bfe34  012118e0
        028bfe38  028bfe78
        028bfe3c  77c516c3 ntdll!__RtlUserThreadStart+0x23
        028bfe40  012118e0
        ...
        028bfe74  00000000
        028bfe78  028bfe90
        028bfe7c  77c51696 ntdll!_RtlUserThreadStart+0x1b
        028bfe80  6e760e40 i1IO!i1IO::_advancedMeasureThreaded
        ...
        028c0000  ????????

        实际上转储出来的堆栈比上面列出来的大得多,只是为了简单起见。我仅仅保留一些相关的部分。



        如今要做的第一件事情就是定位到callstack的起始位置。在这个样例里面,RtlUserThreadStart看起来非常像是这个起始位置。由于它是线程的起始调用函数。

在找到起始点之后,获取起始点的前一个堆栈地址A(第一列),然后在堆栈的内容里面(第二列)寻找是否有等于A的堆栈B(向低地址寻找,由于堆栈是向低地址增长的)。然后再在堆栈内容里面寻找是否有等于B的堆栈地址C……,依照这样的方法不停的搜索内存。直到不能再找到不论什么东西或者找到空地址。
        (译注:这个就是利用的标准函数栈帧的基本原理。对此处不理解的能够去了解下标准函数栈帧,一般没有经过FPO优化的调用函数链,能够通过EBP的值在整个堆栈上面串联起来,事实上Windbg自己也是这么找的。而本文讨论的恰恰是由于堆栈被破坏之后。Windbg找不到正确的callstack之后,我们怎么手动恢复的问题)

        在我们这个样例里面,我们从以下的堆栈開始找:

        028bfe78  028bfe90
        028bfe7c  77c51696 ntdll!_RtlUserThreadStart+0x1b

        搜索地址028bfe78,得到以下的堆栈:

        028bfe38  028bfe78
        028bfe3c  77c516c3 ntdll!__RtlUserThreadStart+0x23

        搜索地址028bfe38。得到以下的堆栈:

        028bfe2c  028bfe38
        028bfe30  763ed0e9 kernel32!BaseThreadInitThunk+0xe

        搜索地址028bfe2c,得到以下的堆栈:

        028bfd98  028bfe2c
        028bfd9c  6e761062 i1IO!i1IO::_advancedMeasureThreaded+0x222

        搜索地址028bfd98。得到以下的堆栈:

        028bfa1c  028bfd98
        028bfa20  6e763387 i1IO!i1IO::_measureSingleRowScanThreaded+0x1467

        搜索地址028bfa1c。得到以下的堆栈:

        028bf9e4  028bfa1c
        028bf9e8  6e760b5b i1IO!i1IO::measureOneStrip+0xbb

        如今。继续搜索028bf9e4已经不能再在堆栈里面找到信息了,也就是说我们可能已经找到了终于出问题的函数位置。我们能够使用Windbg尝试修复我们的callstack,当然我们须要给它我们上面找到的这些信息。事实上非常easy。仅仅要上面没找错,我们给 k 命令指明一个确定地址,通过 L 參数传递进去(译注:用上面我们最后找到的028bfa1c),那么Windbg立即就会给我们一个更加友好的callstack信息。

        0:000> k L=028bf9e4
        ChildEBP RetAddr  
        028b89cc 77c75350 ntdll!KiFastSystemCallRet
        028b89d0 77c4b208 ntdll!ZwTerminateProcess+0xc
        028bf9e4 6e760b5b ntdll!RtlExitUserProcess+0x7a
        028bfa1c 6e763387 i1IO!i1IO::measureOneStrip+0xbb
        028bfd98 6e761062 i1IO!i1IO::_measureSingleRowScanThreaded+0x1467
        028bfe2c 763ed0e9 i1IO!i1IO::_advancedMeasureThreaded+0x222
        028bfe38 77c516c3 kernel32!BaseThreadInitThunk+0xe
        028bfe78 77c51696 ntdll!__RtlUserThreadStart+0x23
        028bfe90 00000000 ntdll!_RtlUserThreadStart+0x1b

        如今我们看到的callstack是不是更加完整而且合理了?!没有了调用栈帧错误的警告,而且callstack的调用基址也正常了。

希望上面介绍的这样的方法能给你的调试工作带来一些帮助。


如何重建一个损坏的调用堆栈(callstack)

标签:count   ant   can   single   com   文件中   解析   转储   proc   

原文地址:http://www.cnblogs.com/claireyuancy/p/6798528.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!