如果是完整的dump，当然可以，会看到被破坏的堆块

要看版本了，Win8之前，可以用InbvXXXInbvEnableDisplayString(TRUE);InbvDisplayString(''Hello NT Boot'');

 0x80000003 是断点异常的代码，通常这是因为触发了模块中的断言或者调试支持代码 （遇到严重意外，主动中断到调试器）从栈回溯看，调用了std::allocator，分配内存，所以怀疑又是“堆腐败”。程序内部某个地方错误使用内存导致堆被破坏，破坏时不知不觉，以后再使用堆时可能就触发问题了

似乎是放在TEB里的COM数据被破坏了，如果需要帮忙，把dump文件压缩一下，发到我的信箱里http://advdbg.org/books/dbgwars/feedback.aspx

多谢分享

转到KiTrap03主要有两种情况，一种是普通的软件断点，另一种是配合所谓的调试服务（Debug Service）（《软件调试》18.6.6） INT 2D可以触发调试服务，转到KiDebugService，KiDebugService内会转到KiTrap03 nt!KiDebugService+0x59:8053dba9 f60550f0dfffff  test    byte ptr ds:[0FFDFF050h],0FFh8053dbb0 0f85eefeffff    jne     nt!Dr_kids_a (8053daa4)8053dbb6 ...

dds的结果暗示，曾经发生过非法访问异常的如果怀疑接口不匹配，那么在宏观层面找线索，比如双方模块的版本号，时间等

ole32!CStdMarshal::CreateStub 是很复杂的一个函数，是可能调用到COM对象的实现模块的因为栈溢出，所以自动的回溯可能遗漏栈帧，用dds esp或者在RPC那个阶段找被调用的对象和方法

可以启用堆的调试支持，如果有《软件调试》的话，看一下第23章

用下面的小程序试了下，正常结束#include ''stdafx.h''#include <iostream> #include <list> using namespace std;int main(int argc, char* argv[]){    std::list<std::string> test;     test.back();  printf(''Hello World!\n''); return 0;}