海内存知己，天涯若比邻:-) 多谢iiris和其他各位的反馈。是打算找个机会让大家碰面聚一下，一起喝茶聊天......

如果在一个WDM驱动里强行这么写，应该可以转到KiTrap10，不过没有什么驱动会这么做，因为前面说过在保护模式下，KiTrap10是处理浮点错误的（coprocessor error）。

如果不是想写一个通用的工具，只是探索一下某个程序组的执行过程，比如build，那么可以使用设置注册表中的Image File Execution Options选项，当目标进程被创建时，自动启动调试器，比如WinDBG，然后执行.childdbg 1，告诉WinDBG要调试所有子进程，这样每个进程启动的时候，都会先启动WinDBG，执行!peb就可以看到详细的命令行和环境信息等等。 比如当使用VC来构建一个驱动的64位目标时，build的命令行一般为： build -b -w 它会这样启动一个控制台窗口，然后执行nmake： C:\WINDOWS\system32\cmd.exe /c nmake.exe /nologo BUILDMSG=Stop. -i NTTEST= ...

看一下ObQueryNameString的代码（当然是汇编:-)），就可以清楚很多： 805b86de 8b5d08 mov ebx,dword ptr [ebp+8] 把参数1（对象指针）放到寄存器EBX 805b86e1 83c3e8 add ebx,0FFFFFFE8h 减去一个对象偏移，以便指向对象的头部结构OBJECT_HEADER，也就是减去0x18 805b86e4 895dc0 mov dword ptr [ebp-40h],ebx 然后把结果赋给局部变量ebp-40h，这个局部变量现在指向了对象的头部，即OBJECT_HEADER结构 lkd> dt ...

从上面的数据来看，6B040000是堆句柄，其实也就是这个堆的_HEAP结构的起始地址。搜索内存可能找到保存这个堆句柄的变量，但是想不出这有多大意义。如果是普通的C/C++程序，默认使用C/C++运行库来管理堆，应用程序自己的代码用不着直接管理维护堆句柄。 你先说怀疑内存泄漏，后来又不担心内存泄漏，到底是什么问题呢？建议先把问题/目标明确了。

OSR新闻组上Tim Roberts的回答很有意思： If you will permit me to be blunt, so what? Is this affecting your ability to do debugging in any way? -- Tim Roberts, timr@probo.com Providenza & Boekelheide, Inc.

与栈绝对属于某个线程不同，堆（HEAP）通常是进程内全局的，也就是说，一个进程的所有线程都可能使用到某个堆。 你如果想查内存泄漏，那么可以启用堆的UST功能，然后用UMDH工具来比较和分析，参见《软件调试》23.7节，特别是P668～669页。

分两步操作当然可以，但是直接执行dd ebp-10应该也可以呀，只要当时的上下文包含有效的EBP值。比如，下面是随便开始一个用户态调试，然后执行dd ebp-10： 0:000> dd ebp-10 0012fd44 00000000 7ffdb000 0012fedc 0169f746 0012fd54 0012fd7c 5f4396fb 004167c8 00000000 0012fd64 00000000 00000000 0012fedc 0169f746 0012fd74 7ffdb000 00416790 0012fdb8 5f43223f 0012fd84 0012fedc 0169f746 7ffdb000 00416790 0012fd94 ...

这是因为应用程序内部的运行库代码捕捉并处理了这个异常，没有执行到崩溃和JIT调试那一阶段。 如果是带有窗口的MFC程序，那么MFC库的默认窗口函数中有一个TRY{}CATCH()，用户代码没有处理的异常会被这个CATCH捕捉到，参考MFC源代码的WINCORE.CPP中的AfxCallWndProc函数： LRESULT AFXAPI AfxCallWndProc(CWnd* pWnd, HWND hWnd, UINT nMsg, WPARAM wParam = 0, LPARAM lParam = 0){ ...  TRY {#ifndef _AFX_NO_OCC_SUPPORT  // special case for ...

按Ctrl+Alt+D启用内核调试的数据传输信息，然后.reload /user看传递的模块名信息是否对？