DDK中会给出每个内核函数可以运行的IRQL，但这只是要求和期望，如上面的崩溃所示，当时就是在IRQL=2时调用文件I/O，此时文件I/O函数（ZwCreateFile）就是运行在IRQL=2上。所以较真的答案是不一定，都有可能，完全看调用的代码怎么写。 对与另字开始的问题，NT是以时钟中断触发来执行线程/进程调度的，时钟中断的IRQL是28，远远高于DISPATCH_LEVEL，所以只要中断没有被屏蔽，那么CPU还可以响应时钟中断，但是时钟中断处理好后，如果此前在某个线程的上下文中有IRQL违例，还是会继续处理，继续蓝屏，一旦进了蓝屏处理函数KeBugCheck2, KeBugCheck2很快就会关闭中断，拒绝打扰，''专心''蓝屏了... 论坛不是系统学习的地方，建议你找本书认真读下

有道理，这个属于关键细节

可以使用双机内核调试，让内核调试器接收用户态异常，中断到内核调试器后，系统的注销过程也就被搁置了。 如果可以在虚拟机中复现此问题，那么可以用虚拟机+主机通过管道虚拟串口来做内核调试。

Page Fault是CPU异常，与外部中断是有区别的（参见《软件调试》第3章，3.1.3）。从CPU的角度来讲，只要符合Page Fault的条件（比如页无效），就产生Page Fault，不管当时的IRQL，因为异常是不可禁止或屏蔽的。所以理论上，当PageFault的异常处理函数被调用时，当前的IRQL可能是任意值，但出于NT内存管理器的设计原则，要求IRQL低于DISPATCH_LEVEL，否则就视为违例，产生蓝屏。这个要求又进一步演变为当IRQL为DISPATCH_LEVEL或者更高时不能触发Page Fault，又常常表达为不能访问分页内存...

为了节约宝贵的内核空间，通常用下面这样的声明把DriverEntry函数放在特殊的INIT段里： #pragma alloc_text(INIT,DriverEntry) INIT段在驱动初始化后会被丢弃...

<BLOCKQUOTE><table width=''85%''><tr><td class=''txt4''><img src=''/Themes/default/images/icon-quote.gif''> <strong>zyq8709 wrote:</strong></td></tr><tr><td class=''quoteTable''><table width=''100%''><tr><td width=''100%'' valign=''top'' ...

普通方法：回忆最近安装了什么软件，卸载这个/些软件 调试方法：启用Ctrl+ScrollLock强制蓝屏，分析dump文件；当然也可以双机内核调试

举例来说，下面这个崩溃是在DISPATCH_LEVEL调用ZwWriteFile： kd> kn 30 # ChildEBP RetAddr 00 f4373014 804f7bad nt!RtlpBreakWithStatusInstruction 01 f4373060 804f879a nt!KiBugCheckDebugBreak+0x19 02 f4373440 80540693 nt!KeBugCheck2+0x574 03 f4373440 80545769 nt!KiTrap0E+0x233 04 f4373528 80514662 nt!ExAllocatePoolWithTag+0x869 05 f4373548 805192ac ...

这个PDB确实没有包含_LIST_ENTRY结构的符号 如果一定要调试这个版本，那么可以尝试给WINDBG小组写信，或者通过OSR的调试新闻组反馈 或者将内核更新到新的版本...

学一下老外的幽默，东施效颦 :-)