这是由于启用了CPU的PAE功能，参见下面的文章： http://advdbg.org/blogs/advdbg_system/articles/627.aspx

王宇分析的很生动!不过还有值得挖掘的地方，使用dds命令看一下栈，很可能还执行过其它模块的函数：kd> dds espb694cbf0  b694cd64b694cbf4  f7bbd806 hfile+0x806b694cbf8  b694cd18b694cbfc  1743cf2eb694cc00  b694cd64b694cc04  0019e824b694cc08  f7bbd6ed hfile+0x6edb694cc0c  2e576f57b694cc10  00657865b694cc14  00000000b694cc18  ...

对于失败的两种情况是因为模块列表没有更新，先执行一下.reload命令就该可以了

你反汇编内核中的真正的NtReadFile函数了。应该是u ntdll!NtReadFile，而不是u nt!NtReadFile。 lkd> u ntdll!NtReadFilentdll!ZwReadFile:7c90e27c b8b7000000      mov     eax,0B7h7c90e281 ba0003fe7f      mov     edx,offset SharedUserData!SystemCallStub (7ffe0300)7c90e286 ...

这个地方书中还是有些欠妥的，应该写完整，即： lkd> u ntdll!NtReadFile 也就是在本地内核调试会话中执行以上命令。在双机内核调试或者用户态调试会话中也可以。 在初稿中没有u命令，最后一稿中才出现“kd> u ntdll... ”这一行，也许是哪次review时的疏忽，抱歉了，会加到勘误中。

你读的很仔细。是的，正如你在另一个帖子里所提到的，有读者认真读书中的内容时，作者的确很高兴。 指令错位后的后果是千差万别的，与错位指令附近的内存内容密切相关，对于书中的例子，EIP指向的指令“变成了”加法指令，而且引用了内核态的地址，所以就访问违例了。当然在其它情况下，有可能因为错位而形成其它局面，比如错位后的指令还是有效的访问用户态空间的指令，可以顺利执行，但是那样的后果更严重，可能运行到其它位置才执行不下去，也就是看起来“见鬼了”的情况。 但是错位后还恰巧形成一系列有效指令的概率比较低。“见鬼”的情况毕竟少数。 不太理解你的“一口否定了我的‘可能’”这句话，书中没有否定其它可能情况呀？

应该先像Vista那样带内核调试选项启动，然后使用WinDBG就可以本地调试吧

一两年前我就有过这样的想法，甚至设想定在某个旅游景点，大家像“一起过个特殊的几日”一样（^_^）。 2002年在台北搞过一次类似的会议，名字叫Debug Fest，在我的DDK Suite光盘里有4张当年的录像。 国内技术界两极分化严重，高水平的有，因此搞这样的会议还是有可能的。我同意并积极支持！ 初步的想法是“纯组织性活动”，参与人员不必太多（五十人以下），没有商业公司介入（赞助除外），费用由参会者平均负担。讲师方面，除了与会者中的高手外，可以邀请少量公认的高手。 其他人还有愿意参加的么？有什么好主意，说说看。

WinDBG的内部老早就把对32位目标和64位目标的支持集成到了一个版本中（一套代码），因此使用32位的WinDBG完全可以调试64位目标。设置方法与调试32位目标一样。

关于问题1，参考《软件调试》的3.4节《中断/异常优先级》（P72）INT 3的优先级是4，高于NMI和普通外部中断，因此，没有必要关中断。 问题2：TSS（P276）