異步過程調用(APCs) 是NT異步處理體系結構中的一個基礎部分，理解了它，對于了解NT怎樣操作和執行幾個核心的系統操作很有幫助。

1) APCs允許用戶程序和系統元件在一個進程的地址空間內某個線程的上下文中執行代碼。
2) I/O管理器使用APCs來完成一個線程發起的異步的I/O操作。例如：當一個設備驅動調用IoCompleteRequest來通知I/O管理器，它已經結束處理一個異步I/O請求時，I/O管理器排隊一個apc到發起請求的線程。然后線程在一個較低IRQL級別，來執行APC. APC的作用是從系統空間拷貝I/O操作結果和狀態信息到線程虛擬內存空間的一個緩沖中。
3) 使用APC可以得到或者設置一個線程的上下文和掛起線程的執行。

上面是網上找來的，下面是MSDN上的說明：

An asynchronous procedure call (APC) is a function that executes asynchronously in the context of a particular thread. When an APC is queued to a thread, the system issues a software interrupt. The next time the thread is scheduled, it will run the APC function. An APC generated by the system is called a kernel-mode APC. An APC generated by an application is called a user-mode APC. A thread must be in an alertable state to run a user-mode APC.

Each thread has its own APC queue. An application queues an APC to a thread by calling the QueueUserAPC function. The calling thread specifies the address of an APC function in the call to QueueUserAPC. The queuing of an APC is a request for the thread to call the APC function.

還先看一下那些重要結構：

kd> dt KTHREAD
nt!KTHREAD
+0x000 Header : _DISPATCHER_HEADER
+0x010 MutantListHead : _LIST_ENTRY
+0x018 InitialStack : Ptr32 Void
+0x01c StackLimit : Ptr32 Void
+0x020 KernelStack : Ptr32 Void
+0x024 ThreadLock : Uint4B
+0x028 ApcState : _KAPC_STATE
+0x028 ApcStateFill : [23] UChar
+0x03f ApcQueueable : UChar
+0x040 NextProcessor : UChar
+0x041 DeferredProcessor : UChar
+0x042 AdjustReason : UChar
+0x043 AdjustIncrement : Char
+0x044 ApcQueueLock : Uint4B
+0x048 ContextSwitches : Uint4B
+0x04c State : UChar
+0x04d NpxState : UChar
+0x04e WaitIrql : UChar
+0x04f WaitMode : Char
+0x050 WaitStatus : Int4B
+0x054 WaitBlockList : Ptr32 _KWAIT_BLOCK
+0x054 GateObject : Ptr32 _KGATE
+0x058 Alertable : UChar
+0x059 WaitNext : UChar
+0x05a WaitReason : UChar
+0x05b Priority : Char
+0x05c EnableStackSwap : UChar
+0x05d SwapBusy : UChar
+0x05e Alerted : [2] UChar
+0x060 WaitListEntry : _LIST_ENTRY
+0x060 SwapListEntry : _SINGLE_LIST_ENTRY
+0x068 Queue : Ptr32 _KQUEUE
+0x06c WaitTime : Uint4B
+0x070 KernelApcDisable : Int2B
+0x072 SpecialApcDisable : Int2B
+0x070 CombinedApcDisable : Uint4B
+0x074 Teb : Ptr32 Void
+0x078 Timer : _KTIMER
+0x078 TimerFill : [40] UChar
+0x0a0 AutoAlignment : Pos 0, 1 Bit
+0x0a0 DisableBoost : Pos 1, 1 Bit
+0x0a0 ReservedFlags : Pos 2, 30 Bits
+0x0a0 ThreadFlags : Int4B
+0x0a8 WaitBlock : [4] _KWAIT_BLOCK
+0x0a8 WaitBlockFill0 : [23] UChar
+0x0bf SystemAffinityActive : UChar
+0x0a8 WaitBlockFill1 : [47] UChar
+0x0d7 PreviousMode : Char
+0x0a8 WaitBlockFill2 : [71] UChar
+0x0ef ResourceIndex : UChar
+0x0a8 WaitBlockFill3 : [95] UChar
+0x107 LargeStack : UChar
+0x108 QueueListEntry : _LIST_ENTRY
+0x110 TrapFrame : Ptr32 _KTRAP_FRAME
+0x114 CallbackStack : Ptr32 Void
+0x118 ServiceTable : Ptr32 Void
+0x11c ApcStateIndex : UChar
+0x11d IdealProcessor : UChar
+0x11e Preempted : UChar
+0x11f ProcessReadyQueue : UChar
+0x120 KernelStackResident : UChar
+0x121 BasePriority : Char
+0x122 PriorityDecrement : Char
+0x123 Saturation : Char
+0x124 UserAffinity : Uint4B
+0x128 Process : Ptr32 _KPROCESS
+0x12c Affinity : Uint4B
+0x130 ApcStatePointer : [2] Ptr32 _KAPC_STATE
+0x138 SavedApcState : _KAPC_STATE
+0x138 SavedApcStateFill : [23] UChar
+0x14f FreezeCount : Char
+0x150 SuspendCount : Char
+0x151 UserIdealProcessor : UChar
+0x152 CalloutActive : UChar
+0x153 Iopl : UChar
+0x154 Win32Thread : Ptr32 Void
+0x158 StackBase : Ptr32 Void
+0x15c SuspendApc : _KAPC
+0x15c SuspendApcFill0 : [1] UChar
…………

…………

上面紅色部分是APC機制用到的幾個字段！！

kd> dt _KAPC_STATE
nt!_KAPC_STATE
+0x000 ApcListHead : [2] _LIST_ENTRY，每個指針指向_KAPC結構
+0x010 Process : Ptr32 _KPROCESS
+0x014 KernelApcInProgress : UChar
+0x015 KernelApcPending : UChar
+0x016 UserApcPending : UChar

顯然，這里的 ApcListHead 就是 APC 隊列頭。不過這是個大小為 2 的數組，說明實際
上(每個線程)有兩個 APC 隊列。這是因為 APC 函數分為用戶 APC 和內核 APC 兩種，各有
各的隊列。所謂用戶 APC，是指相應的 APC 函數位于用戶空間、在用戶空間執行；而內核
APC，則相應的 APC 函數為內核函數。

SavedApcState也是個_KAPC_STATE結構，當當前程暫時“掛靠(Attach)”到另一個進程的地址空間的時侯，ApcState就拷貝到SavedApcState暫時存放！

當然，還要有狀態信息說明本線程當前是處于“原始環境”還是“掛靠環境”，這就是 ApcStateIndex 的作用，代碼中為 ApcStateIndex的值定義了一種枚舉類型：

typedef enum _KAPC_ENVIRONMENT {
OriginalApcEnvironment,
AttachedApcEnvironment,
CurrentApcEnvironment,
InsertApcEnvironment
} KAPC_ENVIRONMENT;

實際可用于 ApcStateIndex 的只是 OriginalApcEnvironment和 AttachedApcEnvironment。

KAPC_STATE 指針數組 ApcStatePointer[2]，就用ApcStateIndex 的當前值作為下標，而數組中的指針則根據情況可以分別指向兩個APC_STATE 數據結構中的一個。

kd> dt _KAPC ;APC對象
nt!_KAPC
+0x000 Type : UChar
+0x001 SpareByte0 : UChar
+0x002 Size : UChar
+0x003 SpareByte1 : UChar
+0x004 SpareLong0 : Uint4B
+0x008 Thread : Ptr32 _KTHREAD
+0x00c ApcListEntry : _LIST_ENTRY
+0x014 KernelRoutine : Ptr32 void
+0x018 RundownRoutine : Ptr32 void
+0x01c NormalRoutine : Ptr32 void
+0x020 NormalContext : Ptr32 Void
+0x024 SystemArgument1 : Ptr32 Void
+0x028 SystemArgument2 : Ptr32 Void
+0x02c ApcStateIndex : Char
+0x02d ApcMode : Char
+0x02e Inserted : UChar

KernelRoutine、RundownRoutine、NormalRoutine。其中只有 NormalRoutine才指向(執行)APC 函數的請求者所提供的函數，其余兩個都是輔助性的！

NTKERNELAPI
VOID
KeInitializeApc (
__out PRKAPC Apc,
__in PRKTHREAD Thread,
__in KAPC_ENVIRONMENT Environment,
__in PKKERNEL_ROUTINE KernelRoutine,
__in_opt PKRUNDOWN_ROUTINE RundownRoutine,
__in_opt PKNORMAL_ROUTINE NormalRoutine,
__in_opt KPROCESSOR_MODE ProcessorMode,
__in_opt PVOID NormalContext
);

這個函數主要用來初始化Apc（_KAPC）這個結構的，如果Environment==CurrentApcEnvironment,Apc->ApcStateIndex就由KTHREAD中的ApcStateIndex決定，但Environment不能大于KTHREAD中的ApcStateIndex！

最后，APC 請求的模式ProcessorMode，但是有個例外，那就是：如果指針NormalRoutine 為 0，那么實際的模式變成了 KernelMode。這是因為在這種情況下沒有用戶空間APC函數可以執行， 唯一將得到執行的是KernelRoutine！

最后，KeInitializeApc 設置Inserted域為FALSE。然而初始化APC對象，并沒有把它存放到相應的APC隊列中。

NTKERNELAPI
BOOLEAN
KeInsertQueueApc (
__inout PRKAPC Apc,
__in_opt PVOID SystemArgument1,
__in_opt PVOID SystemArgument2,
__in KPRIORITY Increment
);

據APC請求的具體情況，有時候要插在隊列的前頭，一般則掛在隊列的尾部。

_KiServiceExit:

cli ; disable interrupts
DISPATCH_USER_APC ebp, ReturnCurrentEax

;
; Exit from SystemService
;

EXIT_ALL NoRestoreSegs, NoRestoreVolatile ;這個宏以后再講

DISPATCH_USER_APC macro TFrame, ReturnCurrentEax
local a, b, c
c:
.errnz (EFLAGS_V86_MASK AND 0FF00FFFFh)

test byte ptr [TFrame]+TsEflags+2, EFLAGS_V86_MASK/010000h ; is previous mode v86?
jnz short b ; if nz, yes, go check for APC
test byte ptr [TFrame]+TsSegCs,MODE_MASK ; is previous mode user mode?
jz a ; No, previousmode=Kernel, jump out
b: mov ebx, PCR[PcPrcbData+PbCurrentThread]; get addr of current thread
mov byte ptr [ebx]+ThAlerted, 0 ; clear kernel mode alerted
cmp byte ptr [ebx]+ThApcState.AsUserApcPending, 0
je a ; if eq, no user APC pending

mov ebx, TFrame
ifnb <ReturnCurrentEax>;條件宏匯編，如果ReturnCurrentEax參數不為空，則編譯！

;DISPATCH_USER_APC ebp, ReturnCurrentEax，顯然這里是編譯的！
mov [ebx].TsEax, eax ; Store return code in trap frame
mov dword ptr [ebx]+TsSegFs, KGDT_R3_TEB OR RPL_MASK
mov dword ptr [ebx]+TsSegDs, KGDT_R3_DATA OR RPL_MASK
mov dword ptr [ebx]+TsSegEs, KGDT_R3_DATA OR RPL_MASK
mov dword ptr [ebx]+TsSegGs, 0
endif

;
; Save previous IRQL and set new priority level
;
RaiseIrql APC_LEVEL
push eax ; Save OldIrql

sti ; Allow higher priority ints

;
; call the APC delivery routine.
;
; ebx - Trap frame
; 0 - Null exception frame
; 1 - Previous mode
;
; call APC deliver routine
;

stdCall _KiDeliverApc, <1, 0, ebx> ;1就是UserMode

pop ecx ; (ecx) = OldIrql
LowerIrql ecx

ifnb <ReturnCurrentEax> ;同上分析
mov eax, [ebx].TsEax ; Restore eax, just in case
endif

cli
jmp b ; 注意這個循環！！

ALIGN 4
a:
endm

這段代碼主要檢查：

即將返回的是否用戶空間。
是否有用戶APC請求正在等待執行

條件符合才用KiDeliverApc真正投遞APC。注意代碼jmp b，好像在返回用戶空間前KiDeliverApc會被循環調用直到沒有user APC，其實不是的，KiDeliverApc每處理完一個User APC就把UserApcPending清零，所以User APCs在返回用戶空間時還是只能投遞一次！KiDeliverApc中用while處理完所有Kernel Mode APCs，但User Mode APC卻只處理一個！事實上User APC的投遞是很特殊的，以后會講到，而且每次只能投遞一次！

前面講過，KTHREAD 中有兩個 KAPC_STATE 數據結構，一個是 ApcState，另一個是SavedApcState，二者都有APC 隊列，但是要投遞的只是ApcState 中的隊列。

KiDeliverApc (
IN KPROCESSOR_MODE PreviousMode,//寫成DeliverMode不是更好
IN PKEXCEPTION_FRAME ExceptionFrame,//這個參數幾乎就是0
IN PKTRAP_FRAME TrapFrame
)

這個函數里面還比較復雜，代碼不帖了。

參數PreviousMode表示需要“投遞”哪一種 APC，可以是UserMode，也可以是KernelMode。不過，KernelMode 確實表示只要求執行內核 APC，而UserMode 卻表示在執行內核 APC 之外再執行用戶APC。

The Windows operating system uses three kinds of APCs:

User APCs run strictly in user mode and only when the current thread is in an alertable wait state. The operating system uses user APCs to implement mechanisms such as overlapped I/O and the QueueUserApc Win32 routine. （run IRQL = PASSIVE_LEVEL）
Normal kernel APCs run in kernel mode at IRQL = PASSIVE_LEVEL. A normal kernel APC preempts all user-mode code, including user APCs. Normal kernel APCs are generally used by file systems and file-system filter drivers.
Special kernel APCs run in kernel mode at IRQL = APC_LEVEL. A special kernel APC preempts user-mode code and kernel-mode code that executes at IRQL = PASSIVE_LEVEL, including both user APCs and normal kernel APCs. The operating system uses special kernel APCs to handle operations such as I/O request completion.
從代碼的角度看是這樣的：

User APCs
_KAPC.ApcMode==UserMode,_KAPC.KernelRoutine!=NULL,_KAPC.NormolRoutine!=NULL

Normal kernel APCs

_KAPC.ApcMode==KernelMode,_KAPC.KernelRoutine!=NULL,_KAPC.NormolRoutine!=NULL

Special kernel APCs

_KAPC.ApcMode==KernelMode,_KAPC.KernelRoutine!=NULL,_KAPC.NormolRoutine==NULL

有一點它們的_KAPC.KernelRoutine肯定不為空。并且，如果NormolRoutine也不為空，那么KernelRoutine都在NormolRoutine被調用前被調用！！

上文中講到投遞User Mode APCs是很特殊的，道理很簡單，因為User Mode APC是ring3下的回調函數，顯然ring0中的KiDeliverAPC（）不能像Kernel Mode APC那樣直接call，必須要先回到ring3環境下。當然不能像普通情況那樣返回（否則就回到ring3系統調用的地方了），只有一個辦法，那就是修改TrapFrame ，欺騙系統返回“APC回調函數”！KiInitializeUserApc就是這么做的！

該函數首先把TrapFrame轉化為ContextFrame，然后移動用戶態ESP指針，分配大約sizeof（CONTEXT）+sizeof（KAPC_RECORD）個字節:

UserStack-> ……

KAPC_RECORD

……

……

CONTEXT

TopOfStack-> ……

KAPC_RECORD就是KiInitializeUserApc的最后四個參數

nt!_KAPC_RECORD

+0x000 NormalRoutine : Ptr32 void

+0x004 NormalContext : Ptr32 Void

+0x008 SystemArgument1 : Ptr32 Void

+0x00c SystemArgument2 : Ptr32 Void

CONTEXT結構主要來存放被修改前的TrapFrame，之所以用CONTEXT結構是跟APC函數返回有關！

TrapFrame->HardwareEsp = UserStack;

TrapFrame->Eip = (ULONG)KeUserApcDispatcher;

TrapFrame->ErrCode = 0;

從上面的代碼看到確實修改了TrapFrame，并且返回到的是ring3下的KeUserApcDispatcher，剛才說的_KAPC_RECORD其實也是它的參數！真正我們的User APC回調函數是由KeUserApcDispatcher調用的！

.func KiUserApcDispatcher@16

.globl _KiUserApcDispatcher@16

_KiUserApcDispatcher@16:

/* Setup SEH stack */

lea eax, [esp+CONTEXT_ALIGNED_SIZE+16]

mov ecx, fs:[TEB_EXCEPTION_LIST]

mov edx, offset _KiUserApcExceptionHandler

mov [eax], ecx

mov [eax+4], edx

/* Enable SEH */

mov fs:[TEB_EXCEPTION_LIST], eax

/* Put the Context in EDI */

pop eax

lea edi, [esp+12]

/* Call the APC Routine */

call eax

/* Restore exception list */

mov ecx, [edi+CONTEXT_ALIGNED_SIZE]

mov fs:[TEB_EXCEPTION_LIST], ecx

/* Switch back to the context */

push 1 ; TestAlert

push edi ;edi->CONTEXT結構

call _ZwContinue@8

;;不會返回到這里的

上面的代碼并不難理解，我們的User APC回調函數返回后，立即調用了ZwContinue，這是個ntdll中的導出函數，這個函數又通過系統調用進入kernel中的NtContinue！

NTSTATUS

; NtContinue (

; IN PCONTEXT ContextRecord,

; IN BOOLEAN TestAlert

; )

;

; Routine Description:

;

; This routine is called as a system service to continue execution after

; an exception has occurred. Its function is to transfer information from

; the specified context record into the trap frame that was built when the

; system service was executed, and then exit the system as if an exception

; had occurred.

;

; WARNING - Do not call this routine directly, always call it as

; ZwContinue!!! This is required because it needs the

; trapframe built by KiSystemService.

;

; Arguments:

;

; KTrapFrame (ebp+0: after setup) -> base of KTrapFrame

;

; ContextRecord (ebp+8: after setup) = Supplies a pointer to a context rec.

;

; TestAlert (esp+12: after setup) = Supplies a boolean value that specifies

; whether alert should be tested for the previous processor mode.

;

; Return Value:

;

; Normally there is no return from this routine. However, if the specified

; context record is misaligned or is not accessible, then the appropriate

; status code is returned.

;

;--

NcTrapFrame equ [ebp + 0]

NcContextRecord equ [ebp + 8]

NcTestAlert equ [ebp + 12]

align dword

cPublicProc _NtContinue ,2

push ebp ;ebp->TrapFrame

;

; Restore old trap frame address since this service exits directly rather

; than returning.

;

mov ebx, PCR[PcPrcbData+PbCurrentThread] ; get current thread address

mov edx, [ebp].TsEdx ; restore old trap frame address

mov [ebx].ThTrapFrame, edx ;

;

; Call KiContinue to load ContextRecord into TrapFrame. On x86 TrapFrame

; is an atomic entity, so we don't need to allocate any other space here.

;

; KiContinue(NcContextRecord, 0, NcTrapFrame)

;

mov ebp,esp

mov eax, NcTrapFrame

mov ecx, NcContextRecord

stdCall _KiContinue, <ecx, 0, eax>

or eax,eax ; return value 0?

jnz short Nc20 ; KiContinue failed, go report error

;

; Check to determine if alert should be tested for the previous processor mode.

;

cmp byte ptr NcTestAlert,0 ; Check test alert flag

je short Nc10 ; if z, don't test alert, go Nc10

mov al,byte ptr [ebx]+ThPreviousMode ; No need to xor eax, eax.

stdCall _KeTestAlertThread, <eax> ; test alert for current thread

;如果User APCs不為空，它會設置UserApcPending,

;跟Alertable無關

Nc10: pop ebp ; (ebp) -> TrapFrame

mov esp,ebp ; (esp) = (ebp) -> trapframe

jmp _KiServiceExit2 ; common exit

Nc20: pop ebp ; (ebp) -> TrapFrame

mov esp,ebp ; (esp) = (ebp) -> trapframe

jmp _KiServiceExit ; common exit

stdENDP _NtContinue

NtContinue把CONTEXT結構轉化成TrapFrame（回復原來的陷阱幀），然后就從KiServiceExit2處退出系統調用！

;++

;

; _KiServiceExit2 - same as _KiServiceExit BUT the full trap_frame

; context is restored

;

;--

public _KiServiceExit2

_KiServiceExit2:

cli ; disable interrupts

DISPATCH_USER_APC ebp

;

; Exit from SystemService

;

EXIT_ALL ; RestoreAll

KiServiceExit2跟KiServiceExit差不多，只是宏參數的不同!同樣如果還有User APC又會進入上文描述的情形，直到沒有User APC，至此才會返回真正發起原始系統調用的地方！

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/better0332/archive/2009/06/29/4306683.aspx