如何做混合用戶模式/內核模式調試？

Question

基本上，我有一個用戶模式程序調用kernel32.CreateProcessA（），它在內部調用kernel32.CreateProcessInternalW（）。在這個函數中，我對ntdll.NtCreateSection（）中發生的事情感興趣，它試圖在虛擬內存中映射可執行文件。一旦進入這個函數，程序會迅速將內核調用設置爲EAX = 0x32並執行SYSENTER指令。

很明顯，我看不到在用戶模式調試器的調用門之外。我有一些調試內核模式驅動程序的經驗，所以我在VMWare窗口中加載了XP SP3的副本，並使用VirtualKD將管道連接到WinDbg（我碰巧在IDA中運行）。在連接內核調試器之後，我將我的用戶模式EXE程序和PDB複製到虛擬機上，但我對如何正確設置用戶模式程序中的初始斷點感到困惑。我不想攔截所有對相當於ntdll.ZwCreateSection（）的調用，我相信它們位於調用門的另一邊。理想情況下，我想闖入用戶模式代碼，並逐步通過調用門，現在我正在使用內核調試器，但我不知道第一步是什麼。

我做了一些谷歌上搜索，我已經接近通過設置在

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\myprocess.exe 

這會導致內核調試器的暫停，當我開始我的過程「NTSD -D」的價值，但我可以在.breakin命令後面我似乎沒有設置任何斷點，我需要發送給IDA才能進入WinDbg提示符。我一直在關注這個guide，我在這裏找到了我的進程！進程然後切換到上下文並重新加載符號，但是我在設置我的進程中的斷點時出現了問題，或者超出了由「ntsd -d」設置的初始斷點。在得到消息指出斷點無法解析並添加了延遲斷點後，如果沒有任何意義，我似乎無法將進程「推入」進程而不清除斷點。這裏是哪裏，我似乎是在我擊球的時候，最初的休息堆棧：

ChildEBP RetAddr 
b2b55ccc 8060e302 nt!RtlpBreakWithStatusInstruction 
b2b55d44 8053d638 nt!NtSystemDebugControl+0x128 
b2b55d44 7c90e4f4 nt!KiFastCallEntry+0xf8 
0007b270 7c90de3c ntdll!KiFastSystemCallRet 
0007b274 6d5f5ca6 ntdll!ZwSystemDebugControl+0xc 
0007bd48 6d5f6102 dbgeng!DotCommand+0xd0d 
0007de8c 6d5f7077 dbgeng!ProcessCommands+0x318 
0007dec4 6d5bec6c dbgeng!ProcessCommandsAndCatch+0x1a 
0007eedc 6d5bed4d dbgeng!Execute+0x113 
0007ef0c 010052ce dbgeng!DebugClient::Execute+0x63 
0007ff3c 010069fb ntsd!MainLoop+0x1ec 
0007ff44 01006b31 ntsd!main+0x10e 
0007ffc0 7c817067 ntsd!mainCRTStartup+0x125 
0007fff0 00000000 kernel32!BaseProcessStart+0x23 

說實話，我不知道是正裝我的PDB，但我懷疑它可能不是我的眼前的問題;我的模塊窗格只顯示內核驅動程序模塊，而不是用戶模式模塊。在過去我一直在進行驅動程序調試時，我可以在此窗格中看到我的驅動程序映像，以及這些符號是否已加載，因此我不確定期望用戶模式映像的內容。 沒有圖像，我真的不希望調試器解決任何斷點。

我意識到我可能會對這個完全錯誤的，但我沒有任何運氣尋找如何做用戶模式/內核模式混合調試。有沒有人可以指出我正確的方向，所以我可以從特定的用戶模式進程進入這種內核模式功能？或者，至少設置一個適當的內核模式斷點，以便它僅在我的特定用戶模式進程中被觸發？

UPDATE： 我裝我的模塊（碰巧被命名爲runlist.exe）在調試OS上的用戶模式調試器（我碰巧使用OllyDbg的）。一旦我在用戶模式斷點處暫停，只有SYSENTER的幾條指令，我使用內核調試器暫停了操作系統。然後我設置流程上下文。 WinDbg的命令窗口，內容如下：

WINDBG>!process 0 0 runlist.exe 

PROCESS 820645a8 SessionId: 0 Cid: 01b4 Peb: 7ffd7000 ParentCid: 02b0 
    DirBase: 089c02e0 ObjectTable: e1671bb0 HandleCount: 8. 
    Image: runlist.exe 

WINDBG>.process /i /r /p 820645a8 
You need to continue execution (press 'g' <enter>) for the context 
to be switched. When the debugger breaks in again, you will be in 
the new process context. 
WINDBG>g 
This command cannot be passed to the WinDbg plugin directly, please use IDA Debugger menu to achieve the same result. 
Break instruction exception - code 80000003 (first chance) 
WINDBG>.reload /user 
Loading User Symbols 
.... 
Caching 'Modules'... ok 
WINDBG>lmu 
start end  module name 
00400000 00405000 runlist C (no symbols)   
7c340000 7c396000 MSVCR71 (private pdb symbols) g:\symcache\msvcr71.pdb\630C79175C1942C099C9BC4ED019C6092\msvcr71.pdb 
7c800000 7c8f6000 kernel32 (pdb symbols)   e:\windows\symbols\dll\kernel32.pdb 
7c900000 7c9af000 ntdll  (pdb symbols)   e:\windows\symbols\dll\ntdll.pdb 
WINDBG>bp 0x7c90d16a 
WINDBG>bl 
0 e 7c90d16a  0001 (0001) ntdll!ZwCreateSection+0xa 

雖然我不能讓我的進程符號與「.reload」加載（PDB是在同一個目錄 - 可能需要將其複製到我的符號目錄），我關心的斷點無論如何都在ntdll中，所以我將它設置在調試器識別爲在ntdll.ZwCreateSection（）內的地址0x7C90D16A處。奇怪的是，在用戶模式代碼中，該地址解析爲ntdll。NtCreateSection（），但是無論哪種方式，斷點只有2個指令，從我的用戶模式中斷處開始。當我恢復機器時，我的意圖是「運行」用戶模式調試進程，這會觸發內核模式斷點2指令。內核斷點從來沒有被擊中，應用程序恢復過去這一點。然而，我可以在ntdll！ZwCreateSection（）上設置一個斷點，但是當恢復操作系統時，其他進程反覆觸發斷點，從而阻止我回到用戶模式調試器，因此我只能「運行」到該位置我自己的過程。

UPDATE 合併由@conio提供的提示，下面的步驟爲我工作：

1>安裝內核調試器和引導目標OS之後，暫停OS和應用一些配置選項：

!gflag +ksl   //allow sxe to report user-mode module load events under kernel debugger 
sxe ld myproc.exe //cause kernel debugger break upon process load 
.sympath+ <path> //path to HOST machine's user-mode app's symbols 

2>運行調試器來恢復目標目標OS

3>，運行我們要調試

的EXE

4>內核調試程序應該中斷;現在，輸入以下命令，切換到用戶模式的上下文：

!process 0 0 myproc.exe     //get address of EProcess structure (first number on 1st line after "PROCESS") 
.process /i /r /p <eprocess*>   //set kernel debugger to process context 
g          //continue execution to allow the context switch; debugger will break after switch complete 
.reload /user       //reload user symbols 
lmu          //ensure you have symbols although not really necessary in my particular case 

5>，因爲現在我已經知道ntdll.NtCreateSection（）的用戶模式一側發生了什麼，我只是說幹就幹，設置斷點該函數的內核模式一側，但指定我希望斷點只發生在我的進程的上下文中。通過這種方式，斷點不會被觸發OS寬：

bu /p <eprocess*> nt!NtCreateSection  //set breakpoint in kernel side of function 
g           //run to break 

6>如果一切按計劃進行，斷點會醒來NtCreateSection的內核模式方面的調試器（）。我感謝所有的迴應和提示！

Answer 1

將用戶模式調試與內核模式調試相結合有兩種方法，您會混淆並混淆它們。

您嘗試的方式是使用內核模式調試器來調試內核模式代碼，使用用戶模式調試器（ntsd）來調試用戶模式代碼並控制目標上運行的用戶模式調試器機器來自內核調試器。這就是-d標誌ntsd。該方法在Controlling the User-Mode Debugger from the Kernel Debugger頁面及其在MSDN上的子頁面中進行了描述。

這樣做（或多或少）是將ntsd輸入和輸出重定向到內核調試器。模塊窗格 - 作爲WinDbg中其餘的窗口 - 屬於內核調試器。您與用戶模式調試器的唯一交互是通過內核調試器創建的隧道，並且只能通過命令窗口訪問它。這是記錄在-d標誌的文檔中：

-d

             通過這個調試器內核調試器的控制。如果您正在調試CSRSS，則即使未指定-d，此控制重定向也始終處於活動狀態。 （此選項在遠程調試期間不能使用 - 請改爲使用-ddefer。）有關詳細信息，請參閱從內核調試器控制用戶模式調試器。此選項不能與-ddefer選件或-noio選件一起使用。

              注意如果您使用WinDbg作爲內核調試器，很多的WinDbg熟悉的功能不可用在這種情況下。例如，您不能使用「本地」窗口，「反彙編」窗口或「調用堆棧」窗口，也無法逐步執行源代碼。這是因爲WinDbg僅作爲目標計算機上運行的調試器（NTSD或CDB）的查看器。

第二種方式，即您所使用的鏈接中使用的方式是使用內核調試器來調試內核模式代碼和用戶模式代碼。沒有用戶模式的調試器。沒有ntsd。你說你已經遵循了指南，但實際上你沒有。如果你有，不會有任何ntsd。

我建議你使用這種方法啓動，並且在你使用用戶模式調試器後，只有當你發現你需要（因爲你想使用用戶模式擴展）。

爲了使內核調試器能夠很好地與用戶模式模塊配合使用，您必須啓用Enable loading of kernel debugger symbols GlobalFlag。使用!gflag +ksl來做到這一點。

一旦你這樣做，使用sxe ld:runlist中斷你的進程加載，設置斷點（可能與/p選項），並調試任何你想要的。

只要做到這一點，而不是所有ntsd爛攤子。

Answer 2

使用ntsd -d並從kd連接開始從目標調試executabke，您可以使用kd作爲用戶模式調試程序以及內核調試程序多次讀取文檔這不是件容易的事，只需要多次嘗試即可完成你應該瞭解它的竅門。唱到等

How to break on the entry point of a program when debug in kernel mode with windbg?

編輯以添加一個演示了使用NTSD -d

設置

1) a vm running winxp sp3 and windbg version 6.12 installed in it  
2) _NT_SYMBOL_PATH in vm is set to z:\ 
3) z:\ is a mapped network drive that points to e:\symbols in host 
4) host running win 7 sp2  
5) host windbg 10.0010586  

開始在VM下NTSD應用程序並將其重定向到KD

打開在VM命令提示導航到WINDBG安裝目錄併發出ntsd -s -d calc-s is to disable lazy symbol loading

0:000> version 
version 
Windows XP Version 2600 (Service Pack 3) UP Free x86 compatible 
Product: WinNt, suite: SingleUserTS 
kernel32.dll version: 5.1.2600.5512 (xpsp.080413-2111) 
Machine Name: 
Debug session time: Thu Mar 16 16:44:29.222 2017 
System Uptime: 0 days 0:10:12.941 
Process Uptime: 0 days 0:01:40.980 
    Kernel time: 0 days 0:00:01.632 
    User time: 0 days 0:00:00.040 
Live user mode: <Local> 

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 
Copyright (c) Microsoft Corporation. All rights reserved. 

command line: 'ntsd -s -d calc' Debugger Process 0xA8 
dbgeng: image 6.12.0002.633, built Tue Feb 02 01:38:31 2010 
[path C:\Documents and Settings\admin\Desktop\Debugging Tools for Windows (x86)\dbgeng.dll] 

上SystemBreakPoint WinDBG的場所及調試提示是輸入：\>
流明表示符號從ž加載：\

CommandLine: calc 
Symbol search path is: z:\ 
Executable search path is: 
ModLoad: 01000000 0101f000 calc.exe 
xxxxx 
ntdll!DbgBreakPoint: 
7c90120e cc    int  3 
0:000> lm 
lm 
start end  module name 
01000000 0101f000 calc  (pdb symbols)   z:\calc.pdb\3B7D84101\calc.pdb 
77c10000 77c68000 msvcrt  (export symbols)  C:\WINDOWS\system32\msvcrt.dll 

執行，直到AddressOfEntryPoint

0:000> g @$exentry 
g @$exentry 

calc!WinMainCRTStartup: 
01012475 6a70   push 70h 

一次

0:000> bp ntdll!ZwCreateSection <--- user mode bp notice prompt 0:000 
bp ntdll!ZwCreateSection 


0:000> .breakin <<---- transferring to kd mode 
.breakin 
Break instruction exception - code 80000003 (first chance) 
nt!RtlpBreakWithStatusInstruction: 
804e3592 cc    int  3 


kd> !process 0 0 calc.exe <<----- looking for our process of interest 
Failed to get VAD root 
PROCESS ffae2020 SessionId: 0 Cid: 0410 Peb: 7ffde000 ParentCid: 00a8 
    DirBase: 04d87000 ObjectTable: e1bd5238 HandleCount: 26. 
    Image: calc.exe 

kd> bp /p ffae2020 nt!NtCreateSection << setting a kernel mode bp  
on counterpart that matches with our process of interest notice prompt kd> 


kd> g <<<---- return to user mode after setting a breakpoint 
0:000> g <<<<<--------- executing in user mode 
g 

現在計算的過程是在用戶模式運行中有關VM 點擊幫助。設置在用戶模式內核模式斷點和其對應（這將引發Loadlib並且需要一個Section，所以我們將在內核調試器中打破我們的用戶模式bp）

Breakpoint 0 hit 
eax=00000000 ebx=00000000 ecx=00000001 edx=ffffffff esi=0007f368 edi=00000000 
eip=7c90d160 esp=0007f22c ebp=0007f2a8 iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!NtCreateSection: 
7c90d160 b832000000  mov  eax,32h 

現在我們可以歡快跟蹤各地使用T跟蹤不P或G或任何其它執行命令

0:000> t 
t 
eax=00000032 ebx=00000000 ecx=00000001 edx=ffffffff esi=0007f368 edi=00000000 
eip=7c90d165 esp=0007f22c ebp=0007f2a8 iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!ZwCreateSection+0x5: 
7c90d165 ba0003fe7f  mov  edx,offset SharedUserData!SystemCallStub (7ffe0300) 
0:000> 

eax=00000032 ebx=00000000 ecx=00000001 edx=7ffe0300 esi=0007f368 edi=00000000 
eip=7c90d16a esp=0007f22c ebp=0007f2a8 iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!ZwCreateSection+0xa: 
7c90d16a ff12 call dword ptr [edx] ds:0023:7ffe0300={ntdll!KiFastSystemCall (7c90e4f0)} 
0:000> 

eax=00000032 ebx=00000000 ecx=00000001 edx=7ffe0300 esi=0007f368 edi=00000000 
eip=7c90e4f0 esp=0007f228 ebp=0007f2a8 iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!KiFastSystemCall: 
7c90e4f0 8bd4   mov  edx,esp 
0:000> 

eax=00000032 ebx=00000000 ecx=00000001 edx=0007f228 esi=0007f368 edi=00000000 
eip=7c90e4f2 esp=0007f228 ebp=0007f2a8 iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!KiFastSystemCall+0x2: 
7c90e4f2 0f34   sysenter 
0:000> 

Breakpoint 1 hit 
nt!NtCreateSection: 
805652b3 6a2c   push 2Ch 

當在內核.reload bp和看棧跟蹤

所述第二堆跟蹤是一樣的第一，但與 的Shell32.dll修正符號（VM可是沒有上網所以失敗了第一次 所以我拖累下跌，從虛擬機的具體DLL和使用其獲取來自sumbols主機的WinDbg -z shell32.dll中和。重裝（因爲在主機downstore是網絡中虛擬機mappped第二跡正確加載PDB，並給出了正確的堆棧跟蹤不警告

kd> kb 
# ChildEBP RetAddr Args to Child    
00 f8bb1d40 804de7ec 0007f368 0000000f 00000000 nt!NtCreateSection 
01 f8bb1d40 7c90e4f4 0007f368 0000000f 00000000 nt!KiFastCallEntry+0xf8 
02 0007f224 7c90d16c 7c91c993 0007f368 0000000f ntdll!KiFastSystemCallRet 
03 0007f228 7c91c993 0007f368 0000000f 00000000 ntdll!NtCreateSection+0xc 
04 0007f2a8 7c91c64a 0007f340 00000790 0007f300 ntdll!LdrpCreateDllSection+0x92 
05 0007f388 7c91624a 000add00 0007f414 0007f93c ntdll!LdrpMapDll+0x28f 
06 0007f648 7c9164b3 00000000 000add00 0007f93c ntdll!LdrpLoadDll+0x1e9 
07 0007f8f0 7c801bbd 000add00 0007f93c 0007f91c ntdll!LdrLoadDll+0x230 
08 0007f958 7c801d72 7ffddc00 00000000 00000000 kernel32!LoadLibraryExW+0x18e 
09 0007f96c 7ca625a3 7ca625ac 00000000 00000000 kernel32!LoadLibraryExA+0x1f 
WARNING: Stack unwind information not available. Following frames may be wrong. 
0a 0007f990 010057b8 000700ac 000a7c84 00000000 SHELL32!SHCreateQueryCancelAutoPlayMoniker+0x2062d 
0b 0007fbc4 010041ac 0000012e 00000111 01006118 calc!MenuFunctions+0x15d 
0c 0007fcb4 01004329 0000012e 00000111 01006118 calc!RealProcessCommands+0x1b61 
0d 0007fcdc 01006521 0000012e 0007fd6c 01006118 calc!ProcessCommands+0x2d 
0e 0007fd04 7e418734 000700ac 00000111 0000012e calc!CalcWndProc+0x409 
0f 0007fd30 7e418816 01006118 000700ac 00000111 USER32!InternalCallWinProc+0x28 
10 0007fd98 7e4189cd 00000000 01006118 000700ac USER32!UserCallWinProcCheckWow+0x150 
11 0007fdf8 7e418a10 0007fee8 00000000 0007ff1c USER32!DispatchMessageWorker+0x306 
12 0007fe08 010021a7 0007fee8 7c80b731 000a1ee4 USER32!DispatchMessageW+0xf 
13 0007ff1c 010125e9 000a7738 00000055 000a7738 calc!WinMain+0x256 
14 0007ffc0 7c817067 00000000 00000000 7ffde000 calc!WinMainCRTStartup+0x174 
15 0007fff0 00000000 01012475 00000000 78746341 kernel32!BaseProcessStart+0x23 

堆棧跟蹤不警告

Breakpoint 0 hit 
nt!NtCreateSection: 
805652b3 6a2c   push 2Ch 
kd> kb 
# ChildEBP RetAddr Args to Child    
00 f8aa0d40 804de7ec 0007f368 0000000f 00000000 nt!NtCreateSection 
01 f8aa0d40 7c90e4f4 0007f368 0000000f 00000000 nt!KiFastCallEntry+0xf8 
02 0007f224 7c90d16c 7c91c993 0007f368 0000000f ntdll!KiFastSystemCallRet 
03 0007f228 7c91c993 0007f368 0000000f 00000000 ntdll!NtCreateSection+0xc 
04 0007f2a8 7c91c64a 0007f340 00000790 0007f300 ntdll!LdrpCreateDllSection+0x92 
05 0007f388 7c91624a 000add00 0007f414 0007f93c ntdll!LdrpMapDll+0x28f 
06 0007f648 7c9164b3 00000000 000add00 0007f93c ntdll!LdrpLoadDll+0x1e9 
07 0007f8f0 7c801bbd 000add00 0007f93c 0007f91c ntdll!LdrLoadDll+0x230 
08 0007f958 7c801d72 7ffdfc00 00000000 00000000 kernel32!LoadLibraryExW+0x18e 
09 0007f96c 7ca625a3 7ca625ac 00000000 00000000 kernel32!LoadLibraryExA+0x1f 
0a 0007f97c 7ca62e8e 003800dd 000a7c84 00000000 SHELL32!GetXPSP1ResModuleHandle+0x16 
0b 0007f990 010057b8 000900ac 000a7c84 00000000 SHELL32!ShellAboutW+0x1f 
0c 0007fbc4 010041ac 0000012e 00000111 01006118 calc!MenuFunctions+0x15d 
0d 0007fcb4 01004329 0000012e 00000111 01006118 calc!RealProcessCommands+0x1b61 
0e 0007fcdc 01006521 0000012e 0007fd6c 01006118 calc!ProcessCommands+0x2d 
0f 0007fd04 7e418734 000900ac 00000111 0000012e calc!CalcWndProc+0x409 
10 0007fd30 7e418816 01006118 000900ac 00000111 USER32!InternalCallWinProc+0x28 
11 0007fd98 7e4189cd 00000000 01006118 000900ac USER32!UserCallWinProcCheckWow+0x150 
12 0007fdf8 7e418a10 0007fee8 00000000 0007ff1c USER32!DispatchMessageWorker+0x306 
13 0007fe08 010021a7 0007fee8 7c80b731 000a1ee4 USER32!DispatchMessageW+0xf 
14 0007ff1c 010125e9 000a7738 00000055 000a7738 calc!WinMain+0x256 
15 0007ffc0 7c817067 00000000 00000000 7ffda000 calc!WinMainCRTStartup+0x174 
16 0007fff0 00000000 01012475 00000000 78746341 kernel32!BaseProcessStart+0x23 

轉儲參數NtCreateSection

kd> dds @esp l8 
f8bb1d44 804de7ec nt!KiFastCallEntry+0xf8 
f8bb1d48 0007f368 
f8bb1d4c 0000000f 
f8bb1d50 00000000 
f8bb1d54 00000000 
f8bb1d58 00000010 
f8bb1d5c 01000000 calc!_imp__RegOpenKeyExA <PERF> (calc+0x0) 
f8bb1d60 00000790 

我們所知道的第七個參數是HANDLE according to prototype of DDI

NTSTATUS ZwCreateSection(
     _Out_ PHANDLE   SectionHandle, 
     _In_  ACCESS_MASK  DesiredAccess, 
     _In_opt_ POBJECT_ATTRIBUTES ObjectAttributes, 
     _In_opt_ PLARGE_INTEGER  MaximumSize, 
     _In_  ULONG    SectionPageProtection, 
     _In_  ULONG    AllocationAttributes, 
     _In_opt_ HANDLE    FileHandle 
    ); 

kd> !handle 790 

Failed to get VAD root 
PROCESS ffae2020 SessionId: 0 Cid: 0410 Peb: 7ffde000 ParentCid: 00a8 
    DirBase: 04d87000 ObjectTable: e1bd5238 HandleCount: 29. 
    Image: calc.exe 

Handle table at e1bd5238 with 29 entries in use 

0790: Object: 8124b028 GrantedAccess: 00100020 Entry: e1032f20 
Object: 8124b028 Type: (8127b900) File 
    ObjectHeader: 8124b010 (old version) 
     HandleCount: 1 PointerCount: 1 
     Directory Object: 00000000 Name: \WINDOWS\system32\xpsp1res.dll {HarddiskVolume1} 

從內核模式返回到用戶模式並檢查新科處理

kd> g 
eax=00000000 ebx=00000000 ecx=00000001 edx=ffffffff esi=0007f368 edi=00000000 
eip=7c90d16c esp=0007f22c ebp=0007f2a8 iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!ZwCreateSection+0xc: 
7c90d16c c21c00   ret  1Ch 

檢查在用戶模式下手柄的返回值

0:000> dd 7f368 l1 
dd 7f368 l1 
0007f368 0000078c 
0:000> !handle 78c 
!handle 78c 
Handle 78c 
    Type   Section 
0:000> !handle 78c f 
!handle 78c f 
Handle 78c 
    Type   Section 
    Attributes 0 
    GrantedAccess 0xf: 
     None 
     Query,MapWrite,MapRead,MapExecute 
    HandleCount 2 
    PointerCount 3 
    Name   <none> 
    Object Specific Information 
    Section base address 0 
    Section attributes 0x1800000 
    Section max size 0x2f000 
0:000> 

如果不滿意，我們可以恢復KD設置進程上下文，並檢查在內核模式下返回的句柄

kd> !handle 78c f 

Failed to get VAD root 
PROCESS ffae2020 SessionId: 0 Cid: 0410 Peb: 7ffde000 ParentCid: 00a8 
    DirBase: 04d87000 ObjectTable: e1bd5238 HandleCount: 30. 
    Image: calc.exe 

Handle table at e1bd5238 with 30 entries in use 

078c: Object: e1088f30 GrantedAccess: 0000000f Entry: e1032f18 
Object: e1088f30 Type: (8128b900) Section 
    ObjectHeader: e1088f18 (old version) 
     HandleCount: 1 PointerCount: 1 

現在如果繼續執行，你可以看到在WinDbg中加載庫dbgprint和關於對話框中的虛擬機:)

kd> g 
0:000> g 
g 
ModLoad: 10000000 1002f000 C:\WINDOWS\system32\xpsp1res.dll