Neil，问题是线性地址空间不够用，对于32位系统，内核态的线性地址空间只有0x80000000~0xFFFFFFFF这2GB大，无论是从paged pool、non-paged pool分出来的内存都需要占用这2GB的空间，因此PTE表项多了也没有用，因为线性空间就那么多。

记得去年，“调试精灵”曾经有个提议，建议搞个线下的聚会： http://advdbg.com/forums/2078/ShowPost.aspx 这几天，我又想起了这个建议。而且忽然想起，到今年3月份，高端调试网站就成立5年了（创立于2005年3月）。虽然发展很缓慢，但是五年来，这里还是集聚了不少热爱调试技术的朋友，分布在国内外的不同地方，很多朋友在网上经常见，但是网络上的交流始终还是代替不了面对面的聚会。于是一个“5周年聚会”的想法逐步浮现出来，下面是一些初步的想法，拿出来和大家讨论： 1）时间为两天一晚，周五晚上到周日下午； 2）白天主要是主题演讲，晚上是座谈和自由交流； 3）选一个交通发达的旅游城市，比如无锡； 4）会议的目的主要有两个：一是交流技术；二是结识朋友 5）会 ...

下面这行 Free System PTEs: 70121 ( 280484 Kb) 应该如此解释： 系统中还有70121个系统PTE空闲，这些空闲的PTE可以映射70121个内存页，每个内存页按4KB算，也就是70121*4KB=280484KB内存。 并不是说这些PTE要占用280MB的空间，32位下每个PTE占4个字节，这么多PTE如果使用了，那么会占： lkd> ? 0n70121*4 Evaluate expression: 280484 = 000447a4 这么多个字节，也就是200多KB，不到1MB的内存空间

感觉是agcore!CFrameworkElement::SetValue内部调用对象的方法时，方法的地址被意外覆盖成了错误的值，即0x9122086c，这个地址是指向内核态的，不可以从用户态访问，所以触发异常了。 对象方法的地址被覆盖掉的原因可能有多种，比如缓冲区溢出，使用已经释放了对象等。 Google了一下，有人遇到同样的问题： http://stackoverflow.com/questions/1324890/debugging-silverlight-crash 宏观上看，与IE的某些插件有关，可以在IE的Add-on对话框中把不用的插件禁止掉试试看。或者使用即时调试（JIT）...

因为要把所有原稿印出来要1200多页，出这么厚的原版书，大家都觉得没底，所以在出版前做了两轮删除。 大部分删节的内容后来整理成PDF了，可以在以下的页面中下载： http://advdbg.com/blogs/advdbg_system/articles/1815.aspx  

系统资源有很多种，内存资源、IO资源、中断资源，所以先要定位是哪一种。 然后需要判断是应用程序本身报告的，还是操作系统报告的。如果是应用程序本身报告的，那可能是程序本身的逻辑问题，或者“误报”。 如果是应用程序报告的，建议附加调试器到出问题的进程，然后分许。 如果是系统报告的，而且是内存资源不足，那么需要分析内存使用情况，可以先用任务管理器初步分析，找到消耗内存的主要进程。

可以将调试器附加到WORD进程分析，执行~* kv命令观察每个线程的栈回溯，根据对MessageBox函数的调用可以找到发生错误的线程。 这不属于异常，只是C运行库检测到错误，报告出来。

LKD是不可以用r命令的。因为系统中可能有多个CPU，每个CPU的寄存器内容每时每刻都在变化，所以不知道该显示哪个CPU或者哪个上下文中的寄存器内容，显示了也没有太大意义。

这是个商业问题，技术角度来看，太应该一样了。

上面的输出信息表明已经建立起本地内核调试（LKD）会话了。LKD是不支持观察寄存器这样的命令。