APC：異步過程調用。這是一種常見的技術。前面進程啟動的初始過程就是：主線程在內核構造好運行環境后，從KiThreadStartup開始運行，然后調用PspUserThreadStartup，在該線程的apc隊列中插入一個APC：LdrInitializeThunk,這樣，當PspUserThreadStartup返回后，正式退回用戶空間的總入口BaseProcessStartThunk前，會執行中途插入的那個apc，完成進程的用戶空間初始化工作（鏈接dll的加載等）

可見：APC的執行時機之一就是從內核空間返回用戶空間的前夕。也即在返回用戶空間前，會“中斷”那么一下。因此，APC就是一種軟中斷。

除了這種APC用途外，應用程序中也經常使用APC。如Win32?API?ReadFileEx就可以使用APC機制來實現異步讀寫文件的功能。

BOOL???//源碼

ReadFileEx(IN?HANDLE?hFile,

???????????IN?LPVOID?lpBuffer,

???????????IN?DWORD?nNumberOfBytesToRead??OPTIONAL,

???????????IN?LPOVERLAPPED?lpOverlapped,//完成結果

???????????IN?LPOVERLAPPED_COMPLETION_ROUTINE?lpCompletionRoutine)//預置APC將調用的完成例程

{

???LARGE_INTEGER?Offset;

???NTSTATUS?Status;

???Offset.u.LowPart?=?lpOverlapped->Offset;

???Offset.u.HighPart?=?lpOverlapped->OffsetHigh;

???lpOverlapped->Internal?=?STATUS_PENDING;

???Status?=?NtReadFile(hFile,

???????????????????????NULL,?//Event=NULL

???????????????????????ApcRoutine,//這個是內部預置的APC例程

???????????????????????lpCompletionRoutine,//APC的Context

???????????????????????(PIO_STATUS_BLOCK)lpOverlapped,

???????????????????????lpBuffer,

???????????????????????nNumberOfBytesToRead,

???????????????????????&Offset,

???????????????????????NULL);//Key=NULL

???if?(!NT_SUCCESS(Status))

???{

?SetLastErrorByStatus(Status);//

?return?FALSE;

???}

???return?TRUE;

}

?

VOID??ApcRoutine(PVOID?ApcContext,//指向用戶提供的完成例程

_IO_STATUS_BLOCK*?IoStatusBlock,//完成結果

????????????ULONG?Reserved)

{

LPOVERLAPPED_COMPLETION_ROUTINE?lpCompletionRoutine?=?ApcContext;

DWORD?dwErrorCode?=?RtlNtStatusToDosError(IoStatusBlock->Status);

?????//調用用戶提供的完成例程

lpCompletionRoutine(dwErrorCode,

IoStatusBlock->Information,?

(LPOVERLAPPED)IoStatusBlock);

}

?

?

因此，應用層的用戶提供的完成例程實際上是作為APC函數進行的，它運行在APC_LEVEL?irql

?

NTSTATUS

NtReadFile(IN?HANDLE?FileHandle,

???????????IN?HANDLE?Event?OPTIONAL,

???????????IN?PIO_APC_ROUTINE?ApcRoutine?OPTIONAL,//內置的APC

???????????IN?PVOID?ApcContext?OPTIONAL,//應用程序中用戶提供的完成例程

???????????OUT?PIO_STATUS_BLOCK?IoStatusBlock,

???????????OUT?PVOID?Buffer,

???????????IN?ULONG?Length,

???????????IN?PLARGE_INTEGER?ByteOffset?OPTIONAL,

???????????IN?PULONG?Key?OPTIONAL)

{

???…

???Irp?=?IoAllocateIrp(DeviceObject->StackSize,?FALSE);//分配一個irp

???Irp->Overlay.AsynchronousParameters.UserApcRoutine?=?ApcRoutine;//記錄

???Irp->Overlay.AsynchronousParameters.UserApcContext?=?ApcContext;//記錄

???…

???Status?=?IoCallDriver(DeviceObject,?Irp);//把這個構造的irp發給底層驅動

???…

}

?

當底層驅動完成這個irp后，會調用IoCompleteRequest完成掉這個irp，這個IoCompleteRequest實際上內部最終調用IopCompleteRequest來做一些完成時的工作

VOID

IopCompleteRequest(IN?PKAPC?Apc,

???????????????????IN?PKNORMAL_ROUTINE*?NormalRoutine,

???????????????????IN?PVOID*?NormalContext,

???????????????????IN?PVOID*?SystemArgument1,

???????????????????IN?PVOID*?SystemArgument2)

{

???…

???if?(Irp->Overlay.AsynchronousParameters.UserApcRoutine)//上面傳入的APC

???{

??????//構造一個APC

??????KeInitializeApc(&Irp->Tail.Apc,KeGetCurrentThread(),CurrentApcEnvironment,

?????? IopFreeIrpKernelApc,

???????????????????IopAbortIrpKernelApc,

??????????????????(PKNORMAL_ROUTINE)Irp->Overlay.AsynchronousParameters.UserApcRoutine,

??????????????????Irp->RequestorMode,

??????????????????Irp->Overlay.AsynchronousParameters.UserApcContext);//應用層的完成例程

??????//插入到APC隊列

??????KeInsertQueueApc(&Irp->Tail.Apc,?Irp->UserIosb,?NULL,?2);

????}//end?if

???…

}

?

如上，ReadFileEx函數的異步APC機制是：在這個請求完成后，IO管理器會將一個APC插入隊列中，然后

在返回用戶空間前夕調用那個內置APC，最終調用應用層用戶提供的完成例程。

?

明白了APC大致原理后，現在詳細看一下APC的工作原理。

APC分兩種，用戶APC、內核APC。前者指在用戶空間執行的APC，后者指在內核空間執行的APC。

先看一下內核為支持APC機制提供的一些基礎結構設施。

Typedef?struct?_KTHREAD

{

???…

???KAPC_STATE??ApcState;//表示本線程當前使用的APC狀態（即apc隊列的狀態）

???KAPC_STATE??SavedApcState;//表示保存的原apc狀態，備份用

???KAPC_STATE*?ApcStatePointer[2];//狀態數組，包含兩個指向APC狀態的指針

???UCHAR?ApcStateIndex;//0或1，指當前的ApcState在ApcStatePointer數組中的索引位置

???UCHAR?ApcQueueable;//指本線程的APC隊列是否可插入apc

???ULONG?KernelApcDisable;//禁用標志

//專用于掛起操作的APC（這個函數在線程一得到調度就重新進入等待態,等待掛起計數減到0）

???KAPC?SuspendApc;

???…???

}KTHREAD;

?

Typedef?struct?_KAPC_STATE?//APC隊列的狀態描述符

{

???LIST_EBTRY??ApcListHead[2];//每個線程有兩個apc隊列

???PKPROCESS?Process;//當前線程所在的進程

???BOOL?KernelApcInProgress;//指示本線程是否當前正在?內核apc

???BOOL?KernelApcPending;//表示內核apc隊列中是否有apc

???BOOL?UserApcPending;//表示用戶apc隊列中是否apc

}

Typedef?enum?_KAPC_ENVIRONMENT

{

???OriginalApcEnvironment,//0，狀態數組索引

???AttachedApcEnvironment;//1，狀態數組索引

???CurrentApc?Environment;//2，表示使用當前apc狀態

???CurrentApc?Environment;//3，表示使用插入apc時那時的線程的apc狀態

}

?

一個線程可以掛靠到其他進程的地址空間中，因此，一個線程的狀態分兩種：常態、掛靠態。

常態下，狀態數組中0號元素指向ApcState(即當前apc狀態)，1號元素指向SavedApcState(非當前apc狀態)；掛靠態下，兩個元素的指向剛好相反。但無論如何，KTHREAD結構中的ApcStateIndex總是指當前狀態的位置，ApcState則總是表示線程當前使用的apc狀態。

于是有：

#define?PsGetCurrentProcess??IoGetCurrentProces

PEPROCESS??IoGetCurrentProces()

{

???Return?PsGetCurrentThread()->Tcb.ApcState.Process;//ApcState中的進程字段總是表示當前進程

}

不管當前線程是處于常態還是掛靠態下，它都有兩個apc隊列，一個內核，一個用戶。把apc插入對應的隊列后就可以在恰當的時機得到執行。注意：每當一個線程掛靠到其他進程時，掛靠初期，兩個apc隊列都會變空。下面看下每個apc本身的結構

typedef?struct?_KAPC

{

??UCHAR?Type;//結構體的類型

??UCHAR?Size;//結構體的大小

??struct?_KTHREAD?*Thread;//目標線程

??LIST_ENTRY?ApcListEntry;//用來掛入目標apc隊列

??PKKERNEL_ROUTINE?KernelRoutine;//該apc的內核總入口

??PKRUNDOWN_ROUTINE?RundownRoutine;

??PKNORMAL_ROUTINE?NormalRoutine;//該apc的用戶空間總入口或者用戶真正的內核apc函數

??PVOID?NormalContext;//真正用戶提供的用戶空間apc函數或者用戶真正的內核apc函數的context*

??PVOID?SystemArgument1;//掛入時的附加參數1。真正用戶apc的context*

??PVOID?SystemArgument2;//掛入時的附加參數2

??CCHAR?ApcStateIndex;//指要掛入目標線程的哪個狀態時的apc隊列

??KPROCESSOR_MODE?ApcMode;//指要掛入用戶apc隊列還是內核apc隊列

??BOOLEAN?Inserted;//表示本apc是否已掛入隊列

}?KAPC,?*PKAPC;

注意：

若這個apc是內核apc，那么NormalRoutine表示用戶自己提供的內核apc函數，NormalContext則是該apc函數的context*，SystemArgument1與SystemArgument2表示插入隊列時的附加參數

若這個apc是用戶apc，那么NormalRoutine表示該apc的用戶空間總apc函數，NormalContext才是真正用戶自己提供的用戶空間apc函數，SystemArgument1則表示該真正apc的context*。（一切錯位了）

?

?

//下面這個Win32?API可以用來手動插入一個apc到指定線程的用戶apc隊列中

DWORD?

QueueUserAPC(PAPCFUNC?pfnAPC,?HANDLE?hThread,?ULONG_PTR?dwData)

{

??NTSTATUS?Status;

??//調用對應的系統服務

??Status?=?NtQueueApcThread(hThread,//目標線程

?IntCallUserApc,//用戶空間中的總apc入口

?pfnAPC,//用戶自己真正提供的apc函數

(PVOID)dwData,//SysArg1=context*

?NULL);//SysArg2=NULL

??if?(!NT_SUCCESS(Status))

??{

????SetLastErrorByStatus(Status);

????return?0;

??}

??return?1;

}

?

NTSTATUS

NtQueueApcThread(IN?HANDLE?ThreadHandle,//目標線程

?????????????????IN?PKNORMAL_ROUTINE?ApcRoutine,//用戶空間中的總apc

?????????????????IN?PVOID?NormalContext,//用戶自己真正的apc函數

?????????????????IN?PVOID?SystemArgument1,//用戶自己apc的context*

?????????????????IN?PVOID?SystemArgument2)//其它

{

????PKAPC?Apc;

????PETHREAD?Thread;

????NTSTATUS?Status?=?STATUS_SUCCESS;

????Status?=?ObReferenceObjectByHandle(ThreadHandle,THREAD_SET_CONTEXT,PsThreadType,

???????????????????????????????????????ExGetPreviousMode(),?(PVOID)&Thread,NULL);

????//分配一個apc結構，這個結構最終在PspQueueApcSpecialApc中釋放

????Apc?=?ExAllocatePoolWithTag(NonPagedPool?|POOL_QUOTA_FAIL_INSTEAD_OF_RAISE,

????????????????????????????????sizeof(KAPC),TAG_PS_APC);

????//構造一個apc

????KeInitializeApc(Apc,

????????????????????&Thread->Tcb,//目標線程

????????????????????OriginalApcEnvironment,//目標apc狀態（此服務固定為OriginalApcEnvironment）

????????????????????PspQueueApcSpecialApc,//內核apc總入口

????????????????????NULL,//Rundown?Rounine=NULL

????????????????????ApcRoutine,//用戶空間的總apc

????????????????????UserMode,//此系統服務固定插入到用戶apc隊列

????????????????????NormalContext);//用戶自己真正的apc函數

????//插入到目標線程的用戶apc隊列

????KeInsertQueueApc(Apc,

?????????????????????SystemArgument1,//插入時的附加參數1，此處為用戶自己apc的context*

?????????????????????SystemArgument2,?//插入時的附加參數2

?????????????????????IO_NO_INCREMENT)//表示不予調整目標線程的調度優先級

????return?Status;

}

?

//這個函數用來構造一個要插入指定目標隊列的apc對象

VOID

KeInitializeApc(IN?PKAPC?Apc,

????????????????IN?PKTHREAD?Thread,//目標線程

????????????????IN?KAPC_ENVIRONMENT?TargetEnvironment,//目標線程的目標apc狀態

????????????????IN?PKKERNEL_ROUTINE?KernelRoutine,//內核apc總入口

????????????????IN?PKRUNDOWN_ROUTINE?RundownRoutine?OPTIONAL,

????????????????IN?PKNORMAL_ROUTINE?NormalRoutine,//用戶空間的總apc

????????????????IN?KPROCESSOR_MODE?Mode,//要插入用戶apc隊列還是內核apc隊列

????????????????IN?PVOID?Context)?//用戶自己真正的apc函數

{

????Apc->Type?=?ApcObject;

????Apc->Size?=?sizeof(KAPC);

????if?(TargetEnvironment?==?CurrentApcEnvironment)//CurrentApcEnvironment表示使用當前apc狀態

????????Apc->ApcStateIndex?=?Thread->ApcStateIndex;

????else

????????Apc->ApcStateIndex?=?TargetEnvironment;

????Apc->Thread?=?Thread;

????Apc->KernelRoutine?=?KernelRoutine;

????Apc->RundownRoutine?=?RundownRoutine;

????Apc->NormalRoutine?=?NormalRoutine;

????if?(NormalRoutine)//if?提供了用戶空間總apc入口

????{

????????Apc->ApcMode?=?Mode;

????????Apc->NormalContext?=?Context;

????}

????Else//若沒提供，肯定是內核模式

????{

????????Apc->ApcMode?=?KernelMode;

????????Apc->NormalContext?=?NULL;

????}

????Apc->Inserted?=?FALSE;//表示初始構造后，尚未掛入apc隊列

}

?

BOOLEAN

KeInsertQueueApc(IN?PKAPC?Apc,IN?PVOID?SystemArgument1,IN?PVOID?SystemArgument2,

?????????????????IN?KPRIORITY?PriorityBoost)

{

????PKTHREAD?Thread?=?Apc->Thread;

????KLOCK_QUEUE_HANDLE?ApcLock;

????BOOLEAN?State?=?TRUE;

????KiAcquireApcLock(Thread,?&ApcLock);//插入過程需要獨占隊列

????if?(!(Thread->ApcQueueable)?||?(Apc->Inserted))//檢查隊列是否可以插入apc

????????State?=?FALSE;

????else

????{

????????Apc->SystemArgument1?=?SystemArgument1;//記錄該apc的附加插入時的參數

????????Apc->SystemArgument2?=?SystemArgument2;?//記錄該apc的附加插入時的參數

????????Apc->Inserted?=?TRUE;//標記為已插入隊列

???//插入目標線程的目標apc隊列（如果目標線程正處于睡眠狀態，可能會喚醒它）

????????KiInsertQueueApc(Apc,?PriorityBoost);?

????}

????KiReleaseApcLockFromDpcLevel(&ApcLock);

????KiExitDispatcher(ApcLock.OldIrql);//可能引發一次線程切換，以立即切換到目標線程執行apc

????return?State;

}

?

VOID?FASTCALL

KiInsertQueueApc(IN?PKAPC?Apc,IN?KPRIORITY?PriorityBoost)//喚醒目標線程后的優先級增量

{

????PKTHREAD?Thread?=?Apc->Thread;

????BOOLEAN?RequestInterrupt?=?FALSE;

????if?(Apc->ApcStateIndex?==?InsertApcEnvironment)?//if要動態插入到當前的apc狀態隊列

????????Apc->ApcStateIndex?=?Thread->ApcStateIndex;?

????ApcState?=?Thread->ApcStatePointer[(UCHAR)Apc->ApcStateIndex];//目標狀態

ApcMode?=?Apc->ApcMode;

//先插入apc到指定位置

????/*?插入位置的確定：分三種情形

?????*?1)?Kernel?APC?with?Normal?Routine?or?User?APC?:?Put?it?at?the?end?of?the?List

?????*?2)?User?APC?which?is?PsExitSpecialApc?:?Put?it?at?the?front?of?the?List

?????*?3)?Kernel?APC?without?Normal?Routine?:?Put?it?at?the?end?of?the?No-Normal?Routine?Kernel?APC?list

????*/

????if?(Apc->NormalRoutine)//有NormalRoutine的APC都插入尾部（用戶模式發來的線程終止APC除外）

????{

????????if?((ApcMode?==?UserMode)?&&?(Apc->KernelRoutine?==?PsExitSpecialApc))

????????{

????????????Thread->ApcState.UserApcPending?=?TRUE;

????????????InsertHeadList(&ApcState->ApcListHead[ApcMode],&Apc->ApcListEntry);

????????}

????????else

????????????InsertTailList(&ApcState->ApcListHead[ApcMode],&Apc->ApcListEntry);

????}

????Else?//無NormalRoutine的特殊類APC（內核APC），少見

????{

????????ListHead?=?&ApcState->ApcListHead[ApcMode];

????????NextEntry?=?ListHead->Blink;

????????while?(NextEntry?!=?ListHead)

????????{

????????????QueuedApc?=?CONTAINING_RECORD(NextEntry,?KAPC,?ApcListEntry);

????????????if?(!QueuedApc->NormalRoutine)?break;

????????????NextEntry?=?NextEntry->Blink;

????????}

????????InsertHeadList(NextEntry,?&Apc->ApcListEntry);//插在這兒

????}

?

????//插入到相應的位置后，下面檢查Apc狀態是否匹配

????if?(Thread->ApcStateIndex?==?Apc->ApcStateIndex)//if?插到了當前apc狀態的apc隊列中

????{

????????if?(Thread?==?KeGetCurrentThread())//if就是給當前線程發送的apc

????????{

????????????ASSERT(Thread->State?==?Running);//當前線程肯定沒有睡眠，這不廢話嗎？

????????????if?(ApcMode?==?KernelMode)

????????????{

????????????????Thread->ApcState.KernelApcPending?=?TRUE;

????????????????if?(!Thread->SpecialApcDisable)//發出一個apc中斷，待下次降低irql時將執行apc

????????????????????HalRequestSoftwareInterrupt(APC_LEVEL);?//關鍵

????????????}

????????}

????????Else?//給其他線程發送的內核apc

????????{

????????????KiAcquireDispatcherLock();

????????????if?(ApcMode?==?KernelMode)

????????????{

????????????????Thread->ApcState.KernelApcPending?=?TRUE;

????????????????if?(Thread->State?==?Running)

????????????????????RequestInterrupt?=?TRUE;//需要給它發出一個apc中斷

????????????????else?if?((Thread->State?==?Waiting)?&&?(Thread->WaitIrql?==?PASSIVE_LEVEL)?&&

?????????????????????????!(Thread->SpecialApcDisable)?&&?(!(Apc->NormalRoutine)?||

?????????????????????????(!(Thread->KernelApcDisable)?&&

?????????????????????????!(Thread->ApcState.KernelApcInProgress))))

????????????????{

????????????????????Status?=?STATUS_KERNEL_APC;

????????????????????KiUnwaitThread(Thread,?Status,?PriorityBoost);//臨時喚醒目標線程執行apc

????????????????}

????????????????else?if?(Thread->State?==?GateWait)?…

????????????}

????????????else?if?((Thread->State?==?Waiting)?&&?(Thread->WaitMode?==?UserMode)?&&

?????????????????????((Thread->Alertable)?||?(Thread->ApcState.UserApcPending)))

????????????{

????????????????Thread->ApcState.UserApcPending?=?TRUE;

????????????????Status?=?STATUS_USER_APC;

????????????????KiUnwaitThread(Thread,?Status,?PriorityBoost);//強制喚醒目標線程

????????????}

????????????KiReleaseDispatcherLockFromDpcLevel();

????????????KiRequestApcInterrupt(RequestInterrupt,?Thread->NextProcessor);

????????}

????}

}

如上，這個函數既可以給當前線程發送apc，也可以給目標線程發送apc。若給當前線程發送內核apc時，會立即請求發出一個apc中斷。若給其他線程發送apc時，可能會喚醒目標線程。

?

APC函數的執行時機：

回顧一下從內核返回用戶時的流程：

KiSystemService()//int?2e的isr，內核服務函數總入口，注意這個函數可以嵌套、遞歸！！！

{

?????SaveTrap();//保存trap現場

Sti??//開中斷

---------------上面保存完寄存器等現場后，開始查SST表調用系統服務------------------

FindTableCall();

---------------------------------調用完系統服務函數后------------------------------

Move??esp,kthread.TrapFrame;?//將棧頂回到trap幀結構體處

Cli??//關中斷

If(上次模式==UserMode)

{

Call??KiDeliverApc?//遍歷執行本線程的內核APC和用戶APC隊列中的所有APC函數

清理Trap幀，恢復寄存器現場

Iret???//返回用戶空間

}

Else

{

???返回到原call處后面的那條指令處

}

}

不光是從系統調用返回用戶空間要掃描執行apc，從異常和中斷返回用戶空間也同樣需要掃描執行。

現在我們只看從系統調用返回時apc的執行過程。

上面是偽代碼，實際的從Cli后面的代碼，是下面這樣的。

Test?dword?ptr[ebp+KTRAP_FRAME_EFLAGS],?EFLAGS_V86_MASK???//檢查eflags是否標志運行在V86模式

Jnz?1??//若運行在V86模式，那么上次模式肯定是從用戶空間進入內核的，跳過下面的檢查

Test?byte?ptr[ebp+KTRAP_FRAME_CS],1

Je?2?//若上次模式不是用戶模式，跳過下面的流程，不予掃描apc

1:

Mov?ebx,PCR[KPCR_CURRENT_THREAD]??//ebx=KTHREAD*（當前線程對象的地址）

Mov?byte?ptr[ebx+KTHREAD_ALERTED],0?//kthread.Alert修改為不可提醒

Cmp?byte?ptr[ebx+KTHREAD_PENDING_USER_APC],0

Je?2?//如果當前線程的用戶apc隊列為空，直接跳過

Mov?ebx,ebp?//ebx=TrapFrame幀的地址

Mov?[ebx,KTRAP_FRAME_EAX],eax?//保存

Mov?ecx,APC_LEVEL

Call?KfRaiseIrql??//call?KfRaiseIrql(APC_LEVEL)

Push?eax?//保存提升irql之前的irql

Sti

Push?ebx?//TrapFrame幀的地址

Push?NULL

Push?UserMode

Call?KiDeliverApc???//call?KiDeliverApc(UserMode,?NULL,?TrapFrame*)?

Pop?ecx?//?ecx=之前的irql

Call?KfLowerIrql??//call?KfLowerIrql(之前的irql)

Move?eax,?[ebx,KTRAP_FRAME_EAX]?//恢復eax

Cli

Jmp?1?//再次跳回1處循環，掃描apc隊列

…

?

關鍵的函數是KiDeliverApc，這個函數用來真正掃描apc隊列執行所有apc，我們看：

VOID

KiDeliverApc(IN?KPROCESSOR_MODE?DeliveryMode,//指要執行哪個apc隊列中的函數

?????????????IN?PKEXCEPTION_FRAME?ExceptionFrame,//傳入的是NULL

?????????????IN?PKTRAP_FRAME?TrapFrame)//即將返回用戶空間前的Trap現場幀

{

????PKTHREAD?Thread?=?KeGetCurrentThread();

????PKPROCESS?Process?=?Thread->ApcState.Process;

????OldTrapFrame?=?Thread->TrapFrame;

????Thread->TrapFrame?=?TrapFrame;

????Thread->ApcState.KernelApcPending?=?FALSE;

if?(Thread->SpecialApcDisable)?goto?Quickie;

//先固定執行掉內核apc隊列中的所有apc函數

????while?(!IsListEmpty(&Thread->ApcState.ApcListHead[KernelMode]))

????{

????????KiAcquireApcLockAtApcLevel(Thread,?&ApcLock);//鎖定apc隊列

????????ApcListEntry?=?Thread->ApcState.ApcListHead[KernelMode].Flink;//隊列頭部中的apc

????????Apc?=?CONTAINING_RECORD(ApcListEntry,?KAPC,?ApcListEntry);

????????KernelRoutine?=?Apc->KernelRoutine;//內核總apc函數

????????NormalRoutine?=?Apc->NormalRoutine;//用戶自己真正的內核apc函數

????????NormalContext?=?Apc->NormalContext;//真正內核apc函數的context*

????????SystemArgument1?=?Apc->SystemArgument1;

????????SystemArgument2?=?Apc->SystemArgument2;

????????if?(NormalRoutine==NULL)?//稱為Special?Apc,少見

????????{

????????????RemoveEntryList(ApcListEntry);//關鍵，移除隊列

????????????Apc->Inserted?=?FALSE;

????????????KiReleaseApcLock(&ApcLock);

????????????//執行內核中的總apc函數

????????????KernelRoutine(Apc,&NormalRoutine,&NormalContext,

??????????????????????????&SystemArgument1,&SystemArgument2);

????????}

????????Else?//典型，一般程序員都會提供一個自己的內核apc函數

????????{

????????????if?((Thread->ApcState.KernelApcInProgress)?||?(Thread->KernelApcDisable))

????????????{

????????????????KiReleaseApcLock(&ApcLock);

????????????????goto?Quickie;

????????????}

????????????RemoveEntryList(ApcListEntry);?//關鍵，移除隊列

????????????Apc->Inserted?=?FALSE;

????????????KiReleaseApcLock(&ApcLock);

//執行內核中的總apc函數

????????????KernelRoutine(Apc,

??????????????????????????&NormalRoutine,//注意，內核中的總apc可能會在內部修改NormalRoutine

??????????????????????????&NormalContext,

??????????????????????????&SystemArgument1,

??????????????????????????&SystemArgument2);

????????????if?(NormalRoutine)//如果內核總apc沒有修改NormalRoutine成NULL

????????????{

????????????????Thread->ApcState.KernelApcInProgress?=?TRUE;//標記當前線程正在執行內核apc

????????????????KeLowerIrql(PASSIVE_LEVEL);

????????????????//直接調用用戶提供的真正內核apc函數

????????????????NormalRoutine(NormalContext,?SystemArgument1,?SystemArgument2);

????????????????KeRaiseIrql(APC_LEVEL,?&ApcLock.OldIrql);

????????????}

????????????Thread->ApcState.KernelApcInProgress?=?FALSE;

????????}

????}

????//上面的循環，執行掉所有內核apc函數后，下面開始執行用戶apc隊列中的第一個apc

????if?((DeliveryMode?==?UserMode)?&&

?????????!(IsListEmpty(&Thread->ApcState.ApcListHead[UserMode]))?&&

?????????(Thread->ApcState.UserApcPending))

????{

????????KiAcquireApcLockAtApcLevel(Thread,?&ApcLock);//鎖定apc隊列

????????Thread->ApcState.UserApcPending?=?FALSE;

?

????????ApcListEntry?=?Thread->ApcState.ApcListHead[UserMode].Flink;//隊列頭

????????Apc?=?CONTAINING_RECORD(ApcListEntry,?KAPC,?ApcListEntry);

????????KernelRoutine?=?Apc->KernelRoutine;?//內核總apc函數

????????NormalRoutine?=?Apc->NormalRoutine;?//用戶空間的總apc函數

????????NormalContext?=?Apc->NormalContext;//用戶真正的用戶空間apc函數

????????SystemArgument1?=?Apc->SystemArgument1;//真正apc的context*

????????SystemArgument2?=?Apc->SystemArgument2;

????????RemoveEntryList(ApcListEntry);//關鍵，移除隊列

????????Apc->Inserted?=?FALSE;

????????KiReleaseApcLock(&ApcLock);

????????KernelRoutine(Apc,

??????????????????????&NormalRoutine,//?注意，內核中的總apc可能會在內部修改NormalRoutine

??????????????????????&NormalContext,

??????????????????????&SystemArgument1,

??????????????????????&SystemArgument2);

????????if?(!NormalRoutine)

????????????KeTestAlertThread(UserMode);

????????Else?//典型，準備提前回到用戶空間調用用戶空間的總apc函數

????????{

????????????KiInitializeUserApc(ExceptionFrame,//NULL

????????????????????????????????TrapFrame,//Trap幀的地址

????????????????????????????????NormalRoutine,?//用戶空間的總apc函數

????????????????????????????????NormalContext,?//用戶真正的用戶空間apc函數

????????????????????????????????SystemArgument1,?//真正apc的context*

????????????????????????????????SystemArgument2);

????????}

????}

Quickie:

????Thread->TrapFrame?=?OldTrapFrame;

}

如上，這個函數既可以用來投遞處理內核apc函數，也可以用來投遞處理用戶apc隊列中的函數。

特別的，當要調用這個函數投遞處理用戶apc隊列中的函數時，它每次只處理一個用戶apc。

由于正式回到用戶空間前，會循環調用這個函數。因此，實際的處理順序是：

掃描執行內核apc隊列所有apc->執行用戶apc隊列中一個apc->再次掃描執行內核apc隊列所有apc->執行用戶apc隊列中下一個apc->再次掃描執行內核apc隊列所有apc->再次執行用戶apc隊列中下一個apc如此循環，直到將用戶apc隊列中的所有apc都執行掉。

執行用戶apc隊列中的apc函數與內核apc不同，因為用戶apc隊列中的apc函數自然是要在用戶空間中執行的，而KiDeliverApc這個函數本身位于內核空間，因此，不能直接調用用戶apc函數，需要‘提前’回到用戶空間去執行隊列中的每個用戶apc，然后重新返回內核，再次掃描整個內核apc隊列，再執行用戶apc隊列中遺留的下一個用戶apc。如此循環，直至執行完所有用戶apc后，才‘正式’返回用戶空間。

?

?

?

?

下面的函數就是用來為執行用戶apc做準備的。

VOID

KiInitializeUserApc(IN?PKEXCEPTION_FRAME?ExceptionFrame,

????????????????????IN?PKTRAP_FRAME?TrapFrame,//原真正的斷點現場幀

????????????????????IN?PKNORMAL_ROUTINE?NormalRoutine,

????????????????????IN?PVOID?NormalContext,

????????????????????IN?PVOID?SystemArgument1,

????????????????????IN?PVOID?SystemArgument2)

{

Context.ContextFlags?=?CONTEXT_FULL?|?CONTEXT_DEBUG_REGISTERS;

//將原真正的Trap幀打包保存在一個Context結構中

????KeTrapFrameToContext(TrapFrame,?ExceptionFrame,?&Context);

????_SEH2_TRY

????{

????????AlignedEsp?=?Context.Esp?&?~3;//對齊4B

//為用戶空間中KiUserApcDisatcher函數的參數騰出空間（4個參數+?CONTEXT?+?8B的seh節點）

????????ContextLength?=?CONTEXT_ALIGNED_SIZE?+?(4?*?sizeof(ULONG_PTR));

????????Stack?=?((AlignedEsp?-?8)?&?~3)?-?ContextLength;//8表示seh節點的大小

????????//模擬壓入KiUserApcDispatcher函數的4個參數

????????*(PULONG_PTR)(Stack?+?0?*?sizeof(ULONG_PTR))?=?(ULONG_PTR)NormalRoutine;

????????*(PULONG_PTR)(Stack?+?1?*?sizeof(ULONG_PTR))?=?(ULONG_PTR)NormalContext;

????????*(PULONG_PTR)(Stack?+?2?*?sizeof(ULONG_PTR))?=?(ULONG_PTR)SystemArgument1;

????????*(PULONG_PTR)(Stack?+?3?*?sizeof(ULONG_PTR))?=?(ULONG_PTR)SystemArgument2;

????????//將原真正trap幀保存在用戶棧的一個CONTEXT結構中，方便以后還原

????????RtlCopyMemory(?(Stack?+?(4?*?sizeof(ULONG_PTR))),&Context,sizeof(CONTEXT));

?

????????//強制修改當前Trap幀中的返回地址與用戶棧地址（偏離原來的返回路線）

????????TrapFrame->Eip?=?(ULONG)KeUserApcDispatcher;//關鍵，新的返回斷點地址

????????TrapFrame->HardwareEsp?=?Stack;//關鍵，新的用戶棧頂

????????TrapFrame->SegCs?=?Ke386SanitizeSeg(KGDT_R3_CODE,?UserMode);

????????TrapFrame->HardwareSegSs?=?Ke386SanitizeSeg(KGDT_R3_DATA,?UserMode);

????????TrapFrame->SegDs?=?Ke386SanitizeSeg(KGDT_R3_DATA,?UserMode);

????????TrapFrame->SegEs?=?Ke386SanitizeSeg(KGDT_R3_DATA,?UserMode);

????????TrapFrame->SegFs?=?Ke386SanitizeSeg(KGDT_R3_TEB,?UserMode);

????????TrapFrame->SegGs?=?0;

????????TrapFrame->ErrCode?=?0;

????????TrapFrame->EFlags?=?Ke386SanitizeFlags(Context.EFlags,?UserMode);

????????if?(KeGetCurrentThread()->Iopl)?TrapFrame->EFlags?|=?EFLAGS_IOPL;

????}

????_SEH2_EXCEPT((RtlCopyMemory(&SehExceptRecord,?_SEH2_GetExceptionInformation()->ExceptionRecord,?sizeof(EXCEPTION_RECORD)),????EXCEPTION_EXECUTE_HANDLER))

????{

????????SehExceptRecord.ExceptionAddress?=?(PVOID)TrapFrame->Eip;

????????KiDispatchException(&SehExceptRecord,ExceptionFrame,TrapFrame,UserMode,TRUE);

????}

????_SEH2_END;

}

至于為什么要放在一個try塊中保護，是因為用戶空間中的棧地址，誰也無法保證會不會出現崩潰。

如上，這個函數修改返回地址，回到用戶空間中的KiUserApcDisatcher函數處去。然后把原trap幀保存在用戶棧中。由于KiUserApcDisatcher這個函數有參數，所以需要模擬壓入這個函數的參數，這樣，當返回到用戶空間時，就仿佛是在調用這個函數。看下那個函數的代碼：

KiUserApcDisatcher(NormalRoutine,

???????????????????NormalContext,

???????????????????SysArg1,

???????????????????SysArg2

)

{

???Lea?eax,[esp+?CONTEXT_ALIGNED_SIZE+16]???//eax指向seh異常節點的地址

???Mov?ecx,fs:[TEB_EXCEPTION_LIST]

???Mov?edx,offset?KiUserApcExceptionHandler

???--------------------------------------------------------------------------------------

???Mov?[eax],ecx?//seh節點的next指針成員

???Mov?[eax+4],edx?//she節點的handler函數指針成員

???Mov?fs:[TEB_EXCEPTION_LIST],eax

???--------------------上面三條指令在棧中構造一個8B的標準seh節點-----------------------

???Pop?eax?//eax=NormalRoutine（即IntCallUserApc這個總apc函數）

???Lea?edi,[esp+12]?//edi=棧中保存的CONTEXT結構的地址

???Call?eax?//相當于call?IntCallUserApc（NormalContext，SysArg1，SysArg2）

???

???Mov?ecx,[edi+?CONTEXT_ALIGNED_SIZE]

???Mov?fs:[?TEB_EXCEPTION_LIST],ecx???//撤銷棧中的seh節點

?

???Push?TRUE??//表示回到內核后需要繼續檢測執行用戶apc隊列中的apc函數

???Push?edi??//傳入原棧幀的CONTEXT結構的地址給這個函數，以做恢復工作

???Call?NtContinue???//調用這個函數重新進入內核（注意這個函數正常情況下是不會返回到下面的）

???----------------------------------華麗的分割線-------------------------------------------

???Mov?esi,eax

???Push?esi

???Call?RtlRaiseStatus??//若ZwContinue返回了，那一定是內部出現了異常

???Jmp?StatusRaiseApc

???Ret?16

}

如上，每當要執行一個用戶空間apc時，都會‘提前’偏離原來的路線返回用戶空間的這個函數處去執行用戶的apc。在執行這個函數前，會先構造一個seh節點，也即相當于把這個函數的調用放在try塊中保護。這個函數內部會調用IntCallUserApc，執行完真正的用戶apc函數后，調用ZwContinue重返內核。?

?

?

Void?CALLBACK??//用戶空間的總apc函數

IntCallUserApc(void*?RealApcFunc,?void*?SysArg1,void*?SysArg2)

{

???(*RealApcFunc)(SysArg1);//也即調用RealApcFunc（void*?context）

}

NTSTATUS?NtContinue(CONTEXT*?Context,?//原真正的TraFrame?

????????????????????BOOL?TestAlert??//指示是否繼續執行用戶apc隊列中的apc函數

)

{

???Push?ebp??//此時ebp=本系統服務自身的TrapFrame地址

???Mov?ebx,PCR[KPCR_CURRENT_THREAD]?//ebx=當前線程的KTHREAD對象地址

???Mov?edx,[ebp+KTRAP_FRAME_EDX]?//注意TrapFrame中的這個edx字段不是用來保存edx的

???Mov?[ebx+KTHREAD_TRAP_FRAME],edx?//將當前的TrapFrame改為上一個TrapFrame的地址

???Mov?ebp,esp

???Mob?eax,[ebp]?//eax=本系統服務自身的TrapFrame地址

???Mov?ecx,[ebp+8]?/本函數的第一個參數，即Context

???Push?eax

???Push?NULL

???Push?ecx

???Call?KiContinue??//call?KiContinue(Context*,NULL,TrapFrame*)

???Or?eax,eax

???Jnz?error

???Cmp?dword?ptr[ebp+12],0?//檢查TestAlert參數的值

???Je?DontTest

???Mov?al,[ebx+KTHREAD_PREVIOUS_MODE]

???Push?eax

???Call?KeTestAlertThread??//檢測用戶apc隊列是否為空

???DontTest：

???Pop?ebp

???Mov?esp,ebp

???Jmp?KiServiceExit2?//返回用戶空間（返回前，又會去掃描執行apc隊列中的下一個用戶apc）

}

?

?

NTSTATUS

KiContinue(IN?PCONTEXT?Context,//原來的斷點現場

???????????IN?PKEXCEPTION_FRAME?ExceptionFrame,

???????????IN?PKTRAP_FRAME?TrapFrame)?//NtContinue自身的TrapFrame地址

{

????NTSTATUS?Status?=?STATUS_SUCCESS;

????KIRQL?OldIrql?=?APC_LEVEL;

????KPROCESSOR_MODE?PreviousMode?=?KeGetPreviousMode();

if?(KeGetCurrentIrql()?<?APC_LEVEL)?

KeRaiseIrql(APC_LEVEL,?&OldIrql);

????_SEH2_TRY

????{

????????if?(PreviousMode?!=?KernelMode)

????????????KiContinuePreviousModeUser(Context,ExceptionFrame,TrapFrame);//恢復成原TrapFrame

????????else

????????{

????????????KeContextToTrapFrame(Context,ExceptionFrame,TrapFrame,Context->ContextFlags,

?????????????????????????????????KernelMode);?//恢復成原TrapFrame

????????}

????}

????_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)

????{

????????Status?=?_SEH2_GetExceptionCode();

????}

????_SEH2_END;

if?(OldIrql?<?APC_LEVEL)

?KeLowerIrql(OldIrql);

????return?Status;

}

?

VOID

KiContinuePreviousModeUser(IN?PCONTEXT?Context,//原來的斷點現場

???????????????????????????IN?PKEXCEPTION_FRAME?ExceptionFrame,

???????????????????????????IN?PKTRAP_FRAME?TrapFrame)//NtContinue自身的TrapFrame地址

{

????CONTEXT?LocalContext;

????ProbeForRead(Context,?sizeof(CONTEXT),?sizeof(ULONG));

????RtlCopyMemory(&LocalContext,?Context,?sizeof(CONTEXT));

Context?=?&LocalContext;

//看到沒，將原Context中的成員填寫到NtContinue系統服務的TrapFrame幀中（也即修改成原來的TrapFrame）

????KeContextToTrapFrame(&LocalContext,ExceptionFrame,TrapFrame,

?????????????????????????LocalContext.ContextFlags,UserMode);

}

?

如上，上面的函數，就把NtContinue的TrapFrame強制還原成原來的TrapFrame，以好‘正式’返回到用戶空間的真正斷點處（不過在返回用戶空間前，又要去掃描用戶apc隊列，若仍有用戶apc函數，就先執行掉內核apc隊列中的所有apc函數，然后又偏離原來的返回路線，‘提前’返回到用戶空間的KiUserApcDispatcher函數去執行用戶apc，這是一個不斷循環的過程。可見，NtContinue這個函數不僅含有繼續回到原真正用戶空間斷點處的意思，還含有繼續執行用戶apc隊列中下一個apc函數的意思）

?

BOOLEAN??KeTestAlertThread(IN?KPROCESSOR_MODE?AlertMode)

{

????PKTHREAD?Thread?=?KeGetCurrentThread();

????KiAcquireApcLock(Thread,?&ApcLock);

????OldState?=?Thread->Alerted[AlertMode];

????if?(OldState)

????????Thread->Alerted[AlertMode]?=?FALSE;

????else?if?((AlertMode?!=?KernelMode)?&&

?(!IsListEmpty(&Thread->ApcState.ApcListHead[UserMode])))

????{

????????Thread->ApcState.UserApcPending?=?TRUE;//關鍵。又標記為不空，從而又去執行用戶apc

????}

????KiReleaseApcLock(&ApcLock);

????return?OldState;

}

上面這個函數的關鍵工作是檢測到用戶apc隊列不為空，就又將UserApcPending標志置于TRUE。

?

?

?

前面我們看到的是用戶apc隊列的執行機制與時機，那是用戶apc唯一的執行時機。內核apc隊列中的apc執行時機是不相同的，而且有很多執行時機。

內核apc的執行時機主要有：

1、?每次返回用戶空間前，每執行一個用戶apc前，就會掃描執行整個內核apc隊列

2、?每當調用KeLowerIrql,從APC_LEVEL以上（不包括APC_LEVEL）?降到?APC_LEVEL以下（不包括APC_LEVEL）前，中途會檢查是否有阻塞的apc中斷請求，若有就掃描執行內核apc隊列

3、?每當線程重新得到調度，開始運行前，會掃描執行內核apc隊列?或者?發出apc中斷請求

內核apc的執行時機：【調度、返、降】apc

?

?

KeLowerIrql實質上是下面的函數：

VOID?FASTCALL

KfLowerIrql(IN?KIRQL?OldIrql)

{

????ULONG?EFlags;

????ULONG?PendingIrql,?PendingIrqlMask;

????PKPCR?Pcr?=?KeGetPcr();

????PIC_MASK?Mask;

????EFlags?=?__readeflags();//保存原eflags

????_disable();//關中斷

Pcr->Irql?=?OldIrql;//降到目標irql

//檢測是否有高于目標irql的阻塞中的軟中斷

????PendingIrqlMask?=?Pcr->IRR?&?FindHigherIrqlMask[OldIrql];

????if?(PendingIrqlMask)//若有

????{

????????BitScanReverse(&PendingIrql,?PendingIrqlMask);//找到最高級別的軟中斷

????????if?(PendingIrql?>?DISPATCH_LEVEL)

????????{

????????????Mask.Both?=?Pcr->IDR;

????????????__outbyte(PIC1_DATA_PORT,?Mask.Master);

????????????__outbyte(PIC2_DATA_PORT,?Mask.Slave);

????????????Pcr->IRR?^=?(1?<<?PendingIrql);

????????}

????????SWInterruptHandlerTable[PendingIrql]();//處理阻塞的軟中斷（即掃描執行隊列中的函數）

????}

????__writeeflags(EFlags);//恢復原eflags

}

?

這個函數在從當前irql降到目標irql時，會按irql高低順序執行各個軟中斷的isr。

軟中斷是用來模擬硬件中斷的一種中斷。

#define?PASSIVE_LEVEL???????????0

#define?APC_LEVEL???????????????1

#define?DISPATCH_LEVEL??????????2

#define?CMCI_LEVEL??????????????5

比如，當調用KfLowerIrql要將cpu的irql從CMCI_LEVEL降低到PASSIVE_LEVEL時，這個函數中途會先看看當前cpu是否收到了CMCI_LEVEL級的軟中斷，若有，就調用那個軟中斷的isr處理之。然后，再檢查是否收到有DISPATCH_LEVEL級的軟中斷，若有，調用那個軟中斷的isr處理之，然后，檢查是否有APC中斷，若有，同樣處理之。最后，降到目標irql，即PASSIVE_LEVEL。

換句話說，在irql的降低過程中會一路檢查、處理中途的軟中斷。Cpu數據結構中有一個IRR字段，即表示當前cpu累積收到了哪些級別的軟中斷。

?

?

下面的函數可用于模擬硬件，向cpu發出任意irql級別的軟中斷，請求cpu處理執行那種中斷。

VOID?FASTCALL

HalRequestSoftwareInterrupt(IN?KIRQL?Irql)//Irql一般是APC_LEVEL/DPC_LEVEL

{

????ULONG?EFlags;

????PKPCR?Pcr?=?KeGetPcr();

????KIRQL?PendingIrql;

????EFlags?=?__readeflags();//保存老的eflags寄存器

????_disable();//關中斷

????Pcr->IRR?|=?(1?<<?Irql);//關鍵。標志向cpu發出了一個對應irql級的軟中斷

PendingIrql?=?SWInterruptLookUpTable[Pcr->IRR?&?3];//IRR后兩位表示是否有阻塞的apc中斷

//若有阻塞的apc中斷，并且當前irql是PASSIVE_LEVEL,立即執行apc。也即在PASSIVE_LEVEL級時發出任意軟中斷后，會立即檢查執行現有的apc中斷。

if?(PendingIrql?>?Pcr->Irql)

?SWInterruptHandlerTable[PendingIrql]();//調用執行apc中斷的isr，處理apc中斷

????__writeeflags(EFlags);//恢復原eflags寄存器

}

?

那么什么時候，系統會調用這個函數，向cpu發出apc中斷呢？

典型的情形1：

在切換線程時，若將線程的WaitIrql置為APC_LEVEL,將導致KiSwapContextInternal函數內部在重新切回來后，立即自動發出一個apc中斷，以在下次降低irql到PASSIVE_LEVEL時處理執行隊列中那些阻塞的apc。反之，若將線程的WaitIrql置為PASSIVE_LEVEL,將導致KiSwapContextInternal函數內部在重新切回來后，不會發出apc中斷，然后系統會自行顯式調用KiDeliverApc給予掃描執行

?

典型情形2：

在給自身線程發送一個內核apc時，在apc進隊的同時，會發出apc中斷，以請求cpu在下次降低irql時，掃描執行apc。

?

?

?

Apc是一種軟中斷，既然是中斷，他也有類似的isr。Apc中斷的isr最終進入?HalpApcInterruptHandler

VOID?FASTCALL

HalpApcInterruptHandler(IN?PKTRAP_FRAME?TrapFrame)

{

????//模擬硬件中斷壓入保存的寄存器

????TrapFrame->EFlags?=?__readeflags();

????TrapFrame->SegCs?=?KGDT_R0_CODE;

????TrapFrame->Eip?=?TrapFrame->Eax;

????KiEnterInterruptTrap(TrapFrame);//構造Trap現場幀

????掃描執行當前線程的內核apc隊列，略…

????KiEoiHelper(TrapFrame);?

}

轉載于:https://www.cnblogs.com/jadeshu/p/10663609.html

總結

以上是生活随笔為你收集整理的[6]Windows内核情景分析 --APC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。