搜索论坛 帖子排序:  Oldest to newest Newest to oldest

2009-09-18, 11:24 上午 william 注册: 2009-06-01 发 贴: 14 大家来讨论一下64位程序dump分析的一些问题 相信分析过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也是这种情况。 IP 地址: 已记录   报告

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

2010-04-11, 09:42 上午 jiayiw 注册: 2009-02-16 发 贴: 2 Re: 大家来讨论一下64位程序dump分析的一些问题 对于64位的dump分析，如果是优化过的代码，确实是没有办法从stack上面的到参数，但是有一个编译器选项可以把参数放到Home Space上面去，这样仍然可以从stack上面的到我们需要的参数。 微软最新的程序也开始使用这个选择开始编译，所以，痛苦会越来越少。 另外，如果真的是/Ox 编译的，我们也可以通过ub来获得相应的参数，因为我们知道他的前四个参数肯定是通过rcx,rdx, r8,r9 来传递的。 您上面的stack结果是通过什么得到的？k or dps/dds? IP 地址: 已记录   报告

2010-04-11, 09:48 上午 jiayiw 注册: 2009-02-16 发 贴: 2 Re: 大家来讨论一下64位程序dump分析的一些问题 一篇好文章： http://blogs.msdn.com/ntdebugging/archive/2009/01/09/challenges-of-debugging-optimized-x64-code.aspx IP 地址: 已记录   报告

2010-04-11, 18:31 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 大家来讨论一下64位程序dump分析的一些问题 粗看了一眼确实是好文章，最近正好要移植一个驱动到x64 平台，晚上再仔细阅读一下！ IP 地址: 已记录   报告

2010-04-20, 20:50 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 大家来讨论一下64位程序dump分析的一些问题 已经移植了好几个小玩意到x64平台了，还是挺好玩的，呵呵，现在就等公司把驱动签名买回来了。 IP 地址: 已记录   报告

高端调试 » 软件调试 » C/C++本地代码调试 » Re: 大家来讨论一下64位程序dump分析的一些问题

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- Windows内核调试 |- C/C++本地代码调试 |- .Net程序调试 |- 脚本程序调试 |- Java程序调试 |- Linux内核调试 |- 《程序员》杂志调试专栏 |- WinDbg |- GDB |- 远程调试 |- 调试ACPI和BIOS |- 特殊的调试任务 |- 转储分析 |- GDK7 内核探秘 |- Windows内核 |- Linux内核 系统架构 |- CPU架构 |- PCI/PCI Express架构 程序人生 |- 软件物语 |- 社区活动 |- 名人逸事 联盟论坛 |- 欢迎使用CnForums 没有银弹 |- BUG也精彩 |- 豆腐工程 |- 软件圈里十大怪 Windows Vista |- 用调试利剑剖析VISTA内幕 |- 老专家如何破解新问题 |- 我的电脑谁说了算？ |- 资源 Office开发 |- Visio 驱动程序开发 |- Windows驱动开发 |- Linux驱动开发 |- Windows CE驱动开发 用户态开发 |- Windows本地代码（native）高级开发 |- Web应用开发 |- WinFX和.Net |- Office开发 本站建设 |- 高端调试团队 |- 版面布局 |- 活动建议 |- 网站维护 64位计算 |- 64-bit Windows |- 64-bit CPU 图书 |- 《软件调试》的示例程序 |- 《软件调试》的工具 |- 《软件调试》书友 |- 《软件调试》答疑 |- 《软件调试》勘误和意见 |- 《格蠹汇编》 |- 《软件调试》第二版卷1 |- 《软件调试》第二版卷2 云计算 |- IaaS |- 云存储 |- 大数据 |- PaaS和SaaS GPU |- CUDA |- OpenCL |- HSA |- 游戏开发与调试