亚洲精品国产日韩,欧美精品成人,欧美电影免费观看高清完整版

LISTVIEW_LButtonDown

shaker(太子) — Thu, 15 Sep 2011 13:45:00 GMT

摘要: 阅读全文

shaker(太子) 2011-09-15 21:45 发表评论

[zt] Windows APC机制

shaker(太子) — Thu, 05 May 2011 04:09:00 GMT

异步�q�程调用(APCs) 是NT异步处理体系�l�构中的一个基��部分�Q�理解了它，对于了解NT怎样操作和执行几个核心的�pȝ��操作很有帮助�?/p>

1) APCs允许用户�E�序和系�l�元件在一个进�E�的地址�I�间内某个线�E�的上下文中执行代码�?br>2) I/O��理器��用APCs来完成一个线�E�发��L��异步的I/O操作。例如：当一个设备驱动调用IoCompleteRequest来通知I/O��理器，它已�l�结束处理一个异步I/O��h��Ӟ��I/O��理器排队一个apc到发赯��求的�U�程。然后线�E�在一个较低IRQL�U�别�Q�来执行APC. APC的作用是从系�l�空间拷贝I/O操作�l�果和状态信息到�U�程虚拟内存�I�间的一个缓冲中�?br>3) 使用APC可以得到或者设�|�一个线�E�的上下文和挂�v�U�程的执行�?/p>

上面是网上找来的�Q�下面是MSDN上的说明�Q?/p>

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.

�q�先看一下那些重要结构：

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
…………

…………

上面�U�色部分是APC机制用到的几个字�D�！�Q?/p>

kd> dt _KAPC_STATE
nt!_KAPC_STATE
+0x000 ApcListHead : [2] _LIST_ENTRY�Q�每个指针指向_KAPC�l�构
+0x010 Process : Ptr32 _KPROCESS
+0x014 KernelApcInProgress : UChar
+0x015 KernelApcPending : UChar
+0x016 UserApcPending : UChar

昄��Q�这里的 ApcListHead ��是 APC 队列头。不�q�这是个大小�?2 的数�l�，说明实际
�?每个�U�程)有两�?APC 队列。这是因�?APC 函数分�ؓ用户 APC 和内�?APC 两种�Q�各�?br>各的队列。所谓用�?APC�Q�是指相应的 APC 函数位于用户�I�间、在用户�I�间执行�Q�而内�?br>APC�Q�则相应�?APC 函数为内核函数�?/p>

SavedApcState也是个_KAPC_STATE�l�构�Q�当当前�E�暂�?#8220;挂靠(Attach)”到另一个进�E�的地址�I�间的时侯，ApcState��拷贝到SavedApcState暂时存放�Q?/p>

当然�Q�还要有状态信息说明本�U�程当前是处�?#8220;原始环境”�q�是“挂靠环境”�Q�这��是 ApcStateIndex 的作用，代码中�ؓ ApcStateIndex的值定义了一�U�枚丄��型：

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

实际可用�?ApcStateIndex 的只�?OriginalApcEnvironment�?AttachedApcEnvironment�?/p>

KAPC_STATE 指针数组 ApcStatePointer[2]�Q�就用ApcStateIndex 的当前��g��Z��标，而数�l�中的指针则�Ҏ��情况可以分别指向两个APC_STATE 数据�l�构中的一个�?/p>

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 函数的请求者所提供的函敎ͼ�其余两个都是辅助性的�Q?/p>

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
);

�q�个函数主要用来初始化Apc�Q�_KAPC�Q�这个结构的�Q�如果Environment==CurrentApcEnvironment,Apc->ApcStateIndex��q��KTHREAD中的ApcStateIndex军_��Q�但Environment不能大于KTHREAD中的ApcStateIndex�Q?/p>

最后，APC ��h��的模式ProcessorMode�Q�但是有个例外，那就是：如果指针NormalRoutine �?0�Q�那么实际的模式变成�?KernelMode。这是因为在�q�种情况下没有用��L��间APC函数可以执行�Q?唯一��得到执行的是KernelRoutine�Q?/p>

最后，KeInitializeApc 讄��Inserted域�ؓFALSE。然而初始化APC对象�Q��ƈ没有把它存放到相应的APC队列中�?/p>

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

据APC��h��的具体情况，有时候要插在队列的前��_��一般则挂在队列的尾部�?/p>

_KiServiceExit:

cli ; disable interrupts
DISPATCH_USER_APC ebp, ReturnCurrentEax

;
; Exit from SystemService
;

EXIT_ALL NoRestoreSegs, NoRestoreVolatile ;�q�个宏以后再�?/p>

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 ;条�g宏汇�~�，如果ReturnCurrentEax参数不�ؓ�I�，则编译！

;DISPATCH_USER_APC ebp, ReturnCurrentEax�Q�显然这里是�~�译的！
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 ;同上分析
mov eax, [ebx].TsEax ; Restore eax, just in case
endif

cli
jmp b ; 注意�q�个循环�Q�！

ALIGN 4
a:
endm

�q�段代码主要��查：

卛_��q�回的是否用��L��间�?br>是否有用户APC��h��正在�{�待执行

条�g�W�合才用KiDeliverApc真正投递APC。注意代码jmp b�Q�好像在�q�回用户�I�间前KiDeliverApc会被循环调用直到没有user APC�Q�其实不是的�Q�KiDeliverApc每处理完一个User APC��把UserApcPending清零�Q�所以User APCs在返回用��L��间时�q�是只能投递一�ơ！KiDeliverApc中用while处理完所有Kernel Mode APCs�Q�但User Mode APC却只处理一个！事实上User APC的投递是很特�D�的�Q�以后会讲到�Q�而且每次只能投递一�ơ！

前面讲过�Q�KTHREAD 中有两个 KAPC_STATE 数据�l�构�Q�一个是 ApcState�Q�另一个是SavedApcState�Q�二者都有APC 队列�Q�但是要投递的只是ApcState 中的队列�?/p>

KiDeliverApc (
IN KPROCESSOR_MODE PreviousMode,//写成DeliverMode不是更好
IN PKEXCEPTION_FRAME ExceptionFrame,//�q�个参数几乎��是0
IN PKTRAP_FRAME TrapFrame
)

�q�个函数里面�q�比较复杂，代码不帖了�?/p>

参数PreviousMode表示需�?#8220;投�?#8221;哪一�U?APC�Q�可以是UserMode�Q�也可以是KernelMode。不�q�，KernelMode ��实表示只要求执行内�?APC�Q�而UserMode 却表�C�在执行内核 APC 之外再执行用户APC�?/p>

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. �Q�run IRQL = PASSIVE_LEVEL�Q?br>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.
从代码的角度看是�q�样的：

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肯定不�ؓ�I�。�ƈ且，如果NormolRoutine也不为空�Q�那么KernelRoutine都在NormolRoutine被调用前被调用！�Q?/p>

上文中讲到投递User Mode APCs是很�Ҏ��的，道理很简单，因�ؓUser Mode APC是ring3下的回调函数�Q�显然ring0中的KiDeliverAPC�Q�）不能像Kernel Mode APC那样直接call�Q�必��要先回到ring3环境下。当然不能像普通情况那栯��回（否则��回到ring3�pȝ��调用的地方了�Q�，只有一个办法，那就是修改TrapFrame �Q�欺骗系�l�返�?#8220;APC回调函数”�Q�KiInitializeUserApc��是�q�么做的�Q?/p>

该函数首先把TrapFrame转化为ContextFrame�Q�然后移动用��h��ESP指针�Q�分配大�U�sizeof�Q�CONTEXT�Q?sizeof�Q�KAPC_RECORD�Q�个字节:

UserStack-> ……

KAPC_RECORD

……

CONTEXT

TopOfStack-> ……

KAPC_RECORD��是KiInitializeUserApc的最后四个参�?/p>

nt!_KAPC_RECORD

+0x000 NormalRoutine : Ptr32 void

+0x004 NormalContext : Ptr32 Void

+0x008 SystemArgument1 : Ptr32 Void

+0x00c SystemArgument2 : Ptr32 Void

CONTEXT�l�构主要来存放被修改前的TrapFrame�Q�之所以用CONTEXT�l�构是跟APC函数�q�回有关�Q?/p>

TrapFrame->HardwareEsp = UserStack;

TrapFrame->Eip = (ULONG)KeUserApcDispatcher;

TrapFrame->ErrCode = 0;

从上面的代码看到��实修改了TrapFrame�Q��ƈ且返回到的是ring3下的KeUserApcDispatcher�Q�刚才说的_KAPC_RECORD其实也是它的参数�Q�真正我们的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�l�构

call _ZwContinue@8

;;不会�q�回到这里的

上面的代码�ƈ不难理解�Q�我们的User APC回调函数�q�回后，立即调用了ZwContinue�Q�这是个ntdll中的导出函数�Q�这个函数又通过�pȝ��调用�q�入kernel中的NtContinue�Q?/p>

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,

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, ; test alert for current thread

;如果User APCs不�ؓ�I�，它会讄��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�l�构转化成TrapFrame�Q�回复原来的陷阱帧）�Q�然后就从KiServiceExit2处退出系�l�调用！

;++

;

; _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差不多，只是宏参数的不同!同样如果�q�有User APC又会�q�入上文描述的情形，直到没有User APC�Q�至此才会返回真正发起原始系�l�调用的地方�Q?/p>

本文来自CSDN博客�Q��{载请标明出处�Q?a >http://blog.csdn.net/better0332/archive/2009/06/29/4306683.aspx

shaker(太子) 2011-05-05 12:09 发表评论

shaker(太子) — Thu, 05 May 2011 03:46:00 GMT

异步�q�程调用(APCs) 是NT异步处理体系�l�构中的一个基��部分�Q�理解了它，对于了解NT怎样操作和执行几个核心的�pȝ��操作很有帮助�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
1) APCs允许用户�E�序和系�l�元件在一个进�E�的地址�I�间内某个线�E�的上下文中执行代码�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">2) I/O��理器��用APCs来完成一个线�E�发��L��异步的I/O操作。例如：当一个设备驱动调用IoCompleteRequest来通知I/O��理器，它已�l�结束处理一个异步I/O��h��Ӟ��I/O��理器排队一个apc到发赯��求的�U�程。然后线�E�在一个较低IRQL�U�别�Q�来执行APC. APC的作用是从系�l�空间拷贝I/O操作�l�果和状态信息到�U�程虚拟内存�I�间的一个缓冲中�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">3) 使用APC可以得到或者设�|�一个线�E�的上下文和挂�v�U�程的执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
��管APCs在nt体系�l�构下被�q�泛使用�Q�但是关于怎样使用它的文档却非常的�~�Z��。本��我们详�l�介�l�下nt�pȝ��是怎样处理APCs的，�q�且记录导出的nt函数�Q�方便设备驱动开发者在他们的程序中使用APCs。我也会展示一个非常可靠的NT的APC调度子程序KiDeliverApc的实玎ͼ�来帮助你更好的掌握APC调度的内�q��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
APC对象

在NT中，有两�U�类型的APCs�Q�用��h��式和内核模式。用户APCs�q�行在用��h��式下目标�U�程当前上下文中�Q��ƈ且需要从目标�U�程得到许可来运行。特别是�Q�用��h��式的APCs需要目标线�E�处在alertable�{�待状态才能被成功的调度执行。通过调用下面��L��一个函敎ͼ�都可以让�U�程�q�入�q�种状态。这些函数是�Q�KeWaitForSingleObject, KeWaitForMultipleObjects, KeWaitForMutexObject, KeDelayExecutionThread�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">对于用户模式下，可以调用函数SleepEx, SignalObjectAndWait, WaitForSingleObjectEx, WaitForMultipleObjectsEx,MsgWaitForMultipleObjectsEx 都可以��目标�U�程处于alertable�{�待状态，从而让用户模式APCs执行,原因是这些函数最�l�都是调用了内核中的KeWaitForSingleObject, KeWaitForMultipleObjects, KeWaitForMutexObject, KeDelayExecutionThread�{�函数。另外通过调用一个未公开的alert-test服务KeTestAlertThread�Q�用��L��E�可以��用户模式APCs执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
当一个用��h��式APC被投递到一个线�E�，调用上面的等待函敎ͼ�如果�q�回�{�待状态STATUS_USER_APC�Q�在�q�回用户模式�Ӟ��内核转去控制APC例程�Q�当APC例程完成后，再��l�线�E�的执行.

和用��h��式APCs比较�Q�内核模式APCs执行在内核模式下。可以被划分为常规的和特�D�的两类。当APCs被投递到一个特�D�的�U�程�Q�特�D�的内核模式APCs不需要从�U�程得到许可来运行。然而，常规的内核模式APCs在他们成功执行前�Q�需要有特定的环境。此外，�Ҏ��的内核APC被尽可能快地执行�Q�既只要APC_LEVEL�U�上有可调度的活动。在很多情况下，�Ҏ��的内核APC甚至能唤醒阻塞的�U�程。普通的内核APC仅在所有特�D�APC都被执行完，�q�且目标�U�程仍在�q�行�Q�同时该�U�程中也没有其它内核模式APC正执行时才执行。用��h��式APC在所有内核模式APC执行完后才执行，�q�且仅在目标�U�程有alertable属性时才执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
每一个等待执行的APC都存在于一个线�E�执行体�Q�由内核��理的队列中。系�l�中的每一个线�E�都包含两个APC队列�Q�一个是为用��h��式APCs,另一个是为内核模式APCs的�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">NT通过一个成为KAPC的内核控制对象来描述一个Ａ�Q��E�Q�尽��Ｄ�Q��O中没有明��的文档化Ａ�Q��Eｓ，但是在NTDDK.H中却非常清楚的定义了�Q�Ｐ�Q�对象。从下面的KAPC对象的定义看�Q�有些是不需要说明的。像Type和Size。Type表示了这是一个APC内核对象。在nt中，每一个内核对象或者执行体对象都有Type和Size�q�两个域。由此处理函数可以确定当前处理的对象。Size表示一个字寚w��的结构体的大��。也��是指明了对象占的内存空间大��。Spare0看�v来有些晦涩难懂，但是它是没用什么�Q何深�q�的意义�Q�仅仅是��Z��内存补齐。其他的域将在下面的��幅中介�l��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
//-------------------------------------------------------------------------------------------------------

几个函数声明和结构定义：

typedef struct _KAPC {
CSHORT Type;
CSHORT Size;
ULONG Spare0;
struct _KTHREAD *Thread;
LIST_ENTRY ApcListEntry;
PKKERNEL_ROUTINE KernelRoutine;
PKRUNDOWN_ROUTINE RundownRoutine;
PKNORMAL_ROUTINE NormalRoutine;
PVOID NormalContext;
//
// N.B. The following two members MUST be together.
//
PVOID SystemArgument1;
PVOID SystemArgument2;
CCHAR ApcStateIndex;
KPROCESSOR_MODE ApcMode;
BOOLEAN Inserted;
} KAPC, *PKAPC, *RESTRICTED_POINTER PRKAPC;
//------

APC环境

一个线�E�在它执行的��L��时刻�Q�假讑ֽ�前的IRQL是在Passive�U�，它可能需要��时在其他的进�E�上下文中执行代码，��Z��完成�q�个操作�Q�线�E�调用系�l�功能函数KeAttachProcess�Q�在从这个调用返回时�Q�线�E�执行在另一个进�E�的地址�I�间。先前所有在�U�程自己的进�E�上下文中等待执行的APCs,�׃��q�时其所属进�E�的地址�I�间不是当前可用的，因此他们不能被投递执行。然而，新的插入到这个线�E�的APCs可以执行在这个新的进�E�空间。甚臛_��U�程最后从新的�q�程中分��L��Q�新的插入到�q�个�U�程的APCs�q�可以在�q�个�U�程所属的�q�程上下文中执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">��Z��辑ֈ�控制APC传送的�q�个�E�度�Q�NT中每个线�E�维护了两个APC环境或者说是状态。每一个APC环境包含了用��h��式的APC队列和内核模式的APC队列�Q�一个指向当前进�E�对象的指针和三个控制变量，用于指出�Q�是否有未决的内核模式APCs(KernelApcPending),是否有常规内核模式APC在进行中(KernelApcInProgress)�Q�是否有未决的用��h��式的APC(UserApcPending). �q�些APC的环境保存在�U�程对象的ApcStatePointer域中。这个域是由2个元素组成的数组。即�Q?0x138 ApcStatePointer : [2] Ptr32 _KAPC_STATE

typedef struct _KAPC_STATE {
LIST_ENTRY ApcListHead[MaximumMode];
struct _KPROCESS *Process;
BOOLEAN KernelApcInProgress;
BOOLEAN KernelApcPending;
BOOLEAN UserApcPending;
} KAPC_STATE, *PKAPC_STATE, *PRKAPC_STATE;

lkd> dt _kthread
ntdll!_KTHREAD
+0x000 Header : _DISPATCHER_HEADER
+0x010 MutantListHead : _LIST_ENTRY
+0x018 InitialStack : Ptr32 Void
+0x01c StackLimit : Ptr32 Void
+0x020 Teb : Ptr32 Void
+0x024 TlsArray : Ptr32 Void
+0x028 KernelStack : Ptr32 Void
+0x02c DebugActive : UChar
+0x02d State : UChar
+0x02e Alerted : [2] UChar
+0x030 Iopl : UChar
+0x031 NpxState : UChar
+0x032 Saturation : Char
+0x033 Priority : Char
+0x034 ApcState : _KAPC_STATE
+0x04c ContextSwitches : Uint4B
+0x050 IdleSwapBlock : UChar
+0x051 Spare0 : [3] UChar
+0x054 WaitStatus : Int4B
+0x058 WaitIrql : UChar
+0x059 WaitMode : Char
+0x05a WaitNext : UChar
+0x05b WaitReason : UChar
+0x05c WaitBlockList : Ptr32 _KWAIT_BLOCK
+0x060 WaitListEntry : _LIST_ENTRY
+0x060 SwapListEntry : _SINGLE_LIST_ENTRY
+0x068 WaitTime : Uint4B
+0x06c BasePriority : Char
+0x06d DecrementCount : UChar
+0x06e PriorityDecrement : Char
+0x06f Quantum : Char
+0x070 WaitBlock : [4] _KWAIT_BLOCK
+0x0d0 LegoData : Ptr32 Void
+0x0d4 KernelApcDisable : Uint4B
+0x0d8 UserAffinity : Uint4B
+0x0dc SystemAffinityActive : UChar
+0x0dd PowerState : UChar
+0x0de NpxIrql : UChar
+0x0df InitialNode : UChar
+0x0e0 ServiceTable : Ptr32 Void
+0x0e4 Queue : Ptr32 _KQUEUE
+0x0e8 ApcQueueLock : Uint4B
+0x0f0 Timer : _KTIMER
+0x118 QueueListEntry : _LIST_ENTRY
+0x120 SoftAffinity : Uint4B
+0x124 Affinity : Uint4B
+0x128 Preempted : UChar
+0x129 ProcessReadyQueue : UChar
+0x12a KernelStackResident : UChar
+0x12b NextProcessor : UChar
+0x12c CallbackStack : Ptr32 Void
+0x130 Win32Thread : Ptr32 Void
+0x134 TrapFrame : Ptr32 _KTRAP_FRAME
+0x138 ApcStatePointer : [2] Ptr32 _KAPC_STATE
+0x140 PreviousMode : Char
+0x141 EnableStackSwap : UChar
+0x142 LargeStack : UChar
+0x143 ResourceIndex : UChar
+0x144 KernelTime : Uint4B
+0x148 UserTime : Uint4B
+0x14c SavedApcState : _KAPC_STATE
+0x164 Alertable : UChar
+0x165 ApcStateIndex : UChar
+0x166 ApcQueueable : UChar
+0x167 AutoAlignment : UChar
+0x168 StackBase : Ptr32 Void
+0x16c SuspendApc : _KAPC
+0x19c SuspendSemaphore : _KSEMAPHORE
+0x1b0 ThreadListEntry : _LIST_ENTRY
+0x1b8 FreezeCount : Char
+0x1b9 SuspendCount : Char
+0x1ba IdealProcessor : UChar
+0x1bb DisableBoost : UChar

主APC环境是位于线�E�对象的ApcState 域，卻I��
+0x034 ApcState : _KAPC_STATE

�U�程中等待在当前�q�程上下文中执行的APC保存在ApcState的队列中。无��Z��Ӟ��NT的APC�z�֏��?dispatcher)和其他系�l�元件查询一个线�E�未决的APCs�? 他们都会��查主APC环境�Q�如果这里有��M��未决的APCs,��׃��马上被投递，或者修改它的控制变量稍后投递�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
�W�二个APC环境是位于线�E�对象的SavedApcState域，当线�E��时挂接到其他�q�程�Ӟ��它是用来备䆾主APC环境的�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
当一个线�E�调用KeAttachProcess�Q�在另外的进�E�上下文中执行后�l�的代码�Ӟ��ApcState域的内容��p��拯��到SavedApcState域。然后ApcState域被清空�Q�它的APC队列重新初始化，控制变量讄��?�Q�当前进�E�域讄��为新的进�E�。这些步骤成功的��保先前在线�E�所属的�q�程上下文地址�I�间中等待的APCs�Q�当�U�程�q�行在其它不同的�q�程上下文时�Q�这些APCs不被传送执行。随后，ApcStatePointer域数�l�内容被更新来反映新的状态，数组中第一个元素指向SavedApcState域，�W�二个元素指向ApcState域，表明�U�程所属进�E�上下文的APC环境位于SavedApcState域。线�E�的新的�q�程上下文的APC环境位于ApcState域。最后，当前�q�程上下文切换到新的�q�程上下文�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
对于一个APC对象�Q�决定当前APC环境的是ApcStateIndex域。ApcStateIndex域的��g��为ApcStatePointer域数�l�的索引来得到目标APC环境指针。随后，目标APC环境指针用来在相应的队列中存放apc对象.

当线�E�从新的�q�程中脱��L��(KeDetachProcess), ��M��在新的进�E�地址�I�间中等待执行的未决的内核APCs被派发执行。随后SavedApcState 域的内容被拷贝回ApcState域。SavedApcState 域的内容被清�I�，�U�程的ApcStateIndex域被设�ؓOriginalApcEnvironment�Q�ApcStatePointer域更斎ͼ�当前�q�程上下文切换到�U�程所属进�E��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
使用APCs

讑֤�驱动�E�序使用两个主要函数来利用APCs, �W�一个是KeInitializeApc�Q�用来初始化APC对象。这个函数接受一个驱动分配的APC对象�Q�一个目标线�E�对象指针，APC环境索引�Q�指出APC对象存放于哪个APC环境�Q�，APC的kernel,rundown和normal例程指针�Q�APC�c�d��Q�用��h��式或者内核模式）和一个上下文参数�?函数声明如下�Q?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NTKERNELAPI
VOID
KeInitializeApc (
IN PRKAPC Apc,
IN PKTHREAD Thread,
IN KAPC_ENVIRONMENT Environment,
IN PKKERNEL_ROUTINE KernelRoutine,
IN PKRUNDOWN_ROUTINE RundownRoutine OPTIONAL,
IN PKNORMAL_ROUTINE NormalRoutine OPTIONAL,
IN KPROCESSOR_MODE ApcMode,
IN PVOID NormalContext
);

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

KeInitializeApc 首先讄��APC对象的Type和Size域一个适当的��|��然后��查参数Environment的��|��如果是CurrentApcEnvironment�Q�那么ApcStateIndex域设�|��ؓ目标�U�程的ApcStateIndex域。否则，ApcStateIndex域设�|��ؓ参数Environment的倹{��随后，函数直接用参数设�|�APC对象Thread�Q�RundownRoutine�Q�KernelRoutine域的倹{��ؓ了正��地��定APC的类型，KeInitializeApc ��查参数NormalRoutine的��|��如果是NULL�Q�ApcMode域的��D��|��ؓKernelMode�Q�NormalContext域设�|��ؓNULL。如果NormalRoutine的��g��是NULL�Q�这时候它一定指向一个有效的例程�Q�就用相应的参数来设�|�ApcMode域和NormalContext域。最后，KeInitializeApc 讄��Inserted域�ؓFALSE.然而初始化APC对象�Q��ƈ没有把它存放到相应的APC队列中�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
从这个解释看�Q�你可以了解到APCs对象如果�~�少有效的NormalRoutine�Q�就会被当作内核模式APCs.��其是它们会被认为是�Ҏ��的内核模式APCs.
实际上，I/O��理器就是用�q�类的APC来完成异步I/O操作。相反地�Q�APC对象定义了有效的NormalRoutine�Q��ƈ且ApcMode域是KernelMode�Q�就会被当作常规的内核模式APCs,否则��׃��被当作是用户模式APCs. NTDDK.H中KernelRoutine, RundownRoutine, and NormalRoutine 的定义如下：
typedef
VOID
(*PKKERNEL_ROUTINE) (
IN struct _KAPC *Apc,
IN OUT PKNORMAL_ROUTINE *NormalRoutine,
IN OUT PVOID *NormalContext,
IN OUT PVOID *SystemArgument1,
IN OUT PVOID *SystemArgument2
);

typedef
VOID
(*PKRUNDOWN_ROUTINE) (
IN struct _KAPC *Apc
);

typedef
VOID
(*PKNORMAL_ROUTINE) (
IN PVOID NormalContext,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2
);
//------------------

通常�Q�无论是什么类型，每个APC对象必须要包含一个有效的KernelRoutine 函数指针。当�q�个APC被NT的APC dispatcher传送执行时�Q�这个例�E�首先被执行。用��h��式的APCs必须包含一个有效的NormalRoutine 函数指针�Q�这个函数必��d��用户内存区域。同��L��Q�常规内核模式APCs也必��d��含一个有效的NormalRoutine�Q�但是它��像KernelRoutine一栯��行在内核模式。作为可选择的，��L��c�d��的APC都可以定义一个有效的RundownRoutine�Q�这个例�E�必��d��内核内存区域�Q��ƈ且仅仅当�pȝ��需要释放APC队列的内�Ҏ��Q�才被调用。例如线�E�退出时�Q�在�q�种情况下，KernelRoutine和NormalRoutine都不执行�Q�只有RundownRoutine执行。没有这个例�E�的APC对象会被删除�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
��C��Q�投递APCs��C��个线�E�的动作�Q�仅仅是操作�pȝ��调用KiDeliverApc完成的。执行APC实际上就是调用APC内的例程�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
一旦APC对象完成初始化后�Q�设备驱动调用KeInsertQueueApc来将APC对象存放到目标线�E�的相应的APC队列中。这个函数接受一个由KeInitializeApc完成初始化的APC对象指针�Q�两个系�l�参数和一个优先��增量。跟传递给KeInitializeApc函数的参数context 一��P��q�两个系�l�参数只是在APC的例�E�执行时�Q�简单的传递给APC的例�E��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NTKERNELAPI
BOOLEAN
KeInsertQueueApc (
IN PRKAPC Apc,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2,
IN KPRIORITY Increment
);
//-----------------
在KeInsertQueueApc ��APC对象存放到目标线�E�相应的APC队列之前�Q�它首先��查目标线�E�是否是APC queueable。如果不是，函数立即�q�回FALSE.如果是，函数直接用参数设�|�SystemArgument1域和SystemArgument2 域，随后�Q�函数调用KiInsertQueueApc来将APC对象存放到相应的APC队列�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
KiInsertQueueApc 仅仅接受一个APC对象和一个优先��增量。这个函数首先得到线�E�APC队列的spinlock�q�且持有它，防止其他�U�程修改当前�U�程的APC�l�构。随后，��查APC对象的Inserted 域。如果是TRUE,表明�q�个APC对象已经存放到APC队列中了�Q�函数立卌��回FALSE.如果APC对象的Inserted 域是FALSE.函数通过ApcStateIndex域来��定目标APC环境�Q�然后把APC对象存放到相应的APC队列中，卛_��APC对象中的ApcListEntry 域链入到APC环境的ApcListHead域中。链入的位置由APC的类型决定。常规的内核模式APC,用户模式APC都是存放到相应的APC队列的末端。相反的�Q�如果队列中已经存放了一些APC对象�Q�特�D�的内核模式APC存放到队列中�W�一个常规内核模式APC对象的前面。如果是内核定义的一个当�U�程退出时使用的用户APC,它也会被攑֜�相应的队列的前面。然后，�U�程的主APC环境中的UserApcPending域杯讄��为TRUE。这时KiInsertQueueApc 讄��APC对象的Inserted 域�ؓTRUE�Q�表明这个APC对象已经存放到APC队列中了。接下来�Q�检查这个APC对象是否被排队到�U�程的当前进�E�上下文APC环境中，如果不是�Q�函数立卌��回TRUE。如果这是一个内核模式APC�Q�线�E�主APC环境中的KernelApcPending域设�|��ؓTRUE�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
在WIN32 SDK文档中是�q�样描述APCs的：当一个APC被成功的存放到它的队列后�Q�发��Z��个��Y中断�Q�APC��会在线�E�被调度�q�行的下一个时间片执行。然而这不是完全正确的。这样一个��Y中断�Q�仅仅是当一个内核模式的APC�Q�无论是常规的内核模式APC�q�是�Ҏ��的内核模式APC�Q�针对于调用�U�程�Ӟ��才会发出。随后函数返回TRUE�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
1�Q�如果APC不是针对于调用线�E�，目标�U�程在Passive权限�{��处在�{�待状态；
2�Q�这是一个常规内核模式APC
3�Q�这个线�E�不再��界区
4�Q�没有其他的常规内核模式APC仍然在进行中
那么�q�个�U�程被唤醒，�q�回状态是STATUS_KERNEL_APC。但是等待状态没有aborted�?如果�q�是一个用��h��式APC�Q�KiInsertQueueApc��查判断目标线�E�是否是alertable�{�待状态，�q�且WaitMode域等于UserMode。如果是�Q�主APC环境的UserApcPending 域设�|��ؓTRUE。等待状态返回STATUS_USER_APC�Q�最后，函数释放spinlock�Q�返回TRUE�Q�表�C�APC对象已经被成功放入队列�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">早期作�ؓAPC��理函数的补充，讑֤�驱动开发者可以��用未公开的系�l�服务NtQueueApcThread来直接将一个用��h��式的APC投递到某个�U�程�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">�q�个函数内部实际上是调用了KeInitializeApc 和KeInsertQueueApc 来完成这个�Q务�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NTSYSAPI
NTSTATUS
NTAPI
NtQueueApcThread (
IN HANDLE Thread,
IN PKNORMAL_ROUTINE NormalRoutine,
IN PVOID NormalContext,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2
);

NT的APC�z�֏��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NT��查是否线�E�有未决的APCs. 然后APC�z�֏�器子�E�序KiDeliverApc在这个线�E�上下文执行来开始将未决的APC执行。注意，�q�个行�ؓ中断了线�E�的正常执行��程�Q�首先将控制权给APC�z�֏�器，随后当KiDeliverApc完成后，�l�箋�U�程的执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">例如�Q�当一个线�E�被调度�q�行�Ӟ��最后一步，上下文切换函�?SwapContext 用来��查是否新的线�E�有未决的内核APCs.如果是，SwapContext要么�Q?�Q�请求一个APC�U�别的��Y中断来开始APC执行�Q�由于新�U�程�q�行在低的IRQL�Q�Passive�U�别�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">或者（2�Q�返回TRUE�Q�表�C�新的线�E�有未决的内核APCs�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
�I�竟是执�?1)�q�是(2)取决于新�U�程所处的IRQL�U�别. 如果它的权限�U�别高于Passive�U?SwapContext 执行(1),如果它是在Passive�U?则选择执行(2).
SwapContext的返回��g��仅是特定�pȝ��函数可用�?�q�些�pȝ��函数调用SwapContext来强制切换线�E�上下文到另一个线�E? 然后,当这些系�l�函数经�q�一�D�|��间再�l�箋�?他们通常��查SwapContext 的返回�?如果是TRUE,他们��׃��调用APC�z�֏�器来投递内核APCs到当前的�U�程. 例如:
�pȝ��函数KiSwapThread被等待服务用来放弃处理器�Q�直到等待结束。这个函数内部调用SwapContext。当�{�待�l�束�Q��l�从调用SwapContext处执行时�Q�就会检查SwapContext的返回倹{��如果是TRUE�Q�KiSwapThread会降低IRQL�U�别到APC�U�，然后调用KiDeliverApc来在当前�U�程执行内核APCs.
对于用户APCs, 内核调用APC�z�֏�器仅仅是当线�E�回到用��h��式，�q�且�U�程的主APC环境的UserApcPending域�ؓTRUE时。例如：当系�l�服务派发器KiSystemService完成一个系�l�服务请求正打算回到用户模式�Ӟ��它会��查是否有未决的用户APCs。在执行上，KiDeliverApc调用用户APC的KernelRoutine. 随后�Q�KiInitializeUserApc函数被调用，用来讄��U�程的陷阱��。所以从内核模式退出时�Q�线�E�开始在用户模式下执�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">。KiInitializeUserApc的函数的作用是拷贝当前线�E�先前的执行状态（当进入内核模式时�Q�这个状态保存在�U�程内核栈创建的陷阱帧里�Q�，从内核栈到线�E�的用户模式栈，初始化用��h��式APC。APC�z�֏�器子�E�序KiUserApcDispatcher在Ntdll.dll内。最后，加蝲陷阱帧的EIP寄存器和Ntdll.dll中KiUserApcDispatcher的地址。当陷阱帧最后释放时�Q�内核将控制转交�l�KiUserApcDispatcher�Q�这个函数调用APC的NormalRoutine例程�Q�NormalRoutine函数地址以及参数都在栈中�Q�当例程完成�Ӟ��它调用NtContinue来让�U�程利用在栈中先前的上下文��l�执行，仿佛什么事情也没有发生�q��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">

当内核调用KiDeliverApc来执行一个用��h��式APC�Ӟ��U�程中的PreviousMode域被设�ؓUserMode. TrapFrame域指向线�E�的陷阱帧。当内核调用KiDeliverApc来执行内核APCs�Ӟ��U�程中的PreviousMode域被设�ؓKernelMode. TrapFrame域指向NULL�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">注意�Q�无��Z��时只要KernelRoutine被调用，传递给它的指针是一个局部的APC属性的副本�Q�由于APC对象已经��q��了队列，所以可以安全的在KernelRoutine中释放APC内存。此外，�q�个例程在它的参数被传递给其他例程之前�Q�有一个最后的��Z��来修改这些参数�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
�l�论�Q?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">APC提供了一个非常有用的机制�Q�允许在特定的线�E�上下文中异步的执行代码。作��Z��个设备驱动开发者，你可以依赖APCs在某个特定的�U�程上下文中执行一个例�E�，而不需要线�E�的许可和干涉。对于用户应用程序，用户模式APCs可以用来有效地实��C��些回调通知机制�?/span>

shaker(太子) 2011-05-05 11:46 发表评论