0x01 APC中断请求级别
在Intel x86体系结构中，外部硬件中断是通过处理器上的"中断管脚"或者一个称为"本地APIC(local APIC)"的内置模块来发生的。本地APIC可以接收的中断源包括:
1处理器管脚(LINT0和LINT1)
2本地APIC定时器(timer)
3性能监视计数器中断
4热传感器中断
5 APIC内部错误中断
APIC这个硬件中断设备是有优先级的，它使用了一个可编程阵列硬件来实现，并且在系统初始化的时候就完成了，Intel x86定义了256个中断向量号(Interrupt Vector Number)，也称为中断向量，从0~255。这就对应了IDT中断描述符表，IDT的表项数目就是256，也就是说，APIC定义的是IDT中的中断例程的优先级
对于一个处理器，它一旦被中断(可能来自内部，可能来自外部，可能是硬中断，可能是软中断)，则某个预设的"中断服务例程"便被执行。而系统软件(操作系统)要做的事情就是，提供这些例程，并将它们设定到处理器的硬件中断向量表(即IDT)中。
然而尽管APIC中断控制器已经提供了中断优先级支持，windows还是自己定义了一套优先级方案，称为"中断请求级别(IRPL Interrupt Request Level)"。在Intel x86系统中，windows使用了0~31来表示优先级，数值越大，优先级越高。内核为软件中断定义了一组标准的IRQL，而HAL则将硬件中断号映射为IRQL。
IRQL的宏定义：
#define PASSIVE_LEVEL 0 //Passive release level(被动级别) #define LOW_LEVEL 0 //Lowest interrupt level #define APC_LEVEL 1 //APC interrupt level #define DISPATCH_LEVEL 2 //Dispatcher level #define PROFILE_LEVEL 27 //Timer used for profiling #define CLOCK1_LEVEL 28 //Interval clock 1 level #define CLOCK2_LEVEL 28 //Interval clock 2 level #define IPI_LEVEL 29 //Interprocessor interrupt level #define POWER_LEVEL 30 //Power failure level #define HIGH_LEVEL 31 //Highest interrupt level
对于IRQL，PASSIVE_LEVEL(被动级别)代表了最低的IRQL，那既然你最低，运行在PASSIVE_LEVEL的线程可以被任何更高的IRQL(从LOW_LEVEL开始都可以)的事情打断，所有的的用户模式代码都运行在PASSIVE_LEVEL(被动模式)上。而APC_LEVEL(APC级别)比PASSIVE_LEVEL高，这也正是在一个线程中插入一个APC可以打断该线程(如果被插入的这个线程正在PASSIVE_LEVEL上运行)的原因（APC注入的原理）。
APC_LEVEL位于PASSIVE_LEVEL和DISPATCH_LEVEL之间，这是"专门"为另一种称为APC(异步过程调用 Asynchronous Procedure Call)的"软件中断"而保留的IRQL。每个APC都是在特定的线程环境中执行的，从而也一定在特定的进程环境中执行。APC是针对线程的，每个线程都有自己特有的APC链表。同一个线程的APC也是被排队执行的(思考线程的IRP对清队列，我们的IO请求要被排队执行，APC作为IRP请求的一种也不例外)。
由于APC的IRQL高于PASSIVE_LEVEL，所以，它优先于普通的"线程代码"。当一个线程获得控制时，它的APC进程会立刻被执行(即执行APC队列中的IRP请求)。这一特性使得APC非常适合于实现各种异步通知事件。例如，I/O完成通知可以用APC来实现。
（详细内容见《windows内核原理与实现》第5章2.6节）
0x02 APC结构
APC是与线程相关的，在描述线程的结构KTHREAD中，可以看到很多带APC字眼的成员。
win7 32: kd> dt _kthread dtx is unsupported for this scenario. It only recognizes dtx [<type>] [<address>] with -a, -h, and -r. Reverting to dt. ntdll!_KTHREAD +0x000 Header : _DISPATCHER_HEADER +0x010 CycleTime : Uint8B +0x018 HighCycleTime : Uint4B +0x020 QuantumTarget : Uint8B +0x028 InitialStack : Ptr32 Void +0x02c StackLimit : Ptr32 Void +0x030 KernelStack : Ptr32 Void +0x034 ThreadLock : Uint4B +0x038 WaitRegister : _KWAIT_STATUS_REGISTER +0x039 Running : UChar +0x03a Alerted : [2] UChar +0x03c KernelStackResident : Pos 0, 1 Bit +0x03c ReadyTransition : Pos 1, 1 Bit +0x03c ProcessReadyQueue : Pos 2, 1 Bit +0x03c WaitNext : Pos 3, 1 Bit +0x03c SystemAffinityActive : Pos 4, 1 Bit +0x03c Alertable : Pos 5, 1 Bit …… +0x040 ApcState : _KAPC_STATE …… +0x168 ApcStatePointer : [2] Ptr32 _KAPC_STATE +0x170 SavedApcState : _KAPC_STATE ……
可以看到在win7的32位下，与kthread偏移为0x40和0x170处，有两个成员：ApcState和SavedApcState，这两个成员指向两个不同的_KAPC_STATE结构：
typedef struct _KAPC_STATE {
LIST_ENTRY ApcListHead[MaximumMode]; //线程的apc链表 只有两个 内核态和用户态
struct _KPROCESS *Process; //当前线程的进程体 PsGetCurrentProcess()
BOOLEAN KernelApcInProgress; //内核APC正在执行
BOOLEAN KernelApcPending; //内核APC正在等待执行
BOOLEAN UserApcPending; //用户APC正在等待执行
} KAPC_STATE, *PKAPC_STATE, *PRKAPC_STATE;
在_KAPC_STATE结构中，第一个成员为ApcListHead[2]，第一个成员指向一个用户模式APC链表，而第二个成员指向内核模式APC链表。如果注意观察，可以看出特殊内核模式APC都排在普通内核模式APC之前。
（图片源自危险漫步：http://www.weixianmanbu.com/article/33.html）
APC结构：
//win7 32
kd> dt _kapc
dtx is unsupported for this scenario. It only recognizes dtx [<type>] [<address>] with -a, -h, and -r. Reverting to dt.
ntdll!_KAPC
+0x000 Type : UChar
+0x001 SpareByte0 : UChar
+0x002 Size : UChar
+0x003 SpareByte1 : UChar
+0x004 SpareLong0 : Uint4B
+0x008 Thread : Ptr64 _KTHREAD
+0x010 ApcListEntry : _LIST_ENTRY
+0x020 KernelRoutine : Ptr64 void
+0x028 RundownRoutine : Ptr64 void
+0x030 NormalRoutine : Ptr64 void
+0x038 NormalContext : Ptr64 Void
+0x040 SystemArgument1 : Ptr64 Void
+0x048 SystemArgument2 : Ptr64 Void
+0x050 ApcStateIndex : Char
+0x051 ApcMode : Char
+0x052 Inserted : UChar
在 KAPC 结 构 中 ， Type 域 应 为 KOBJECTS 枚 举 类 型 的 ApcObJect; Size 域 等 于 KAPC结 构 的 大 小 ； Thread 域 指 向 此 APC 对 象 所 在 的 线 程 KTHREAD 对 象 ； ApcListEntry 域 是APC 对 象 被 加 人 到 线 程 APC 链 表 中 的 节 点 对 象 ； KernelRoutine 域 是 一 个函 数 指 针 ， 该 函数 将 在 内 核 模 式 的 APC-LEVEL 上 被 执 行 ； RundownRoutine 域 也 是 一 个 函 数 指 针 ， 当 一个 线 程 终 止 时 如 果 它 的 APC 链 表 中 还 有 APC 对 象 ， 那 么 ， 若 成 员 非 空 ，则 调 用 它 所 指 的 函 数 。 № rmalRoutine 域 指 向 一 个 在 PASSIVE-LEVEL 上 执 行 的 函 数 。 在
这 三 个 函 数 指 针 成 员 中 ， 只 有 KernelRoutine 是 必 需 的 ， RundownRoutine 和 NormalRoutine都 是 可 选 的 。 而 且 ， 如 果 NormalRoutine 为 空 的 话 ， 则 其 后 的 Norma ℃ ontext 和 ApcMode域 也 将 被 忽 略 ， 本 节 稍 后 会 解 释 这 三 个 域 的 关 系 。 SystemArgumentl 和 SystemArgument2是 两 个 提 供 给 KernelRoutine 或 NormalRoutine 函 数 的 参 数 。 ApcStateIndex 域 说 明 了 APC对 象 的 环 境 状 态 ， 它 是 KAPC ENVIRONMENT 枚 举 类 型 的 成 员 ， 一 旦 APC 对 象 被 插 人到 线 程 的 APC 链 表 中 ， 则 ApcStatelndex 域 指 示 了 它 位 于 线 程 KTHREAD 对 象 的 哪 个 APC链 表 中 。 最 后 ， 布 尔 类 型 Inserted 域 指 示 该 APC 对 象 是 否 已 被 插 人 到 线 程 的 APC 链 表 中。
提炼几点关键：
1.如果mode为UserMode，但是NormalRoutine为NULL，那么实际的模式变为Kernelmode,因为没有用户空间的APC例程可以使用；
2.每种APC都有内核模式的例程；
3.特殊的内核模式APC与普通的内核模式APC区别在于Normalroutine是否为空；
4.当普通的内核模式APC例程被执行时，先执行KernelRoutine例程，再执行NormalRoutine例程（除非执行过KernelRoutine例程后，NormalRoutine例程被清除为NULL）。
APC可以分成三种：用户模式APC、普通的内核模式APC，特殊的内核模式APC
（图片源自危险漫步：http://www.weixianmanbu.com/article/33.html）
