处理设备硬件中断的 Windows 驱动程序框架 (WDF) 驱动程序必须为每个设备可以支持的每个中断创建框架中断对象。 在操作系统的 Windows 8 或更高版本上运行的框架版本 1.11 及更高版本中，Kernel-Mode Driver Framework (KMDF) 和 User-Mode Driver Framework (UMDF) 驱动程序可以创建需要 被动级别处理的 中断对象。 但是，除非在芯片 (SoC) 平台上为系统编写驱动程序，否则驱动程序应使用 DIRQL 中断对象。

驱动程序通常在其 EvtDriverDeviceAdd 回调函数中创建框架中断对象。 驱动程序还可以从其 EvtDevicePrepareHardware 回调函数创建中断对象。

框架在即插即用 (PnP) 管理器将系统资源（如中断向量）分配给设备之前，调用驱动程序的 EvtDriverDeviceAdd 回调函数。 PnP 管理器分配资源后，框架会将中断资源存储在设备的中断对象中。 不支持即插即用 ( 驱动程序无法使用中断对象。)

若要创建框架中断对象，驱动程序必须初始化 WDF_INTERRUPT_CONFIG 结构并将其传递给 WdfInterruptCreate 方法。

UMDF 支持以下类型的中断：

注意 UMDF 不支持 共享 边缘触发的中断。

从 UMDF 版本 2.15 开始，UMDF 支持简单设备的中断，例如硬件按钮（通常由 GPIO 引脚提供支持），而你无法使用硬件寄存器显式启用或禁用这些中断。 若要支持此类设备，UMDF 驱动程序必须使用边缘触发的独占中断。

从 KMDF 版本 1.15 开始，KMDF 还支持此类设备的中断，而无需 处理Active-Both中断 中所述的解决方法。

此外，在 WDF_INTERRUPT_CONFIG 中，驱动程序提供指向以下驱动程序提供的事件回调函数的指针：

EvtInterruptEnable
启用硬件中断。

EvtInterruptDisable
禁用硬件中断。

EvtInterruptIsr
中断服务例程 (中断的 ISR) 。

EvtInterruptDpc
延迟过程调用中断 (DPC) 。

EvtInterruptWorkItem
被动级别中断 的工作项。

对于在 Windows 8 或更高版本的操作系统上使用框架版本 1.11 或更高版本的驱动程序，驱动程序可以将框架中断对象的父级显式设置为框架设备对象或框架队列对象 (DIRQL 或被动) 。 如果驱动程序指定父级，则驱动程序必须将中断对象的 WDF_INTERRUPT_CONFIG 结构的 AutomaticSerialization 成员设置为 TRUE。 (回想一下，如果 AutomaticSerialization 为 TRUE，框架会将中断对象的 EvtInterruptDpc 或 EvtInterruptWorkItem 回调函数的执行与来自中断父对象下的其他对象的回调函数同步)

例如，驱动程序可以将队列指定为中断的父级，以将队列的回调与中断的 EvtInterruptDpc 或 EvtInterruptWorkItem 回调同步。 在此配置中，框架在删除设备对象时会删除队列对象。

调用 WdfInterruptCreate 后，驱动程序可以选择调用 WdfInterruptSetPolicy 或 WdfInterruptSetExtendedPolicy 以指定其他中断参数。 通常，驱动程序从其 EvtDriverDeviceAdd 回调函数调用这些方法。

框架在删除中断的父级之前自动删除中断。 （可选）驱动程序可以调用 WdfObjectDelete 以在更早的时间删除中断。

支持消息信号中断

从 Windows Vista 开始，支持消息信号中断 (MSI) 。 若要使操作系统支持设备的 MSI，驱动程序的 INF 文件必须在注册表中设置一些值。 有关如何设置这些值的信息，请参阅 在注册表中启用Message-Signaled中断 。

驱动程序应为设备可以支持的每个中断向量或 MSI 消息创建框架中断对象。 如果 PnP 管理器未向设备授予设备可以支持的所有中断资源，则不会使用额外的中断对象，并且不会调用其回调函数。

在 Windows 7 中，操作系统不支持每个设备功能超过 910 条中断消息的资源请求。 在 Windows 8 中，操作系统不支持每个设备功能中断超过 2048 次的资源请求。

如果设备驱动程序超出此限制，设备可能无法启动。 若要在包含多个逻辑处理器的计算机中运行，驱动程序不应为每个处理器请求多个中断。

驱动程序必须容忍系统重新均衡中断资源，其中 PnP 管理员从资源要求列表中分配给设备的任何一组备用中断资源。 例如，向设备分配的消息中断次数可能比请求的驱动程序少。 在最坏的情况下，驱动程序必须准备好仅使用一个基于线路的中断来操作设备。