聊一聊 C# 线程切换后上下文都去了哪里

宁静至远

一：背景

1. 讲故事

总会有一些朋友问一个问题，在 Windows 中线程做了上下文切换，请问被切的线程他的寄存器上下文都去了哪里？能不能给我挖出来？这个问题其实比较底层，如果对操作系统没有个体系层面的理解以及做过源码分析，其实很难说明白，这篇我们就从.NET高级调试的角度试着分析一下吧。
二：寄存器上下文去哪了

1. 用户线程的两态空间

用C#代码创建的线程在操作系统层面上来说属于 用户态线程，这种线程拥有两个线程栈，哈哈，是不是打破了一些朋友的三观。分别为 用户态栈 和 内核态栈。
为了方便讲解，写一段简单的测试代码，不断的调用 Sleep(1) 让代码在用户态和内核态不断的切换，也就能观察得到这两套栈空间，参考代码如下：

1.         static void Main(string[] args)
2.         {
3.             for (int i = 0; i < int.MaxValue; i++)
4.             {
5.                 Thread.Sleep(1);
6.                 Console.WriteLine($"i={i}");
7.             }
8.         }

复制代码

将程序跑起来后我们用 windbg 附加，观察这个程序的上下文，参考如下：

1. 0: kd> !process 0 2 ConsoleApp7.exe
2. PROCESS ffffe00185e33440
3.     SessionId: 2  Cid: 0f4c    Peb: 7ff73b7a8000  ParentCid: 15f4
4.     DirBase: 1573c1000  ObjectTable: ffffc00165357840  HandleCount: <Data Not Accessible>
5.     Image: ConsoleApp7.exe
7.         THREAD ffffe0018917a080  Cid 0f4c.0f50  Teb: 00007ff73b7ae000 Win32Thread: ffffe00185e3db20 WAIT: (DelayExecution) UserMode Alertable
8.             ffffffffffffffff  NotificationEvent
9. ...
11. 2: kd> dt nt!_KTHREAD ffffe0018917a080
12.    +0x028 InitialStack     : 0xffffd001`f8b64c90 Void
13.    +0x030 StackLimit       : 0xffffd001`f8b5f000 Void
14.    +0x038 StackBase        : 0xffffd001`f8b65000 Void
15.    ...
16.    +0x058 KernelStack      : 0xffffd001`f8b63c80 Void
17.    ...
18.    +0x0f0 Teb              : 0x00007ff7`3b7ae000 Void
19.    ...
21. 2: kd> dt ntdll!_NT_TIB 0x00007ff7`3b7ae000
22.    +0x000 ExceptionList    : (null)
23.    +0x008 StackBase        : 0x00000035`35790000 Void
24.    +0x010 StackLimit       : 0x00000035`3577e000 Void
25.    +0x018 SubSystemTib     : (null)
26.    +0x020 FiberData        : 0x00000000`00001e00 Void
27.    +0x020 Version          : 0x1e00
28.    +0x028 ArbitraryUserPointer : (null)
29.    +0x030 Self             : 0x00007ff7`3b7ae000 _NT_TIB
30.    ...

复制代码

上面的信息非常清晰，两套栈空间 StackBase ~ StackLimit，分别为  0x0000003535790000 ~ 0x000000353577e000 和 0xffffd001f8b5f000~0xffffd001f8b65000。
2. 理解系统调用

理解了线程的两套栈空间之后，接下来说的就是系统调用，简单来说就是C#线程从 用户态 进入到 内核态 时，他的用户态寄存器上下文会存放到 _KTRAP_FRAME 结构体中，而这个结构体会放在内核态的线程栈上，有些朋友可能有点懵，画个图如下：

接下来的问题是如何验证呢？非常简单，第一种是通过 !thread 观察线程栈上的 TrapFrame 标记，第二种是提取内核线程的 _KTHREAD.TrapFrame 字段，为了方便测试，直接在 Sleep 的内核函数 NtDelayExecution 处下一个进程级别的断点，输出如下：

1. 1: kd> bp /p ffffe00185e33440  nt!NtDelayExecution
2. breakpoint 0 redefined
3. 1: kd> g
4. Breakpoint 0 hit
5. nt!NtDelayExecution:
6. fffff802`e4e8dfb0 4883ec28        sub     rsp,28h
8. 3: kd> !thread ffffe0018917a080
9. THREAD ffffe0018917a080  Cid 0f4c.0f50  Teb: 00007ff73b7ae000 Win32Thread: ffffe00185e3db20 RUNNING on processor 3
10. IRP List:
11.     ffffe00187633ca0: (0006,0358) Flags: 00060800  Mdl: 00000000
12. Not impersonating
13. DeviceMap                 ffffc0015d587160
14. Owning Process            ffffe00185e33440       Image:         ConsoleApp7.exe
15. Attached Process          N/A            Image:         N/A
16. Wait Start TickCount      21032          Ticks: 1 (0:00:00:00.015)
17. Context Switch Count      8187           IdealProcessor: 3            
18. UserTime                  00:00:00.015
19. KernelTime                00:00:00.125
20. Win32 Start Address ConsoleApp7_exe!wmainCRTStartup (0x00007ff73beb3c60)
21. Stack Init ffffd001f8b64c90 Current ffffd001f8b64550
22. Base ffffd001f8b65000 Limit ffffd001f8b5f000 Call 0000000000000000
23. Priority 10 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5
24. Child-SP          RetAddr               : Args to Child                                                           : Call Site
25. ffffd001`f8b64af8 fffff802`e4be9b63     : ffffe001`8917a080 00000000`00000014 ffffffff`ffffd8f0 ffffe001`886c3fe0 : nt!NtDelayExecution
26. ffffd001`f8b64b00 00007ff8`cf383b6a     : 00007ff8`cc0d3777 00000035`3578e198 00000000`00000001 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd001`f8b64b00)
27. 00000035`3578e0d8 00007ff8`cc0d3777     : 00000035`3578e198 00000000`00000001 00000000`00000000 00000000`00000000 : ntdll!NtDelayExecution+0xa
28. 00000035`3578e0e0 00007ff8`aec355f2     : 00000035`35977a40 00000000`00000001 00000035`00000000 00000000`00000000 : KERNELBASE!SleepEx+0xa7
29. (Inline Function) --------`--------     : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!ClrSleepEx+0xd (Inline Function @ 00007ff8`aec355f2)
30. 00000035`3578e180 00007ff8`aec354eb     : 06000000`00000001 00007ff8`aec35450 04000000`00000001 00000000`00000000 : coreclr!Thread::UserSleep+0xb2
31. 00000035`3578e1d0 00007ff8`4f1ea095     : 00000035`3578e3c0 00000035`3578e4b8 00000000`00000001 00000000`00000001 : coreclr!ThreadNative::Sleep+0x9b
33. 3: kd> dt nt!_KTRAP_FRAME ffffd001`f8b64b00
34.    ...
35.    +0x030 Rax              : 0x00007ff7`3b770002
36.    +0x038 Rcx              : 0x00000035`358d33a0
37.    +0x040 Rdx              : 0x00000035`37b5c9b8
38.    +0x048 R8               : 0x00000035`37b5c9c8
39.    +0x050 R9               : 0x00000035`3578dd70
40.    +0x058 R10              : 0x00007ff7`3b780022
41.    +0x060 R11              : 0x00000035`3578e170
42.    +0x068 GsBase           : 0x00007ff7`3b7ae000
43.    +0x068 GsSwap           : 0x00007ff7`3b7ae000
44.    ...
45.    +0x0d0 FaultAddress     : 0x00000035`37b7b000
46.    ...
47.    +0x140 Rbx              : 1
48.    +0x148 Rdi              : 0
49.    +0x150 Rsi              : 1
50.    +0x158 Rbp              : 0x503b1
51.    +0x168 Rip              : 0x7ff8cf383b6a [Type: unsigned __int64]
52.    +0x180 Rsp              : 0x353578e0d8 [Type: unsigned __int64]
53.    ...

复制代码

仔细观察上面的 RIP 和 RSP 值，都能看到它是在 Ring3 上的现场，分别对应着用户态的 ret 和 ntdll!NtDelayExecution，输出如下：

1. 3: kd> uf 0x7ff8cf383b6a
2. ntdll!NtDelayExecution:
3. 00007ff8`cf383b60 4c8bd1          mov     r10,rcx
4. 00007ff8`cf383b63 b834000000      mov     eax,34h
5. 00007ff8`cf383b68 0f05            syscall
6. 00007ff8`cf383b6a c3              ret
8. 3: kd> k
9. # Child-SP          RetAddr               Call Site
10. 00 ffffd001`f8b64af8 fffff802`e4be9b63     nt!NtDelayExecution
11. 01 ffffd001`f8b64b00 00007ff8`cf383b6a     nt!KiSystemServiceCopyEnd+0x13
12. 02 00000035`3578e0d8 00007ff8`cc0d3777     ntdll!NtDelayExecution+0xa
13. 03 00000035`3578e0e0 00007ff8`aec355f2     KERNELBASE!SleepEx+0xa7
14. 04 (Inline Function) --------`--------     coreclr!ClrSleepEx+0xd
15. 05 00000035`3578e180 00007ff8`aec354eb     coreclr!Thread::UserSleep+0xb2
16. 06 00000035`3578e1d0 00007ff8`4f1ea095     coreclr!ThreadNative::Sleep+0x9b
17. 07 00000035`3578e320 00000035`3578e3c0     0x00007ff8`4f1ea095

复制代码

3. 内核态线程上下文切换

上一节的_KTRAP_FRAME结构只是保存了 Ring3 -> Ring0 的现场，其实还有一个现场，很显然是调用线程执行 Sleep(1) 后让自己暂停并出让cpu核，为了让自己下一次得到完美的调度，此次必须要保存现场，那这个保存现场的逻辑在哪里的？其实是通过内核的 nt!KiSwapContext 函数实现的。
本来想在 nt!KiSwapContext 处下个断点，发现命中不了我的 Sleep 函数的 SwapContext，怀疑有cli之类的屏蔽外部中断导致的，这里只能反汇编源码了，参考如下：

1. 3: kd> uf nt!KiSwapContext
2. nt!KiSwapContext:
3. fffff802`e4be3f30 4881ec38010000  sub     rsp,138h
4. fffff802`e4be3f37 488d842400010000 lea     rax,[rsp+100h]
5. fffff802`e4be3f3f 0f29742430      movaps  xmmword ptr [rsp+30h],xmm6
6. fffff802`e4be3f44 0f297c2440      movaps  xmmword ptr [rsp+40h],xmm7
7. fffff802`e4be3f49 440f29442450    movaps  xmmword ptr [rsp+50h],xmm8
8. fffff802`e4be3f4f 440f294c2460    movaps  xmmword ptr [rsp+60h],xmm9
9. fffff802`e4be3f55 440f29542470    movaps  xmmword ptr [rsp+70h],xmm10
10. fffff802`e4be3f5b 440f295880      movaps  xmmword ptr [rax-80h],xmm11
11. fffff802`e4be3f60 440f296090      movaps  xmmword ptr [rax-70h],xmm12
12. fffff802`e4be3f65 440f2968a0      movaps  xmmword ptr [rax-60h],xmm13
13. fffff802`e4be3f6a 440f2970b0      movaps  xmmword ptr [rax-50h],xmm14
14. fffff802`e4be3f6f 440f2978c0      movaps  xmmword ptr [rax-40h],xmm15
15. fffff802`e4be3f74 488918          mov     qword ptr [rax],rbx
16. fffff802`e4be3f77 48897808        mov     qword ptr [rax+8],rdi
17. fffff802`e4be3f7b 48897010        mov     qword ptr [rax+10h],rsi
18. fffff802`e4be3f7f 4c896018        mov     qword ptr [rax+18h],r12
19. fffff802`e4be3f83 4c896820        mov     qword ptr [rax+20h],r13
20. fffff802`e4be3f87 4c897028        mov     qword ptr [rax+28h],r14
21. fffff802`e4be3f8b 4c897830        mov     qword ptr [rax+30h],r15
22. fffff802`e4be3f8f 65488b1c2520000000 mov   rbx,qword ptr gs:[20h]
23. fffff802`e4be3f98 488bf9          mov     rdi,rcx
24. fffff802`e4be3f9b 488bf2          mov     rsi,rdx
25. fffff802`e4be3f9e 418bc8          mov     ecx,r8d
26. fffff802`e4be3fa1 e8ba020000      call    nt!SwapContext (fffff802`e4be4260)
27. fffff802`e4be3fa6 488d8c2400010000 lea     rcx,[rsp+100h]
28. fffff802`e4be3fae 0f28742430      movaps  xmm6,xmmword ptr [rsp+30h]
29. fffff802`e4be3fb3 0f287c2440      movaps  xmm7,xmmword ptr [rsp+40h]
30. fffff802`e4be3fb8 440f28442450    movaps  xmm8,xmmword ptr [rsp+50h]
31. fffff802`e4be3fbe 440f284c2460    movaps  xmm9,xmmword ptr [rsp+60h]
32. fffff802`e4be3fc4 440f28542470    movaps  xmm10,xmmword ptr [rsp+70h]
33. fffff802`e4be3fca 440f285980      movaps  xmm11,xmmword ptr [rcx-80h]
34. fffff802`e4be3fcf 440f286190      movaps  xmm12,xmmword ptr [rcx-70h]
35. fffff802`e4be3fd4 440f2869a0      movaps  xmm13,xmmword ptr [rcx-60h]
36. fffff802`e4be3fd9 440f2871b0      movaps  xmm14,xmmword ptr [rcx-50h]
37. fffff802`e4be3fde 440f2879c0      movaps  xmm15,xmmword ptr [rcx-40h]
38. fffff802`e4be3fe3 488b19          mov     rbx,qword ptr [rcx]
39. fffff802`e4be3fe6 488b7908        mov     rdi,qword ptr [rcx+8]
40. fffff802`e4be3fea 488b7110        mov     rsi,qword ptr [rcx+10h]
41. fffff802`e4be3fee 4c8b6118        mov     r12,qword ptr [rcx+18h]
42. fffff802`e4be3ff2 4c8b6920        mov     r13,qword ptr [rcx+20h]
43. fffff802`e4be3ff6 4c8b7128        mov     r14,qword ptr [rcx+28h]
44. fffff802`e4be3ffa 4c8b7930        mov     r15,qword ptr [rcx+30h]
45. fffff802`e4be3ffe 4881c438010000  add     rsp,138h
46. fffff802`e4be4005 c3              ret
48. 1: kd> uf nt!SwapContext
49. nt!SwapContext:
50. ...
51. nt!SwapContext+0xc9:
52. fffff802`1a9df329 0fae5918        stmxcsr dword ptr [rcx+18h]
53. fffff802`1a9df32d 48896758        mov     qword ptr [rdi+58h],rsp
54. fffff802`1a9df331 488b6658        mov     rsp,qword ptr [rsi+58h]
55. fffff802`1a9df335 f6470380        test    byte ptr [rdi+3],80h
56. fffff802`1a9df339 741c            je      nt!SwapContext+0xf7 (fffff802`1a9df357)  Branch
57. ...

复制代码

上面有一句非常重要的汇编代码 rsp,qword ptr [rsi+58h]，翻译过来就是 esp=newThread.KernelStack，其实就是切换到新线程的内核态栈，并且在执行 nt!SwapContext 之前会进行现场保存，比如上面的 xmm 之类的寄存器，在切换完之后在新线程的同等位置上pop出这些现场。
最后一个问题是这个上下文保存在哪里呢？通过观察是还是在 InitialStack ~ KernelStack 之间，并且比 _KTRAP_FRAME 的位置要低，画个模型图如下：

感兴趣的朋友可以在那些能被 int 3 的 KiSwapContext 处下断点，比较下大小即可，截图如下：

三：总结

哈哈，是不是非常有意思，一个简单的 Sleep(1) 涉及到两块的寄存器上下文，并都保存在内核线程栈的 InitialStack ~ KernelStack 区间，这也算是加深了自己对操作系统的理解，也帮一些朋友解答了一些困惑！

来源:https://www.cnblogs.com/huangxincheng/archive/2023/12/22/17921650.html
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！