我正在添加另一个答案，因为使用新的详细信息编辑较早的答案会让人感到困惑
由于多种原因可以切换上下文
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 似乎是一个结构（我们可以看到成员 @ offset 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 和 edi 相同（指向新线程 a Ready Thread 的指针）
edx 匹配调整推送（调用使用一个双字作为返回地址，因此我们检查 [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 调用这些函数 begin 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)
询问或开始一个新的主题，其中包含链接该主题的特定问题