I previously described the behavior of the kernel mode to user mode exception dispatcher (KiUserExceptionDispatcher). While exceptions are arguably the most commonly seen of the kernel mode to user mode “callbacks” in NTDLL, they are not the only such event.
Much like exceptions that traverse into user mode, user mode APCs are all (with the exception of initial thread startup) funneled through a single dispatcher routine inside NTDLL, KiUserApcDispatcher. KiUserApcDispatcher is responsible for invoking the actual APC routine, re-testing for APC delivery (to allow for the entire APC queue to be drained at once), and returning to the return point of the alertable system call that was interrupted to deliver the user mode APC. From the perspective of the user mode APC dispatcher, the stack is logically arranged as if the APC dispatcher would “return” to the instruction immediately following the syscall instruction in the system call that began the alertable wait.
For example, if we breakpoint on KiUserApcDispatcher and examine the stack (in this case, after an alertable WaitForSingleObjectEx call that has been interrupted to deliver a user mode APC), we might see the following:
Breakpoint 0 hit ntdll!KiUserApcDispatcher: 00000000`77691f40 488b0c24 mov rcx,qword ptr [rsp] 0:000> k RetAddr Call Site 00000000`776902ba ntdll!KiUserApcDispatcher 00000000`7746d820 ntdll!NtWaitForSingleObject+0xa 00000000`01001994 kernel32!WaitForSingleObjectEx+0x9c 00000000`01001eb0 TestApp!wmain+0x64 00000000`7746cdcd TestApp!__tmainCRTStartup+0x120 00000000`7768c6e1 kernel32!BaseThreadInitThunk+0xd 00000000`00000000 ntdll!RtlUserThreadStart+0x1d
From an implementation standpoint, KiUserApcDispatcher is conceptually fairly simple. I’ve posted a translation of the assembler for those interested. Keep in mind, however, that as with the other kernel mode to user mode callbacks, the routine is actually written in assembler and utilizes constructs not expressible through C, such as a custom calling convention.
Note that the APC routine invoked by KiUserApcDispatcher corresponds roughly to a standard native APC routine, specifically a PKNORMAL_ROUTINE (except on x64, but more on that later). This is not compatible with the Win32 view of an APC routine, which takes a single parameter, as opposed to be three that a KNORMAL_ROUTINE takes. As a result, there is a kernel32 function, BaseDispatchAPC that wrappers all Win32 APCs, providing an SEH frame around the call (and activating the appropriate activation context, if necessary). BaseDispatchAPC also converts from the native APC calling convention into the Win32 APC calling convention.
For Win32 I/O completion routines, a similar wrapper routine (BasepIoCompletion) serves the purpose of converting from the standard NT APC calling convention to the Win32 I/O completion callback calling convention (which primarily includes unpackaging any I/O completion parameters from the IO_STATUS_BLOCK).
With Windows x64, the behavior of KiUserApcDispatcher changes slightly. Specifically, the APC routine invoked has four parameters instead of the standard set of three parameters for a PKNORMAL_ROUTINE. This is still compatible with standard NT APC routines due to a quirk of the x64 calling convention, whereby the first four arguments are passed by register. (This means that internally, any routines with zero through four arguments that fit within the confines of a standard pointer-sized argument slot are “compatible”, at least from a calling convention perspective.)
The fourth parameter added by KiUserApcDispatcher in the x64 case is a pointer to the context record that is to be resumed when the APC dispatching process is finished. This additional argument is used by Wow64.dll if the process is a Wow64 process, as Wow64.dll wrappers all 32-bit APC routines around a thunk routine (Wow64ApcRoutine). Wow64ApcRoutine internally uses this extra PCONTEXT argument to take control of resuming execution after the real APC routine is invoked. Thus in the 64-bit NTDLL Wow64 case, the NtContinue call following the call to the user APC routine never occurs.
Next time, we’ll take a look at the other kernel mode to user mode exception “callback”, KiRaiseUserExceptionDispatcher.
[…] KiUserApcDispatcher […]
[…] ÐŸÐ¾Ð»ÐµÐ·Ð½Ð°Ñ ÑÑылка Ð´Ð»Ñ Ñ‚ÐµÑ…, кто интереÑуетÑÑ Ð´ÐµÑ‚Ð°Ð»Ñми: http://www.nynaeve.net/?p=202 […]
[…] ÐŸÐ¾Ð»ÐµÐ·Ð½Ð°Ñ ÑÑылка Ð´Ð»Ñ Ñ‚ÐµÑ…, кто интереÑуетÑÑ Ð´ÐµÑ‚Ð°Ð»Ñми: http://www.nynaeve.net/?p=202 […]
“This is still compatible with standard NT APC routines due to a quirk of the x64 calling convention, whereby the first four arguments are passed by register. (This means that internally, any routines with zero through four arguments that fit within the confines of a standard pointer-sized argument slot are “compatibleâ€, at least from a calling convention perspective.)”
Actually, it is even better than this. x64 has only one calling convention, and that calling convention support varargs, which means this works with any number of parameters. With the Win32 __stdcall this never would have worked due to callee-clean, but because x64 and IA64 has only one calling convention this works.