彻底的方法是在Target上自动运行一个CDB或者NTSD，将其输入输出重定向到KD。 简单的方法是对DbgkMapViewofSection 设置条件断点，比如：  bp DbgkMapViewofSection ''.if($proc=815783f0){} .else{.echo map dll in ;? $proc;gc}''   上面的条件是感兴趣的进程中加载DLL时就中断，否则打印一句话，然后继续

呵呵，是进程范围内的，可是当前进程有很多其它模块啊，其它模块也可能设置顶层过滤函数。事实上，这个关键位置一直是很多程序（杀毒软件、病毒、收集错误，存盘保护等等）争夺的目标，抢手的很......

呵呵，Thomson好眼力，我把问题想复杂了。看来LZ是手工写的URL，为什么不用.symfix命令呢？

先检查一下是否有下面这个目录： d:\symbols\xpsp2core2\ntdll.pdb\99192024C5EB4830AC602195086637082 目录下是否有什么文件？特别是.error的文件。      

已经收到不少朋友的报名，大多数人建议方案A，因此决定使用方案A。没有报名的可以继续报名

尽管可能存在争议，我认为这只是同一个概念的两种不同说法。在Windows世界，大多都是使用working set这个术语，几乎从来不使用resident set。 在Linux中，像ps和top这样的命令，都是使用resident set，不使用working set；有些Linux的文档也有使用working set，怀疑可能是懂Windows的人写的:-)

呵呵，王宇误解了。 PCR里看到的还是已经被KD提升过的，永远是HIGH_LEVEL；LZ想看到的是KD介入前，在要调试的目标函数里时的IRQL。 2K3后，故意加了个字段，来保存IRQL的前一个值。

听起来有点迷惑，如果WinDBG中有调试信息输出，那么就说明已经成功建立调试会话了，还何谓连接不上呢？ 这个问题能重现么？或者举个具体的例子。

这是个老生常谈的问题，对于XP没有什么好办法，对于Server 2003开始的系统，可以使用!irql 命令: kd> !irql 1 Debugger saved IRQL for processor 0x1 -- 0 (LOW_LEVEL)

从错误码来看，是内存的问题