从!amli debugger的结果来看，应该是成功与AMLI调试引擎握手了。 手动下载和替换ACPI.pdb是没有必要的，而且可能是导致问题的原因。WinDBG会根据GUID+Age产生路径的打开里面的PDB。 建议删除手工复制的PDB和所在目录，然后设置符号服务器，执行.reload重新下载正确的符号，然后再看是否还有问题。 如果还有问题，那么把当时的命令记录多复制一些过来...

可以使用ETW来监视网络行为，可以用原始的ETW观察工具，也可以用TcpView；也可以使用内核调试来对有关的驱动程序设置断点，然后观察函数调用的情况，看有没有内核对象同步方面的问题......

刚才看了一下这一段的上下文，写的明显有错误。 这一部分写的是栈（stack），这一节的标题是内核态栈。作者想表达的意思是内核态栈对系统内存的影响很大，会占用宝贵的内核态空间。但是表达的不太好，而且不知道为什么会算出2048个线程会用1GB的分页内存空间，360MB的物理内存。两个数字都不对啊。 按每个线程1MB用户态栈算，2048个线程会用2*1024*1MB=2GB；内核态栈即使不考虑分页与否，那么占用的物理内存即使按多算，按16KB（12KB加上PTE/PDE）算，那么只是： 16*210*2*210 = 32*220 = 32 ...

看了下你的代码，当发生用户态异常时，能成功工作的DbgPrint不是在函数的关键路径上，而是在一个分支中，对应的是用户态异常的分支，即下面的else分支中： if(异常来自内核态){   //分发源于内核态的异常   // DbgPrint(''lan \n'');  //如果是内核下发生的异常，调用这句也错}else{   DbgPrint(''lan \n''); //如果是在用户模式下发生的异常，这句会输出没有问题   ...

首先，这个函数的代码是不可以被交换到磁盘上的。你自己的dispatch函数是放在驱动模块里的吧？如果那样，可能是当发生异常时，你的函数不在物理内存中...... 对于调用DbgPrint，不知道你是在哪里做的调用，如果是在异常分发函数中，那么注定有问题的，会导致死循环。因为DbgPrint会调用调试服务，触发异常（《软件调试》18.6.6）....... 楼主对hook这个函数很执着:-)，想达到什么目的呢？

哪本书的P786页？是可以被page out，那句话可能是说没有page out的内核栈所占的物理内存吧

什么版本的Windows和WinDBG?

直接的原因是这个进程的销毁过程完成了一部分，但没有全部完成。根据上面的信息，用户态的部分已经销毁了，所以没办法用户态调试了。但是进程对象和进程结构（_EPROCESS）还在，所以还在进程列表中。 调试的思路，可以用双机内核调试来跟踪销毁进程的过程。《软件调试》第10.8节有关于进程退出的简单介绍...

可以写个GUI的小工具；不然的话，可以用PEView来看一下EXE（看IMAGE_DEBUG_TYPE_CODEVIEW节），用SymView看一下PDB（看Executable的符号），挺直观，不过操作有点多:-)

这种情况一般意味着，这段代码是动态产生的，比如JIT编译产生的或者是某些程序自己分配内存然后放一段代码。 因为这段代码是动态产生的，所以就不属于宿主模块的模块范围，即模块基地址，加上模块的长度。因此，WinDBG就无法找到这个代码所对应的真正模块，只能尽可能找它附近的参照物。对于本例，这条指令离曾经加载过的authz_user模块的基地址比较近，所以就使用这个参照物了。但是这并一定意味着，这段代码与这个模块有关。 [esi+eax*4]是典型索引数组结构的汇编代码，ESI指向数组的基地址，EAX可以是数组的元素序号，4代表这个数据的每个元素是4个字节长，即DWORD这样的整数。