Register Interrupt Handlers with NDIS 6.0 (Compact 2013)
3/26/2014
NDIS 6.0 drivers do not call the NDIS 5.xNdisMRegisterInterrupt function to register interrupts. Instead, NDIS 6.0 drivers call the NdisMRegisterInterruptEx function and pass it a pointer to the NDIS_MINIPORT_INTERRUPT_CHARACTERISTICS structure. In NDIS 5.x, the miniport driver defines interrupt-related entry point functions in the NDIS_MINIPORT_CHARACTERISTICS structure. NDIS 6.0 drivers, instead, define the entry points for these functions in the NDIS_MINIPORT_INTERRUPT_CHARACTERISTICS structure. To deregister an interrupt, your miniport driver calls the NdisMDeregisterInterruptEx function instead of the NDIS 5.xNdisMDeregisterInterrupt function.
The following table shows which API elements have been renamed and/or changed for NDIS 6.0.
NDIS 5.x |
NDIS 6.0 |
|---|---|
NDIS_MINIPORT_CHARACTERISTICS |
NDIS_MINIPORT_INTERRUPT_CHARACTERISTICS |
NdisMRegisterInterrupt |
NdisMRegisterInterruptEx |
NdisMDeregisterInterrupt |
NdisMDeregisterInterruptEx |
Your NDIS 6.0 miniport driver supplies the following interrupt-related functions:
Function |
Purpose |
|---|---|
MiniportInterrupt |
NDIS calls MiniportInterrupt when a device (such as a network adapter) generates an interrupt. |
MiniportInterruptDPC |
NDIS calls MiniportInterruptDPC to complete the deferred interrupt processing of an interrupt. |
MiniportDisableInterruptEx |
NDIS calls MiniportDisableInterruptsEx to disable interrupts. |
MiniportEnableInterruptEx |
NDIS calls MiniportEnableInterruptsEx to enable interrupts. |
The following code example shows how to initialize NDIS_MINIPORT_INTERRUPT_CHARACTERISTICS and call NdisMRegisterInterruptEx for miniport driver interrupt registration.
Important
For readability, the following code example does not contain security checking or error handling. Do not use the following code in a production environment.
NDIS_MINIPORT_INTERRUPT_CHARACTERISTICS InterruptChar;
// Declare my interrupt functions:
InterruptChar.Header.Type = NDIS_OBJECT_TYPE_MINIPORT_INTERRUPT;
InterruptChar.Header.Revision = NDIS_MINIPORT_INTERRUPT_REVISION_1;
InterruptChar.Header.Size = sizeof(NDIS_MINIPORT_INTERRUPT_CHARACTERISTICS);
InterruptChar.InterruptHandler = MyMiniportInterrupt;
InterruptChar.InterruptDpcHandler = MyMiniportInterruptDPC;
InterruptChar.DisableInterruptHandler = MyMiniportDisableInterruptEx;
InterruptChar.EnableInterruptHandler = MyMiniportEnableInterruptEx;
// Register my interrupt functions and get back an interrupt object:
Status = NdisMRegisterInterruptEx (
pMyAdapter->MiniportAdapterHandle,
pMyAdapter,
&InterruptChar,
&pMyAdapter->InterruptHandle);
In the preceding example, when the call to NdisMRegisterInterruptEx succeeds, it writes the handle for the newly created interrupt object into the InterruptHandle member of pMyAdapter. As shown in this example, the miniport driver passes the adapter context as the interrupt context argument (pMyAdapter, the second parameter to NdisMRegisterInterruptEx). NDIS passes this context information block to other functions that are associated with the interrupt, such as MiniportInterrupt and MiniportInterruptDPC. Therefore, if you use the adapter context as your interrupt context (as shown), your interrupt functions must be written to interpret the passed-in interrupt context as the adapter context block. Typically, in Windows Embedded Compact, NDIS drivers use the adapter context for the interrupt context because there is normally a one-to-one relationship between an interrupt and the interrupting network adapter.
For more information about NDIS interrupt registration, see NDIS Functions for Interrupts.