来发个帖子吧，不知道算不算bug. http://blog.csdn.net/Viper/archive/2011/02/16/6188045.aspx 或者 http://user.qzone.qq.com/31731705/blog/1297414323

看下当前的栈，也就是idle线程的栈 kd> kvn # ChildEBP RetAddr Args to Child 00 80548f98 baa2a7fa 000000e2 00000000 00000000 nt!KeBugCheckEx+0x1b (FPO: [5,0,0]) 01 80548fb4 baa2a032 00899d40 01ffffc6 00000000 i8042prt!I8xProcessCrashDump+0x237 (FPO: [3,0,0]) 02 80548ffc 80540add 89d6cd98 8a899c88 00010009 ...

为什么现在DPC不空，当前线程还是idle呢？

解决了，详情可见http://user.qzone.qq.com/31731705/blog/1297832731，不知道是我的机器的问题，还是普遍的现象。 哈，没注意到上面有人回了，理论上差不多，实际上有区别的。

仔细看下XP的call stack，有个很奇怪的地方， 0006ff04 77c379c8 00000000 77c37ad9 00000000 kernel32!TerminateProcess (FPO: [Non-Fpo]) 是kernel32!TerminateProcess，而不是kernel32!TerminateProcess+0x??，在什么样的情况下会这样？至少应该有个函数序言啊。 尝试uf一下，还好代码不长，不过引入更多的问题。 0:000> uf kernel32!terminateprocess kernel32!TerminateProcess: 77e616b8 837c240400 cmp dword ptr ...

贴一下我的call stack, xp下面的。 0:000> bl 0 e 77e616b8 0001 (0001) 0:**** kernel32!TerminateProcess 0:000> g eax=00000000 ebx=00000000 ecx=ffffffff edx=00000000 esi=77f7663e edi=00000000 eip=7ffe0304 esp=0006fdf8 ebp=0006fef0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 ...

使用windbg attach一个notepad，然后使用 bp kernel32!terminateprocess，使用bl查看一切OK。 再使用g命令运行notepad，关闭notepad，windbg中显示程序已经关闭，断点没有命中。我在xp上和win7都试过了，感觉这个断点设和没设效果一样，有人碰到过类似的情况嘛？ 0:000> bl 0 e 77e616b8 0001 (0001) 0:**** kernel32!TerminateProcess 0:000> g 关闭notepad直接显示，没有断点命中。 eax=00000000 ebx=00000000 ecx=ffffffff edx=00000000 ...

调试过程中跟踪到kernel32!WaitForMultipleObjects带了2个句柄参数， 0:001> !handle c0 Handle c0 Type Process 0:001> !handle 88 Handle 88 Type Event 有没有办法获得从Process的handle得到Process的名称?

再看了看书，总算有点明白了。UEF中会检测是否显示GPF，如果不显示，则UEF返回EXCEPTION_EXECUTE_HANDLER，通常也就是终止进程。 UEF接下来会显示Error Box，要么用户选择关闭进程，也还是如上面一样，UEF返回EXCEPTION_EXECUTE_HANDLER，终止进程，要么用户就启用了JIT，UEF返回EXCEPTION_CONTINUE_SEARCH，这样才会有调用外层UEF的机会。

第2个关于JIT的问题应该是这样，在第一次的UEF调用中， 如果启用了JIT，则由于NtDebugActiveProcess函数的作用，当前的进程已经成为了一个被调试的进程，所以第2次的UEF调用中检测到当前进程是一个被调试的进程，直接返回了EXCEPTION_CONTINUE_SEARCH，这样也导致了第2轮的异常分发，调试器会首先收到这一异常。 如果没打开JIT，为什么错误对话框只显示一次呢？目前从代码中还看不出处理的逻辑。