Share via


Convert Interrupt Handling Functionality to Work with NDIS 6.0 (Compact 2013)

3/26/2014

When a network adapter asserts an interrupt line, NDIS 6.0 calls your miniport driver's MiniportInterrupt function (instead of the NDIS 5.xMiniportISR routine). You return TRUE from MiniportInterrupt if you determine that the interrupt was generated by your miniport adapter. This step is necessary because, in some situations, multiple devices share an interrupt line and multiple drivers must be queried to determine which driver is to process the interrupt.

When MiniportInterrupt runs, it dismisses the interrupt, saves interrupt state information, and defers as much of the I/O processing as possible to the MiniportInterruptDPC function (this is equivalent to the MiniportHandleInterrupt function in NDIS 5.x). When your driver claims the interrupt by returning TRUE from MiniportInterrupt, NDIS calls your MiniportInterruptDPC routine to process the interrupt request.

In Windows Embedded Compact, NDIS drivers handle the QueueDefaultInterruptDpc and TargetProcessors parameters of MiniportInterrupt and MiniportInterruptDPC differently than desktop Windows NDIS miniport drivers. In Windows Embedded Compact, NDIS drivers do not support the TargetProcessors parameter, and the QueueDefaultInterruptDpc parameter only schedules deferred procedure calls (DPCs) on the default (current) processor when set to TRUE. If QueueDefaultInterruptDpc is set to FALSE, NDIS does not schedule a DPC.

For more information about how to handle interrupts in NDIS 6.0, see NDIS Functions for Interrupts.

See Also

Concepts

Modify Miniport Driver Interrupt Functionality for NDIS 6.0