KINTERRUPT

The KINTERRUPT structure (formally _KINTERRUPT) is the supporting data for the kernel’s distribution of a hardware interrupt to device drivers that register for the interrupt’s handling. Each processor has its own Interrupt Descriptor Table (IDT) of addresses to divert execution to. A given interrupt vector can therefore be handled differently on different processors. Drivers do not themselves provide the interrupt handler. They instead provide one or another sort of Interrupt Service Routine (ISR) that the kernel is to call from the true interrupt handler. The ISR and various parameters related to its calling are modelled by the KINTERRUPT. There is at least one KINTERRUPT for each processor that the interrupt is prepared for. That there can be more than one is because the kernel provides that its handler can call multiple ISRs, typically each from a different driver that indicates its willingness to share the interrupt’s handling.

Drivers register their interrupt handling through the I/O Manager’s IoConnectInterrupt function or, more recently, IoConnectInterruptEx. These allow the driver to specify multiple processors for the interrupt. They present the driver with apparently one KINTERRUPT structure but it is in a larger allocation with other data, which can include additional KINTERRUPT structures or at least pointers to them in their separate allocations. This note is not concerned with this larger-scale representation, just with the KINTERRUPT as representing the Core Kernel’s part of one interrupt’s handling for one processor.

Accessibility

On modern versions of Windows, the KINTERRUPT object that governs the handling of an interrupt vector for any one processor is relatively accessible from the processor’s KPRCB. In version 6.3 and higher, the x86 KPRCB has a member named VectorToInterruptObject which is formally an array of 0xD0 pointers to KINTERRUPT objects for the possible hardware interrupts numbered 0x30 to 0xFF. The x64 KPRCB does not have a similar array until version 10.0 and it is inevitably named differently, as InterruptObject. Formally, it is an array of pointers to void, but each pointer is indeed the address of a KINTERRUPT. Less of  a formality is that the x64 array has 0x0100 pointers for the whole range of interrupt vectors 0x00 to 0xFF.

Through much of the history of Windows, however, KINTERRUPT objects were much harder to locate. The only known way, as used for instance by the debugger extension command !idt, depends on knowing that connecting a hardware interrupt diverts the corresponding IDT entry to an interrupt handler that is inside the KINTERUPT object. Yes, even as late as 64-bit Windows 8.1, the KINTERRUPT is not just a data structure but contains executable code. This is more easily presented after the layout, below.

Documentation Status

The KINTERRUPT structure is documented only as an opaque object. Drivers obtain one by calling some such documented function as IoConnectInterrupt. They are then given its address as an argument to their Interrupt Service Routine and they may pass this address to other documented functions such as KeSynchronizeExecution and KeAcquireInterruptSpinLock. They may eventually release their access to the KINTERRUPT by calling some such documented function as IoDisconnectInterrupt. All the while, the KINTERRUPT is something whose existence they know of and which is theirs, in some sense, but it is not for their interpretation.

Variability

As an opaque structure that is allocated to drivers by the kernel, the KINTERRUPT has no compatibility constraints even for its size. The KINTERRUPT is, however, shared with the HAL and so it varies less within versions than do many other structures whose internal detail is undocumented. The following changes of size are known:

Layout

These sizes, and the offsets, types and names in the table that follows, are from type information in public symbol files for the kernel, starting with Windows 2000 SP3. For earlier versions, Microsoft’s names and types are something of a guess from comparing different versions of the binaries. Where use of a member corresponds closely with that of a version for which type information is available in Microsoft’s symbol files, it seems reasonable to infer continuity.

As with other kernel objects, the KINTERRUPT begins with a Type from the KOBJECTS enumeration. For a KINTERRUPT, the Type is specifically InterruptObject. Note that the numerical value of this Type took a few versions to settle on 0x16. The Size is in bytes.

SHORT Type;

SHORT Size;

LIST_ENTRY InterruptListEntry;

KSERVICE_ROUTINE *ServiceRoutine;

KMESSAGE_SERVICE_ROUTINE *MessageServiceRoutine;

ULONG MessageIndex;

PVOID ServiceContext;

KSPIN_LOCK SpinLock;

ULONG Spare1;

ULONG TickCount;

KSPIN_LOCK *ActualLock;

VOID (*DispatchAddress) (VOID);

ULONG Vector;

KIRQL Irql;

KIRQL SynchronizeIrql;

BOOLEAN FloatingSave;

BOOLEAN Connected;

CHAR Number;

ULONG Number;

BOOLEAN  ShareVector;

CHAR Pad [3];

BOOLEAN EmulateActiveBoth;

USHORT ActiveCount;

LONG InternalState;

INT Mode;

KINTERRUPT_MODE Mode;

BOOLEAN ShareVector;

KINTERRUPT_POLARITY Polarity;

ULONG Spare2;

ULONG ServiceCount;

ULONG Spare3;

ULONG DispatchCount;

ULONGLONG Rsvd1;

KEVENT *PassiveEvent;

KTRAP_FRAME *TrapFrame;

PVOID Reserved;

ULONG DispatchCode [DISPATCH_LENGTH];

PVOID DisconnectData;

KTHREAD * volatile ServiceThread;

INTERRUPT_CONNECTION_DATA *ConnectionData;

PVOID IntTrackEntry;

ISRDPCSTATS IsrDpcStats;

INTERRUPT_CONNECTION_DATA *ConnectionData;

PVOID RedirectObject;

UCHAR Padding [8];

PVOID PhysicalDeviceObject;

No use is known of the ServiceCount before version 5.0. The name Spare2 is proposed as fitting the sequence frrom Spare1 to Spare3 that is known from later symbol files.

The DispatchCode truly is code. Initialisation of a KINTERRUPT copies code from a template in the kernel. Connection of the KINTERRUPT sets this copy as the interrupt handler whose address is in the IDT entry. Before the WDK for Windows Vista, the NTDDK.H defines the allowed length of this DispatchCode in dwords as DISPATCH_LENGTH. How or why this slipped into the header is not known—the macro is not referenced from any other header—but had its definition continued to be published, its values would be:

• 106 in versions 3.10 to 5.2 (x86);
• 135 in versions 6.0 to 6.1 (x86);
• 145 in version 6.2 (x86);
• 4 in versions 5.2 to 6.3 (x64).