我知道，对于硬件中断，当KeAcquireInterruptSpinLock调用KeLowerIrql时，HAL会调整LAPIC中的中断掩码，这将允许自动处理排队的中断（可能在IRR中）。但是，对于软件中断，例如，对SSDT NtXxx系统服务的ntdll.dll sysenter调用，当IRQL进入被动级别时，它们如何被“推迟”并触发，DPC调度程序软件中断也是如此（如果DPC用于中断）。当前的CPU和高优先级的CPU），当IRQL 关于惰性IRQL的问题完全相同： 由于访问PIC的操作相对较慢，因此需要访问I / O总线以更改IRQL的HAL（例如PIC和32位高级配置和电源接口（ACPI）系统）进行了性能优化，称为惰性IRQL，可避免PIC访问。当IRQL升高时，HAL会在内部记录新的IRQL，而不是更改中断掩码。如果随后发生优先级较低的中断，则HAL会将中断屏蔽设置为适合于第一个中断的设置，并且直到IRQL降低（从而使中断挂起），才会停止优先级较低的中断。因此，如果在IRQL升高时没有发生较低优先级的中断，则HAL无需修改PIC。 如何使此中断挂起？它是否只是在条件上循环，直到更高优先级的ISR降低IRQL，并且在调度线程时最终将满足条件？就这么简单吗？ 编辑：我必须在这里有所遗漏，因为假设设备IRQL上的ISR使用IoRequestDpc请求DPC，如果它是高优先级DPC并且目标是当前处理器，则它调度DPC / Dispatch的中断级别以耗尽处理器的DPC队列。这一切都发生在位于设备IRQL（DIRQL）的ISR中，这意味着具有Dispatch / DPC IRQL级别的软件中断将在KeAcquireInterruptSpinLock I think 处旋转，因为当前的IRQL太高，但不会它不会一直在旋转，因为降低ISR的实际例程是在ISR返回之后调用的，这意味着它将在设备IRQL处停留在ISR中，等待需要IRQL 1）ISR将KDPC对象返回给KiInterruptDispatch，以便它知道DPC是什么优先级，然后在 使用KeReleaseInterruptSpinLock降低IRQL之后对其本身进行调度，但是KSERVICE_ROUTINE仅返回无关的布尔值值，因此排除在外。 有人知道如何避免这种情况吗？ 编辑2：也许它产生了一个新线程，该线程阻塞等待IRQL while (irql != passive)