只谈外部中断的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内核情景分析之中断处理(毛德操)。