我正在搜索，Windows在上下文切换过程中保存其寄存器（内核模式下的寄存器和用户模式下的寄存器）。
然后我找到了this问题，该问题描述了Windows在nt!_KTHREAD中将当前上下文保存在以下字段中：
+0x1b8 WaitPrcb : Ptr32 _KPRCB
我可以在nt!_KPRCB中找到以下字段：
+0x3658 Context : Ptr32 _CONTEXT
如您所知，nt!_CONTEXT是包含上下文切换所需的几乎所有寄存器的结构。
为了找到这个位置我使用windbg配置VMWare内核调试然后在客户机中打开一个xdbg64并连接到x64进程以查看当前寄存器状态并使用主机的windbg暂停客户机并在Windbg中首先我找到目标流程：
kd> !process 0 0
...
PROCESS ffff9387f70d05c0
SessionId: 1 Cid: 15e4 Peb: 35cf6bd000 ParentCid: 10b4
DirBase: 48b46000 ObjectTable: ffffba87f0b628c0 HandleCount: <Data Not Accessible>
Image: example.exe
...
然后找到这个过程的主题：
kd> !process ffff9387f70d05c0
PROCESS ffff9387f70d05c0
SessionId: 1 Cid: 15e4 Peb: 35cf6bd000 ParentCid: 10b4
DirBase: 48b46000 ObjectTable: ffffba87f0b628c0 HandleCount: <Data Not Accessible>
Image: example.exe
VadRoot ffff9387f6238750 Vads 1 Clone 0 Private 168. Modified 0. Locked 0.
DeviceMap ffffba87ef63f230
Token ffffba87e97ec060
ElapsedTime 00:16:35.173
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (0, 0, 0) (0KB, 0KB, 0KB)
PeakWorkingSetSize 0
VirtualSize 79 Mb
PeakVirtualSize 79 Mb
PageFaultCount 0
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 204
DebugPort ffff9387f6952400
Job ffff9387f82b4830
THREAD **ffff9387f62f1700** Cid 15e4.08c4 Teb: 00000035cf6be000 Win32Thread: ffff9387f7b64e50 WAIT: (Executive) KernelMode Non-Alertable
FreezeCount 1
fffffd8ec29cad80 SynchronizationEvent
Cannot read nt!_KWAIT_BLOCK at 0000000000000000 - error 1
Not impersonating
DeviceMap ffffba87ef63f230
Owning Process ffff9387f70d05c0 Image: example.exe
Attached Process N/A Image: N/A
Wait Start TickCount 4600127 Ticks: 3 (0:00:00:00.046)
Context Switch Count 1215
UserTime 00:00:00.000
KernelTime 00:00:00.015
Win32 Start Address 0x00007ff7e7a22440
Stack Init fffffd8ec29cbc90 Current fffffd8ec29ca970
Base fffffd8ec29cc000 Limit fffffd8ec29c6000 Call 0
Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr Call Site
fffffd8e`c29ca9b0 00000000`00000000 nt!KiSwapContext+0x76
在最后一步中，我将上述（线程）地址映射到nt!_kthread：
kd> dt nt!_kthread ffff9387f62f1700
+0x000 Header : _DISPATCHER_HEADER
+0x018 SListFaultAddress : (null)
+0x020 QuantumTarget : 0x878eb54
+0x028 InitialStack : 0xfffffd8e`c29cbc90 Void
+0x030 StackLimit : 0xfffffd8e`c29c6000 Void
+0x038 StackBase : 0xfffffd8e`c29cc000 Void
...
+0x2c8 WaitPrcb : (null)
...
但正如您所见，WaitPrcb为空！
所以我的问题是：
null位置有什么问题？ （或者我在错误的地方？）nt!_CONTEXT结构！它们在哪里？答案 0 :(得分：0)
不确定你要做什么，你的问题有点令人困惑 为什么将waitprcb与_context相互链接
windbgs kb（stack backtrace）通常会显示trapframe的地址
！process 0 2 {process name}将产生特定进程中的所有线程
它将是一个Dml输出，只需单击输出中的线程地址就会显示每个线程的调用堆栈（执行的命令！线程地址）
或者您可以使用dt nt!_ethread Tcb->TrapFrame->*
这是你想要做的吗？
kd> !process 0 2 calc.exe
PROCESS 841fa930 SessionId: 1 Cid: 0228 Peb: 7ffdf000 ParentCid: 022c
DirBase: 06812000 ObjectTable: 9512f448 HandleCount: 88.
Image: calc.exe
THREAD 841fa648 Cid 0228.061c Teb: 7ffde000 Win32Thread: fe7196c0 WAIT:
THREAD 841f6a48 Cid 0228.067c Teb: 7ffdd000 Win32Thread: ff8cc918 WAIT:
THREAD 84975b48 Cid 0228.05b8 Teb: 7ffdc000 Win32Thread: fe246298 WAIT:
**THREAD 841f7850** Cid 0228.073c Teb: 7ffdb000 Win32Thread: 00000000 WAIT:
kd> .shell -ci "!thread 841fa648" grep TrapFrame
8e2e3d1c 772370b4 001eef48 00000000 00000000 nt!KiFastCallEntry+0x12aTrapFrame @ 8e2e3d34)
kd> .shell -ci "!thread 841f6a48" grep TrapFrame
8e21fd18 772370b4 00000002 0166f810 00000001 nt!KiFastCallEntry+0x12aTrapFrame @ 8e21fd34)
kd> .shell -ci "!thread 84975b48" grep TrapFrame
8c65fd18 772370b4 00000001 026cfde0 00000001 nt!KiFastCallEntry+0x12aTrapFrame @ 8c65fd34)
kd> .shell -ci **"!thread 841f7850"** grep TrapFrame
8e2d3d18 772370b4 00000003 00376558 00000001 nt!KiFastCallEntry+0x12aTrapFrame @ 8e2d3d34)
kd> **!thread 841f7850**
ChildEBP RetAddr Args to Child
8e2d3760 8286dd75 841f7850 82937f08 82934d20 nt!KiSwapContext+0x26 (FPO: [0,0,4])
8e2d3798 8286cbd3 841de4a0 841f7850 841f7964 nt!KiSwapThread+0x266
8e2d37c0 82868c59 841f7850 841f7910 00000000 nt!KiCommitThreadWait+0x1df
8e2d393c 82a11a89 00000003 8e2d3a74 00000001 nt!KeWaitForMultipleObjects+0x535
8e2d3bc8 82a117f6 00000003 8e2d3c00 00000001 nt!ObpWaitForMultipleObjects+0x262
8e2d3d18 8284787a 00000003 00376558 00000001 nt!NtWaitForMultipleObjects+0xcd
8e2d3d18 772370b4 00000003 00376558 01 nt!KiFastCallEntry+0x12a **TrapFrame @ 8e2d3d34**)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0258fd48 00000000 00000000 00000000 00000000 0x772370b4
kd> dt nt!_ETHREAD Tcb->TrapFrame 841f7850
+0x000 Tcb :
+0x128 TrapFrame : **0x8e2d3d34 _KTRAP_FRAME**
答案 1 :(得分：0)
我正在添加另一个答案，因为使用新细节编辑早期答案会让人感到困惑
由于几个原因，可以切换上下文 1）线程已经放弃并被阻塞等待一些输入（比如说scanf（））
2）发生中断并且正在运行的线程被中断（异常，高优先级线程变为可运行等）
3）用户模式到内核模式转换
让假设 nt！KiSwapContext是负责切换上下文的函数。
验证我们的假设或假设我们可以在该函数上设置特定于进程的条件断点并记录
debugger win 7 sp1 32 bit physical machine
debuggee win 7 sp1 32 bit vm
transport serial pipe
breakpoint list bl output we have one processes specific conditional bp
condition print the backward disassembly at the return address on stack
print callstack and continue execution
0 e Disable Clear 8288bf00 0001 (0001) nt!KiSwapContext "ub @$ra;kb;gc"
Match process data 842fe7d0
kd> g
在短时间内输出数千行我们将使用wc.exe，sed，grep，awk，sort，uniq，gnuwin32工具来分析文本输出
:\>wc -l swappy.txt
2109 swappy.txt
:\>grep debuggee swappy.txt
Debugger (not debuggee) time: Thu Mar 15 13:03:14.047 2018
Debugger (not debuggee) time: Thu Mar 15 13:06:20.077 2018
:\>grep call.*nt!KiSwapContext swappy.txt | wc -l
153
the output is 2109 lines in 3 minutes of trial time and nt!KiSwapContext has
been called 153 times during this time period for this specific process
这些调用的每个中断都会输出一些像这样的东西
:\>head -n 23 swappy.txt | tail -n 16
kd> g
nt!KiQuantumEnd+0x2ca:
828b976a 8bd6 mov edx,esi
828b976c 8bcb mov ecx,ebx
828b976e c683870100001e mov byte ptr [ebx+187h],1Eh
828b9775 e87ed3faff call nt!KiQueueReadyThread (82866af8)
828b977a 8b542414 mov edx,dword ptr [esp+14h]
828b977e 8bcb mov ecx,ebx
828b9780 c6436a01 mov byte ptr [ebx+6Ah],1
828b9784 e87727fdff call nt!KiSwapContext (8288bf00)
# ChildEBP RetAddr Args to Child
00 80df94d0 828b9789 dcf83678 9601a27a 82959c00 nt!KiSwapContext
WARNING: Process directory table base 16DAC000 doesn't match CR3 00185000
WARNING: Process directory table base 16DAC000 doesn't match CR3 00185000
01 00000000 00000000 00000000 00000000 00000000 nt!KiQuantumEnd+0x2e9
nt!KiSwapThread+0x256:
我们可以像这样排序并获得每次调用的独特出现
:\>grep -B10 call.*nt!KiSwapContext swappy.txt | grep +.*: | sort | uniq
nt!KiExitDispatcher+0x123:
nt!KiQuantumEnd+0x2ca:
nt!KiSwapThread+0x256:
:\>grep -B10 call.*nt!KiSwapContext swappy.txt | grep +.*: | sort | grep Exit | wc -l
12
:\>grep -B10 call.*nt!KiSwapContext swappy.txt | grep +.*: | sort | grep Quant | wc -l
101
:\>grep -B10 call.*nt!KiSwapContext swappy.txt | grep +.*: | sort | grep SwapThread | wc -l
40
我们可以从这个样本数据推断，由于时间片完成，上下文可能很大程度上被交换 然后是线程切除，然后是中断
让我们首先研究最大的出现，其调用序列如下所示 所以准备好的线程排队并交换上下文 我们可以看到ebx正在使用，ebx似乎是一个结构（我们可以看到成员@偏移量0x187和0x6a在调用序列中被访问）
:\>grep -m 3 -B10 call.*nt!KiSwapContext swappy.txt | grep -m 1 -A 10 +.*:
nt!KiQuantumEnd+0x2ca:
828b976a 8bd6 mov edx,esi
828b976c 8bcb mov ecx,ebx
828b976e c683870100001e mov byte ptr [ebx+187h],1Eh
828b9775 e87ed3faff call nt!KiQueueReadyThread (82866af8)
828b977a 8b542414 mov edx,dword ptr [esp+14h]
828b977e 8bcb mov ecx,ebx
828b9780 c6436a01 mov byte ptr [ebx+6Ah],1
828b9784 e87727fdff call nt!KiSwapContext (8288bf00)
让我们修改断点并停止并用f5或g手动继续，直到我们到达QuantumEnd调用序列
kd> bp /p 842fe7d0 nt!KiSwapContext ".printf \"%y\n\" , @$ra"
breakpoint 0 redefined
kd> g
nt!KiExitDispatcher+0x140 (8288be87) nt!KiSwapContext:
8288bf00 83ec10 sub esp,10h
kd> g
nt!KiQuantumEnd+0x2e9 (828b9789) nt!KiSwapContext:
8288bf00 83ec10 sub esp,10h
kd> r
eax=00000000 ebx=84e50b40 ecx=84e50b40 edx=84304030 esi=82959d20 edi=84e50b40
eip=8288bf00 esp=8c691b4c ebp=8c691b88
从寄存器中我们可以看到调用序列的反汇编匹配
ecx，ebx＆amp; edi是相同的（指向新线程的准备线程）
edx匹配调整推送（调用使用一个dword一个返回地址，而不是[esp + 14]我们检查[esp + 18]）指向当前线程的指针
esi = prcb
kd> ? dwo(@esp+18)
Evaluate expression: -2077212624 = 84304030
kd> ? @$thread
Evaluate expression: -2077212624 = 84304030
kd> ? edx
Evaluate expression: -2077212624 = 84304030
kd> ?? @$prcb == (int *)(@esi)
bool true
kd> ? @$prcb ; ? @esi
Evaluate expression: -2104124128 = 82959d20
Evaluate expression: -2104124128 = 82959d20
kd> ? @ecx;? @ebx;? @edi;!thread @ebx 0
Evaluate expression: -2065364160 = 84e50b40
Evaluate expression: -2065364160 = 84e50b40
Evaluate expression: -2065364160 = 84e50b40
THREAD 84e50b40 Cid 0174.01ec Teb: 7ffd9000 Win32Thread: ff9461a0 READY on processor 0
因为我们确认了ebx =将成为新线程的线程 我们可以确认187h和6ah偏移量指向
kd> .enable_long_status 1
kd> ?? #FIELD_OFFSET(nt!_KTHREAD , WaitReason)
long 0x187
kd> ?? #FIELD_OFFSET(nt!_KTHREAD , WaitIrql)
long 0x6a
我们还可以从头文件
确认Wait Reason和WaitIrql:\>grep WaitReason "c:\Program Files\Windows Kits\10\Include\10.0.16299.0\km\wdm.h"
MaximumWaitReason
_In_ _Strict_type_match_ KWAIT_REASON WaitReason,
_In_ _Strict_type_match_ KWAIT_REASON WaitReason,
:\>grep -n KWAIT_REASON "c:\Program Files\Windows Kits\10\Include\10.0.16299.0\km\wdm.h"
20139:typedef enum _KWAIT_REASON {
20181:} KWAIT_REASON;
20925: _In_ _Strict_type_match_ KWAIT_REASON WaitReason,
20941: _In_ _Strict_type_match_ KWAIT_REASON WaitReason,
:\>awk "NR==20139+0x1f" "c:\Program Files\Windows Kits\10\Include\10.0.16299.0\km\wdm.h"
WrQuantumEnd,
:\>grep -n define.*APC_LEVEL "c:\Program Files\Windows Kits\10\Include\10.0.16299.0\km\wdm.h"
175:#define APC_LEVEL 1 // APC interrupt level
因为我们已经解密了几乎所有我们现在可以查看函数的内容
kd> uf .
nt!KiSwapContext:
8288bf00 83ec10 sub esp,10h
8288bf03 895c240c mov dword ptr [esp+0Ch],ebx
8288bf07 89742408 mov dword ptr [esp+8],esi
8288bf0b 897c2404 mov dword ptr [esp+4],edi
8288bf0f 892c24 mov dword ptr [esp],ebp
8288bf12 648b1d1c000000 mov ebx,dword ptr fs:[1Ch]
8288bf19 8bf9 mov edi,ecx
8288bf1b 8bf2 mov esi,edx
8288bf1d 0fb64f6a movzx ecx,byte ptr [edi+6Ah]
8288bf21 e87a010000 call nt!SwapContext (8288c0a0)
8288bf26 8b2c24 mov ebp,dword ptr [esp]
8288bf29 8b7c2404 mov edi,dword ptr [esp+4]
8288bf2d 8b742408 mov esi,dword ptr [esp+8]
8288bf31 8b5c240c mov ebx,dword ptr [esp+0Ch]
8288bf35 83c410 add esp,10h
8288bf38 c3 ret
所以函数取fs：[1c]这是self.pcr新线程的WaitIrql并输入执行实际交换的nt！SwapContext（）
直到nt！SwapContext，你会看到
kd>
nt!KiSwapContext+0x21:
8288bf21 e87a010000 call nt!SwapContext (8288c0a0)
kd> r
eax=00000000 ebx=82959c00 ecx=00000001 edx=84304030 esi=84304030 edi=84e50b40
eip=8288bf21 esp=8c691b3c ebp=8c691b88 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286
nt!KiSwapContext+0x21:
8288bf21 e87a010000 call nt!SwapContext (8288c0a0)
这是一个开始
kd> r
eax=00000000 ebx=82959c00 ecx=00000001 edx=84304030 esi=84304030 edi=84e50b40
eip=8288c0a0 esp=8c691b38 ebp=8c691b88 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286
nt!SwapContext:
8288c0a0 807e3900 cmp byte ptr [esi+39h],0 ds:0023:84304069=00
kd> ?? #FIELD_OFFSET( nt!_KTHREAD , Running)
long 0x39
kd> $$ checks if the current thread is running if it is running it stops it
with a pause if it is not running it sets the running member clears
interrupts updates the counters
kd> it is a big function check it out to see what registers are pushed , copied , moved to where
nt！SwapContext调用这些函数，start accumalation调用在条件下保存浮点寄存器 必要时保存其他寄存器
nt!SwapContext (8288c0a0)
call to hal!HalRequestSoftwareInterrupt (82820258)
call to nt!KiBeginCounterAccumulation (8290d6a7)
call to nt!PsCheckThreadCpuQuota (829263f0)
call to nt!EtwTraceContextSwap (82847de8)
call to nt!KeBugCheckEx (8290940a)
询问或启动一个新线程，其中包含链接此主题的特定问题