王宇分析的很透彻。可能是调用PsGetCurrentThread得到的返回值就是NULL。看起来，当前线程是在服务一个LPC请求，需要以LPC客户的身份做些事情，但是在准备扮演（Impersonate）客户线程时出问题了。 建议楼主执行以下下面几个命令，然后把结果贴上来： r dd fs:[0] l100 !handle 00000a50 && 显示LPC句柄，得到LPC端口 !lpc port

首先多谢你的认可和这么高评价。关于学习底层的重要性我们的观点很一致。我们应该重视底层，就像我们要关心我们脚下的大地和地球一样。但是了解底层的好处就好像是懂得了地球是圆的这个道理那样，得到的好处可能不是那么直接。所以大多数做顶层开发的人对《软件调试》不感兴趣，觉得没有用，这是可以理解的，毕竟“速成”/“快餐化”的思想已经广受认可。 但是事实上，一名优秀的软件工程师应该是洞悉全局的，无论他眼下做的是哪个点，他/她始终是有“大局观”的，知道自己的代码是如何与其它模块乃至整个系统的关系和交互方式。心中有这种大局观的人，无论是作出的设计还是写出的代码都是不一样的。 说的具体一点，对于一个很熟悉底层的（做软件的）人来说，做.Net很容易，而且很多底层的技术仍然有用。举个例子来说，使用WinDBG+S ...

Penryn开始就支持，也就是Core 2 Duo开始就支持。参考下面white paper http://download.intel.com/technology/architecture/new-instructions-paper.pdf

窗口还出来是与工作空间有关，把窗口关闭掉，保存一下工作空间就可以了。因为你前面说step over的影响，那一定是因为Source Mode的影响。 凭空估计没什么意义，调试器分析一下很简单。比如下面就是这个命令的执行过程： 0:001> kn # ChildEBP RetAddr 00 00f0cffc 0159be94 kernel32!FormatMessageA 01 00f0d05c 014eac97 ext!FormatAnyStatus+0x284 02 00f0d080 014ead13 ext!DecodeErrorForMessage+0x27 03 00f0d1e4 014eae8f ext!DecodeError+0x33 04 ...

对于问题1，只要关闭源代码模式（回到汇编模式）就可以了。也就是执行一下 l-t 或者在菜单上选择Debug>Source Mode 对于问题2，!gle命令应该是调用FormatMessage API来取得错误信息的，失败的情况可能是调用哪个API时失败了，如果想一探究竟，那么可以用另一个WinDBG附加到失败的这个WinDBG，跟踪一下。

releaseman, 欢迎你！谢谢你把你的想法写出来。欢迎你多参与更多的讨论。

这是因为hiint3!HiInt3.cpp:11两端不是单引号，而是重音符号，也就是键盘上面通常位于数字1左侧那个。 重音符号对程序员来说比较少用，所以挺容易被误解，看来我应该在那个地方加个说明，抱歉。这种写法的规则定义在918页有描述。

赫赫，不敢谈更高的技术高度，需要学习的基础知识还有很多啊： 内存、中断、芯片组、CPU的新技术 另外我对虚拟化技术很感兴趣VT/VMM 大家一起学习吧:-)

从MCA错误码（0000 1PPT RRRR IILL）来看是CPU发起的对内存的读访问出错了（《软件调试》P140） 这与DUMP记录下的发生错误的指令也相符。 cmp dword ptr [edx],0 BSOD的第二个参数f6076050是MCA_EXCEPTION结构，建议观察一下这个地方的数据（dd f6076050）。 不知道这个蓝屏是如何触发的？容易再现么？不妨更换内存条看看是否有影响。

异常应该是0xC0000005吧，访问违例了，看下面的代码，place指针明显没有指向有效的内存就访问它。