大家来讨论一下64位程序dump分析的一些问题

C/C++本地代码调试

大家来讨论一下64位程序dump分析的一些问题

william 2009-09-18, 11:24 上午
相信分析过AMD x64位dump的人都知道，比起32位来困难多了，首先函数调用的前4个参数，是通过RCX,RDX,R8,R9寄存器传递的，这样很难从栈里把参数恢复过来，不知道各位有什么高招没有。
还有一个问题就是优化后的Release版，用KD或DDS命令看原始栈，可以看到很多已经执行完的函数还在栈里，停留在函数最后一个}这一行，实在是搞不懂为什么会这样。
另外一个问题就是ebp寄存器完全不靠谱，和问win2完全不一样。例如在我的一个dump里就出现了这样的情况。
00000000`1cf06c28 6a96b368 utilDebug!LogAdaptor::AdjustLogIfChanged+0x288 [utildebug\dbg_ns_debug.cpp @ 143]   //143行正是AdjustLogIfChanged（）的最后一个}
00000000`1cf06c2c 00000000
00000000`1cf06c30 6a97cc50 utilDebug!g_LogAdaptor
00000000`1cf06c34 00000000
00000000`1cf06c38 00000000
00000000`1cf06c3c 00000000
00000000`1cf06c40 3e710901
00000000`1cf06c44 00000000
00000000`1cf06c48 6a96b368 utilDebug!LogAdaptor::AdjustLogIfChanged+0x288 [utildebug\dbg_ns_debug.cpp @ 143]
00000000`1cf06c4c 00000000
00000000`1cf06c50 6a97cc50 utilDebug!g_LogAdaptor
00000000`1cf06c54 00000000
00000000`1cf06c58 00000000
00000000`1cf06c5c 00000000
00000000`1cf06c60 6ac6c2b8 cfgSmexSettings!`string'
00000000`1cf06c64 00000000
00000000`1cf06c68 6a96b368 utilDebug!LogAdaptor::AdjustLogIfChanged+0x288 [utildebug\dbg_ns_debug.cpp @ 143]
00000000`1cf06c6c 00000000
00000000`1cf06c70 6a97cc50 utilDebug!g_LogAdaptor
00000000`1cf06c74 00000000
首先这个函数绝对不是递归调用的，按理来说函数调用完成后，应该从栈里清理掉了

用!teb命令，看到栈的信息:
TEB at 000007ffffef0000
    ExceptionList:        0000000000000000
    StackBase:            000000001cf20000
    StackLimit:           000000001cef9000
而ebp的值是
0:015> r ebp
Last set context:
ebp=3e1fad00
0:015> r esp
Last set context:
esp=1cf1f6d8
刚开始怀疑是ebp寄存器的值被破坏了，后来用windbg挂到一个正常执行的程序上去，发现ebp也是这种情况。

Re: 大家来讨论一下64位程序dump分析的一些问题

william 2009-09-18, 23:00 下午
另外发现一个问题，就是在64位多核的机器上，程序多次崩溃在 ofstream和owstringstream的构造函数中，尤其是owstringsteam的构造函数崩溃更是不可思议，就是owstringstream oss这样普通的语句，crash点在msvcp80，不知道是根据windbg dump分析定位有问题还是msvcp80.dll本身真的有问题,不知道有没人碰到过类似的问题。

Re: 大家来讨论一下64位程序dump分析的一些问题

jiayiw 2010-04-11, 09:42 上午
对于64位的dump分析，如果是优化过的代码，确实是没有办法从stack上面的到参数，但是有一个编译器选项可以把参数放到Home Space上面去，这样仍然可以从stack上面的到我们需要的参数。微软最新的程序也开始使用这个选择开始编译，所以，痛苦会越来越少。

另外，如果真的是/Ox 编译的，我们也可以通过ub来获得相应的参数，因为我们知道他的前四个参数肯定是通过rcx,rdx, r8,r9 来传递的。

您上面的stack结果是通过什么得到的？k or dps/dds?

Re: 大家来讨论一下64位程序dump分析的一些问题

jiayiw 2010-04-11, 09:48 上午
一篇好文章：
http://blogs.msdn.com/ntdebugging/archive/2009/01/09/challenges-of-debugging-optimized-x64-code.aspx

Re: 大家来讨论一下64位程序dump分析的一些问题

王宇 2010-04-11, 18:31 下午
粗看了一眼确实是好文章，最近正好要移植一个驱动到x64 平台，晚上再仔细阅读一下！

Re: 大家来讨论一下64位程序dump分析的一些问题

王宇 2010-04-20, 20:50 下午
已经移植了好几个小玩意到x64平台了，还是挺好玩的，呵呵，现在就等公司把驱动签名买回来了。