只谈外部中断的windows内核管理，异常和trap不在此文的讨论之列。
1. windows中断总貌
在windows中，物理上的中断源被抽象为KINTERRUPT结构。一个中断源在windows中对应一个KINTERRUPT数组，数组的长度为CPU的个数，如果是单核系统，那么这个数组长度为1。先分析KINTERRUPT结果。
windows存储了IDT(Interrupt Descriptor Table)，这张表是一个数组结构，数组的下标是Vector号(此Vector不是PIC/APIC的中断号)，数组元素8字节，该Vector中断的入口地址保存在此8字节中。再分析IDT。
PCI设备是共享中断，windows采用KINTERRUPT链表的方式组织共享中断的设备。结合ReactOS源码，说明中断挂接和中断响应的实现过程。
2. KINTERRUPT结构
用windbg可以直接查看KINTERRUPT结构。
nt!_KINTERRUPT
+0x000
Type :
Int2B
+0x002
Size :
Int2B
+0x004 InterruptListEntry : _LIST_ENTRY //
LIST_ENTRY是通用双向链表节点，共享中断的链表
+0x00c
ServiceRoutine : Ptr32 unsigned
char // 我们的Isr
+0x010
ServiceContext : Ptr32 Void // 暂时不清楚怎么用
+0x014 SpinLock : Uint4B
+0x018 TickCount :
Uint4B
+0x01c
ActualLock : Ptr32 Uint4B
+0x020 DispatchAddress : Ptr32
void
+0x024
Vector :
Uint4B // IDT表的数组下标,0~FF
+0x028
Irql :
UChar
+0x029 SynchronizeIrql : UChar
+0x02a FloatingSave : UChar
+0x02b Connected :
UChar // 已连接到IDT标志
+0x02c
Number :
Char
+0x02d
ShareVector : UChar // 共享中断标志
+0x030
Mode :
_KINTERRUPT_MODE // 本Isr响应中断后,是否由OS继续调用链表的next Isr
+0x034 ServiceCount : Uint4B
+0x038 DispatchCount : Uint4B
+0x03c
DispatchCode : [106] Uint4B //
中断响应代码,IDT中登记的入口地址
_LIST_ENTRY：因为内核经常用到双向链表管理内核对象，windows实现了一个通用的双向链表结构_LIST_ENTRY，类似Linux内核的list_header. KINTERRUPT结构内部保存LIST_ENTRY节点，就可以将共享中断的KINTERRUPT链起来。
DispatchCode：是windows的中断响应模板，在调用Isr之前的hook。IDT登记的入口地址其实是DispatchCode的地址，等于KINTERRUPT地址+0x3C. 图1是windbg查看IDT的内容，例如73号Vector挂在了三个设备，入口地址(8208ddd4) 等于链表头结点KINTERRUPT地址(8208dd98)+0x3C.
图1 windbg查看IDT内容
图2 windbg查看KINTERRUPT实例的内容
3. IDT(Interrupt Descriptor Table)中断描述表
参见文章：IDT系列：（一）初探IDT，Interrupt Descriptor Table，中断描述符表
4. 中断挂接与响应
在毛德操的《Windows内核情景分析》9.6节中，深入ReactOS的源码，剖析windows系统中断管理的内幕。看原文，请看windows内核情景分析之中断处理(毛德操)。