整體過程如下：
需要說明兩點：
1．在XP中，新進程主線程的啟動，會先執行一個用戶態的APC，會執行ntdll!LdrInitializeThunk進行程序執行前的一些列初始化操作。其中很重要任務就是加載從Kernel32.dll開始的系統DLL。注意的是，這個APC的插入，根據WRK中的代碼看來是在PspUserThreadStartup中進行的:
但實際調試XP SP3發現，該函數並未有這個動作。並且在進入這個函數的時候APC已經插入好了。於是追蹤到在XP SP3中，該APC的插入時機是在nt!PspCreateThread中進行的。
2.雖然XP和Win7都會在主線程Ring3入口（XP是BaseProcessStart，Win7是RtlUserThreadStart）前執行LdrInitializeThunk進行初始化，但二者細節處還是不同。
對於XP，如上所述，是通過nt!PspCreateThread在創建線程完成后插入APC，等到新進程主線程得到調度，在nt!KiThreadStartup完成后，跳到nt!_KiSystemExit處返回到用戶模式時，該APC得到交付從而執行到。
而對於Win7，創建進程路徑發生了大變化，不再有nt!PspCreateThread，而是nt! PspAllocateThread，這里面也沒有插入APC的動作。即使追蹤到nt!KiThreadStartup即將跳到nt!_KiSystemExit的位置，KTHREAD中的APC隊列仍然沒有LdrInitializeThunk這一項。按理說，這個時候返回就會到線程啟動入口ntdll!RtlUserThreadStart才對。那LdrInitializeThunk怎么會執行呢？調試發現，在即將跳到nt!_KiSystemExit的時候，線程的KTRAP_FRAME中的EIP已經是LdrInitializeThunk而不是RtlUserThreadStart了。進一步跟蹤發現，原來是在nt!PspCreateThread返回的前夕，通過nt!PspInitializeThunkContext—> nt!PspSetContextThreadInternal-->nt!PspGetSetContextSpecialApc-->nt!KeContextToKframes進行對KTRAP_FRAME進行修改了。通過函數名字也可以看出，這個動作是在模擬交付用戶模式APC的動作。
因此，總結一下就是，對於XP，是通過正常的插入APC的形式，在線程內核啟動函數完成后返回到用戶模式時，觸發了APC的交付。而對於Win7，則是在內核啟動函數完成時，模擬出一個APC交付的過程，提前修改了KTRAP_FRAME，等到返回到用戶模式時直接就從LdrInitializeThunk處開始執行。
LdrInitializeThunk執行完成后需要進入內核（通過NtContinue），重新進入到線程的用戶態執行入口。由於在XP中是通過APC進入的，所以這個工作就不用LdrInitializeThunk來做，APC的執行器ntdll!KiUserApcDispatcher會負責這件事。但在Win7上並非通過APC執行的，所以調用NtContinue的工作需要LdrInitializeThunk自己來完成了。
Win7: 
最后說一下，經常見到在LoadImageNotify回調中做（用戶態）APC注入。由圖可見exe&ntdll的回調通知和后面加載的dll回調通知執行的路徑不一樣。最開始這兩個模塊是在DbgkCreateThread中執行回調的，后面的是通過MmMapViewOfSection-->MiMapViewOfImageSection執行的回調。而MmMapViewOfSection在回調執行之前會通過LOCK_ADDRESS_SPACE進行進程地址空間的鎖定。這個時候再進行（用戶態）APC注入，在使用ZwAllocateVirtualMemory分配shellcode的內存空間時會卡死在這里。所以（用戶態）APC注入的時機是在ntdll的回調中，這之后就會面臨卡死的問題。