据我所知，如果 IRQL 级别被调度，那么您可以从非分页池访问内存。如果我们将尝试从分页池访问内存。只是想知道为什么？
【问题讨论】：
标签： windows kernel driver ndis wdm
“为什么我们可以在 DISPATCH LEVEL 或以上的非分页池中访问内存”是一个语句，问题是为什么我们不能从分页池 IRQL >= DISPATCH_LEVEL 访问内存？
嗯……
"任何运行在 IRQL APC_LEVEL 以上的例程都可以 既不从分页池中分配内存，也不在分页中访问内存 安全地游泳池。如果以大于 APC_LEVEL 的 IRQL 运行的例程 导致页面错误，这是一个致命错误。”
-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff554368(v=vs.85).aspx
为什么会这样：
假设您的驱动程序正在处理一个中断，并且在处理中断时，它持有一个自旋锁。现在，您想要访问位于分页池中的一些数据结构，并且由于您已经不走运了，该数据位于已被内存管理器分页的页面上。
现在，您的驱动程序必须等到内存管理器分页您的数据。你正在阻塞/等待/睡觉，实际上是你的司机。
现在，又发生了一个中断，但是由于你还在等待数据被调入，你认为现在会发生什么？
知道这个，
" 不必要地长时间持有自旋锁可能会造成伤害 系统范围的性能。”
当您的驱动程序等待某事发生时，您的内核将冻结。
还有，
"请注意，线程在持有自旋锁时可能不会阻塞，因为 这可能会导致死锁。此外，在给定的情况下禁用抢占 持有自旋锁时的处理器。”
无论如何，请进一步阅读：
"以 IRQL > PASSIVE_LEVEL 运行的驱动程序代码应执行为 尽快。例程运行的 IRQL 越高， 更重要的是为了获得良好的整体性能来调整该例程 尽快执行。例如，任何调用 KeRaiseIrql 应尽快对 KeLowerIrql 进行互惠调用 可以的。”
-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff554368(v=vs.85).aspx
页面错误是需要由内存管理器快速处理的异常。虽然您的驱动程序持有自旋锁并持有该处理器作为人质，但该处理器现在已经死了。
MSDN 说：
"当驱动程序持有自旋锁时，它不会导致硬件 异常或引发软件异常而不降低 系统。换句话说，驱动程序的 ISR 和任何 SynchCritSection 驱动程序在调用 KeSynchronizeExecution 时提供的例程 不得导致错误或陷阱，例如页面错误或算术 异常，并且不能引发软件异常。调用的例程 KeAcquireSpinLock 或 KeAcquireInStackQueuedSpinLock 也不能导致 硬件异常或引发软件异常，直到它有 释放了它的执行自旋锁并且不再运行在 IRQL = DISPATCH_LEVEL。”
-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff559854(v=vs.85).aspx
所有这些都回答了将会发生什么，或者可能发生什么。至于回答为什么我们不能在上面或 DISPATCH_LEVEL 上使用分页内存：
我已尝试获取尽可能多的相关信息，如果您仍然没有出售，请尝试阅读自旋锁、可重入函数、中断处理、分页。尝试阅读 Linux、Windows 和 Apple 操作系统的内核。他们都说同样的话，但细节不同。
【讨论】：