PCI, PCMIA and ISA hardware uses interrupts to signal the host.
There are two main methods of PCI interrupt handling:

WinDriver supports legacy line-based interrupts, both edge triggered and level sensitive, on all supported operating systems: Windows, Windows CE, and Linux. (For Windows CE, see specific information in section 9.2.8).

WinDriver also supports PCI MSI/MSI-X interrupts (when supported by the hardware) on Linux and Windows Vista and higher (earlier versions of Windows do not support MSI/MSI-X), as detailed in section 9.2.6.

WinDriver provides a single set of APIs for handling both legacy and MSI/MSI-X interrupts, as described in this manual.

This section describes how to use WinDriver to handle interrupts from a user-mode application. Since interrupt handling is a performance-critical task, it is very likely that you may want to handle the interrupts directly in the kernel. WinDriver's Kernel PlugIn [11] enables you to implement kernel-mode interrupt routines. To find out how to handle interrupts from the Kernel PlugIn, please refer to section 11.6.5 of the manual.

The interrupt handling sequence using WinDriver is as follows:

The low-level WD_IntWait WinDriver function (described in the WinDriver PCI Low-Level API Reference), which is used by the high-level interrupt enable functions to wait on interrupts from the device, puts the thread to sleep until an interrupt occurs. There is no CPU consumption while waiting for an interrupt. Once an interrupt occurs, it is first handled by the WinDriver kernel, then WD_IntWait wakes up the interrupt handler thread and returns, as explained above. Since your interrupt handler runs in the user mode, you may call any OS API from this function, including file-handling and GDI functions.

When retrieving resources information for a Plug-and-Play device using WDC_PciGetDeviceInfo [B.3.8] (PCI) or WDC_PcmciaGetDeviceInfo [B.3.9] (PCMCIA), or the low-level WD_PciGetCardInfo or WD_PcmciaGetCardInfo function (described in the WinDriver PCI Low-Level API Reference), the function returns information regarding the interrupt types supported by the hardware. This information is returned within the dwOptions field of the returned interrupt resource (pDeviceInfo->Card.Item[i].I.Int.dwOptions for the WDC functions pPciCard->Card.Item[i].I.Int.dwOptions for the low-level functions). The interrupt options bit-mask can contain a combination of any of the following interrupt type flags:

The WDC_GET_INT_OPTIONS macro returns a WDC device's interrupt options bit-mask [B.4.9]. You can pass the returned bit-mask to the WDC_INT_IS_MSI macro to check whether the bit-mask contains the MSI or MSI-X flags [B.4.10].

	The INTERRUPT_MESSAGE and INTERRUPT_MESSAGE_X flags are applicable only to PCI devices [9.2.6]. The Windows APIs do not distinguish between MSI and MSI-X; therefore, on this OS the WinDriver functions set the INTERRUPT_MESSAGE flag for both MSI and MSI-X. *

When attempting to enable interrupts for a PCI card on Linux or Windows Vista and higher, WinDriver first tries to use MSI-X or MSI, if supported by the card. If this fails, WinDriver attempts to enable legacy level-sensitive interrupts.
WinDriver's interrupt enable functions return information regarding the interrupt type that was enabled for the card. This information is returned within the dwEnabledIntType field of the WD_INTERRUPT structure that was passed to the function. When using the high-level WDC_IntEnable function, the information is stored within the Int field of the WDC device structure referred to by the function's hDev parameter [B.3.46], and can be retrieved using the WDC_GET_ENABLED_INT_TYPE low-level WDC macro [B.4.8].

When handling interrupts you may find the need to perform high-priority tasks at the kernel-mode level immediately when an interrupt occurs. For example, when handling level-sensitive interrupts, such as legacy PCI interrupts [9.2.1], the interrupt line must be lowered (i.e. the interrupt must be acknowledged) in the kernel, otherwise the operating system will repeatedly call WinDriver's kernel interrupt handler, causing the host platform to hang. Acknowledgment of the interrupt is hardware-specific and typically involves writing or reading from specific run-time registers on the device. PCMCIA interrupts also require hardware-specific kernel-mode interrupt handling.

WinDriver's interrupt enable functions receive an optional pointer to an array of WD_TRANSFER structures [B.5.15], which can be used to set up read/write transfer command from/to memory or I/O addresses on the device.
The WDC_IntEnable function [B.3.46] accepts this pointer and the number of commands in the array as direct parameters (pTransCmds and dwNumCmds).
The low-level InterruptEnableand WDC_IntEnable functions receive this information within the Cmd and dwCmds fields of the WD_INTERRUPT structure that is passed to them (see the WinDriver PCI Low-Level API Reference).

When you need to execute performance-critical transfers to/from your device upon receiving an interrupt – e.g. when handling level-sensitive interrupts – you should prepare an array of WD_TRANSFER structures that contain the required information regarding the read/write operations to perform in the kernel upon arrival of an interrupt, and pass this array to WinDriver's interrupt enable functions. As explained in section 9.2.2 (step #3), WinDriver's kernel-mode interrupt handler will execute the transfer commands passed to it within the interrupt enable function for each interrupt that it handles, before returning the control to the user mode. Note: Memory allocated for the transfer commands must remain available until the interrupts are disabled .

9.2.5.1  Interrupt Mask Commands

The interrupt transfer commands array that you pass to WinDriver can also contain an interrupt mask structure, which will be used to verify the source of the interrupt. This is done by setting the transfer structure's cmdTrans field, which defines the type of the transfer command, to CMD_MASK, and setting the relevant mask in the transfer structure's Data field [B.5.15]. Note that interrupt mask commands must be set directly after a read transfer command in the transfer commands array.

When WinDriver's kernel interrupt handler encounters a mask interrupt command, it masks the value that was read from the device in the preceding read transfer command in the array, with the mask set in the interrupt mask command. If the mask is successful, WinDriver will claim control of the interrupt, execute the rest of the transfer commands in the array, and invoke your user-mode interrupt handler routine when the control returns to the user mode. However, if the mask fails, WinDriver will reject control of the interrupt, the rest of the interrupt transfer commands will not be executed, and your user-mode interrupt handler routine will not be invoked. (Note: acceptance and rejection of the interrupt is relevant only when handling legacy interrupts; since MSI/MSI-X interrupts are not shared, WinDriver will always accept control of such interrupts.)

To correctly handle shared PCI interrupts, you must always include a mask command in your interrupt transfer commands array, and set up this mask to check whether the interrupt handler should claim ownership of the interrupt. On Windows CE, in the case of a shared interrupt, WinDriver's interrupt handler will execute the first mask command that is found in the provided interrupt transfer commands array, together with the related read command that precedes it (see information above), before executing any other commands in the array, including commands that precede the mask command. Ownership of the interrupt will be determined according to the result of this mask. If the mask fails, no other transfer commands from the transfer commands array will be executed – including commands that preceded the mask command in the array. If the mask succeeds, WinDriver will proceed to perform any commands that precede the first mask command (and its related read command) in the transfer commands array, and then any commands that follow the mask command in the array. To gain more flexibility and control over the interrupt handling, you can use WinDriver's Kernel PlugIn feature, which enables you to write your own kernel-mode interrupt handler routines, as explained in section 11.6.5 of the manual. Note that Kernel PlugIn is not implemented under Windows CE [11].

WD_TRANSFER trans[3]; /* Array of 3 WinDriver transfer command structures */
BZERO(trans);

/* 1st command: Read a DWORD from the INTCSR I/O port */
trans[0].cmdTrans = RP_DWORD;
/* Set address of IO port to read from: */
trans[0].dwPort = dwAddr; /* Assume dwAddr holds the address of the INTCSR */

/* 2nd command: Mask the interrupt to verify its source */
trans[1].cmdTrans = CMD_MASK;
trans[1].Data.Dword = intrMask; /* Assume intrMask holds your interrupt mask */

/* 3rd command: Write DWORD to the INTCSR I/O port.
   This command will only be executed if the value read from INTCSR in the
   1st command matches the interrupt mask set in the 2nd command. */
trans[2].cmdTrans = WP_DWORD;
/* Set the address of IO port to write to: */
trans[2].dwPort = dwAddr; /* Assume dwAddr holds the address of INTCSR */
/* Set the data to write to the INTCSR IO port: */
trans[2].Data.Dword = 0;

/* Enable the interrupts:
   hDev: WDC_DEVICE_HANDLE received from a previous call to WDC_PciDeviceOpen().
   INTERRUPT_CMD_COPY: Used to save the read data - see WDC_IntEnable().
   interrupt_handler: Your user-mode interrupt handler routine.
   pData: The data to pass to the interrupt handler routine. */
WDC_IntEnable(hDev, &trans, 3, INTERRUPT_CMD_COPY, interrupt_handler, 
    pData, FALSE);

As indicated in section 9.2.1, WinDriver supports PCI Message-Signaled Interrupts (MSI) and Extended Message-Signaled Interrupts (MSI-X) on Linux and Windows Vista and higher (earlier versions of Windows do not support MSI/MSI-X).
The same APIs are used for handling both legacy and MSI/MSI-X interrupts, and these APIs return information regarding interrupt types supported by your hardware [9.2.3] and the interrupt type that was enabled for it [9.2.4].

When using WinDriver on Windows Vista and higher, WinDriver's kernel-mode interrupt handler sets the interrupt message data in the dwLastMessage field of the WD_INTERRUPT structure that was passed to the interrupt enable/wait function. If you pass the same interrupt structure as part of the data to your user-mode interrupt handler routine, as demonstrated in the sample and generated DriverWizard interrupt code, you will be able to access this information from your interrupt handler. When using a Kernel PlugIn driver [11], the last message data is passed to your kerne-mode KP_IntAtIrqlMSI [B.6.10] and KP_IntAtDpcMSI [B.6.11] handlers.
You can use the low-level WDC_GET_ENABLED_INT_LAST_MSG macro to retrieve the last message data for a given WDC device [B.4.11].

9.2.6.1  Windows MSI/MSI-X Device INF Files

	The information in this section is relevant only when working on Windows.

To successfully handle PCI interrupts with WinDriver on Windows, you must first install an INF file that registers your PCI card to work with WinDriver's kernel driver, as explained in section 15.1.

To use MSI/MSI-X on Windows, the card's INF file must contain specific [Install.NT.HW] MSI information, as demonstrated below:

[Install.NT.HW]
AddReg = Install.NT.HW.AddReg

[Install.NT.HW.AddReg]
HKR, "Interrupt Management", 0x00000010
HKR, "Interrupt Management\MessageSignaledInterruptProperties", 0x00000010
HKR, "Interrupt Management\MessageSignaledInterruptProperties", MSISupported, 0x10001, 1

Therefore, to use MSI/MSI-X on Windows Vista and higher with WinDriver – provided your hardware supports MSI/MSI-X – you need to install an appropriate INF file.

When using DriverWizard on Windows Vista and higher to generate an INF file for a PCI device that supports MSI/MSI-X, the INF generation dialogue allows you to select to generate an INF file that supports MSI/MSI-X (see step #3 of the DriverWizard Walkthrough in section 4.2 of the manual).

In addition, the WinDriver Xilinx Virtex 5 BMD sample, which demonstrates MSI handling, includes a sample MSI INF file for this chip – WinDriver/xilinx/virtex5/bmd/~ml555_bmd.inf.

	If your card's INF file does not include MSI/MSI-X information, as detailed above, WinDriver will attempt to handle your card's interrupts using the legacy level-sensitive interrupt handling method, even if your hardware supports MSI/MSI-X.

The sample code below demonstrates how you can use the WDC library's [B.2] interrupt APIs (described in sections B.3.46 – B.3.48 of the manual) to implement a simple user-mode interrupt handler.
For complete interrupt handler source code that uses the WDC interrupt functions, refer, for example, to the WinDriver pci_diag (WinDriver/samples/pci_diag/), pcmcia_diag (WinDriver/samples/pcmcia_diag/), and PLX (WinDriver/plx/) samples and to the generated DriverWizard PCI/PCMCIA/ISA code. For a sample of MSI interrupt handling, using the same APIs, refer to the Xilinx Virtex 5 BMD sample (WinDriver/xilinx/virtex5/bmd/), or to the code generated by DriverWizard for PCI hardware that supports MSI/MSI-X on the supported operating sytsems (Linux or Windows Vista and higher).

The following sample code demonstrates interrupt handling for an edge-triggered ISA card. The code does not set up any kernel-mode interrupt transfer commands [9.2.5], which is accetable in the case of edge-triggered or MSI/MSI-X interrupts [9.2.1]. Note that when using WinDriver to handle level-sensitive or PCMCIA interrupts from the user mode, you must set up transfer commands for acknowledging the interrupt in the kernel, as explained above and as demonstrated in section 9.2.5. As mentioned above [9.2.6], WinDriver provides a single set of APIs for handling both legacy and MSI/MSI-X interrupts. You can therefore also use the following code to handle MSI/MSI-X PCI interrupts (if supported by your hardware), on Linux or Windows Vista and higher, by simply replacing the use of WDC_IsaDeviceOpen in the sample with WDC_PciDeviceOpen [B.3.10].

VOID DLLCALLCONV interrupt_handler (PVOID pData)
{
    PWDC_DEVICE pDev = (PWDC_DEVICE)pData;

    /* Implement your interrupt handler routine here */
    
    printf("Got interrupt %d\n", pDev->Int.dwCounter);
}

...

int main()
{
    DWORD dwStatus;
    WDC_DEVICE_HANDLE hDev;
    ...
    WDC_DriverOpen(WDC_DRV_OPEN_DEFAULT, NULL);
    ...
    hDev = WDC_IsaDeviceOpen(...);
    ...
    /* Enable interrupts. This sample passes the WDC device handle as the data
        for the interrupt handler routine */
    dwStatus = WDC_IntEnable(hDev, NULL, 0, 0,
        interrupt_handler, (PVOID)hDev, FALSE);
    /* WDC_IntEnable() allocates and initializes the required WD_INTERRUPT
        structure, stores it in the WDC_DEVICE structure, then calls 
        InterruptEnable(), which calls WD_IntEnable() and creates an interrupt
        handler thread */
    if (WD_STATUS_SUCCESS != dwStatus)
    {
       printf ("Failed enabling interrupt. Error: 0x%x - %s\n",
           dwStatus, Stat2Str(dwStatus));
    }
    else
    {
        printf("Press Enter to uninstall interrupt\n");
        fgets(line, sizeof(line), stdin);

        WDC_IntDisable(hDev);
        /* WDC_IntDisable() calls InterruptDisable(), which calls WD_IntDisable() */
    }
    ...
    WDC_IsaDeviceClose(hDev);
    ...
    WDC_DriverClose();
}

Windows CE uses a logical interrupt scheme rather than the physical interrupt number. It maintains an internal kernel table that maps the physical IRQ number to the logical IRQ number. Device drivers are expected to use the logical interrupt number when requesting interrupts from Windows CE. In this context, there are three approaches to interrupt mapping: