翼度科技»论坛 编程开发 .net 查看内容

浅析 C# 控制台的 Ctrl+C 是怎么玩的

7

主题

7

帖子

21

积分

新手上路

Rank: 1

积分
21
一:背景

1. 讲故事

上一篇我们聊到了 Console 为什么会卡死,读过那篇文章的朋友相信对 conhost.exe 有了一个大概的了解,这一篇更进一步聊一聊窗口的特殊事件 Ctrl+C 底层流转到底是什么样的,为了方便讲述,让 chagtgpt 给我生成一段Ctrl+C 的业务代码。
  1.     class Program
  2.     {
  3.         static void Main(string[] args)
  4.         {
  5.             Console.CancelKeyPress += new ConsoleCancelEventHandler(CancelKeyPressHandler);
  6.             Console.WriteLine("按下 Ctrl+C 试试看!");
  7.             while (true)
  8.             {
  9.                 // 这里写你的代码
  10.             }
  11.         }
  12.         static void CancelKeyPressHandler(object sender, ConsoleCancelEventArgs e)
  13.         {
  14.             Console.WriteLine("你按下了 Ctrl+C!");
  15.             // 在这里可以添加你希望执行的代码
  16.             e.Cancel = true;
  17.         }
  18.     }
复制代码
然后简单跑一下,确认代码没毛病。

二:发布订阅模式

1. 订阅事件在哪里

相信很多朋友看了这段代码知道这是一种发布订阅模式,代码订阅了 Console.CancelKeyPress 事件,一旦有 Ctrl+C 或者 Ctrl+Break 发生就会自动执行对应的订阅逻辑,但这里有一个问题,Ctrl+C 是一种窗口事件,所以必然会有 Win32 API 的参与,有了这个思路就可以反编译看下 Console.CancelKeyPress 底层到底用没用到 Win32 API ,参考代码如下:
  1. private unsafe static PosixSignalRegistration Register(PosixSignal signal, Action<PosixSignalContext> handler)
  2. {
  3.     Token token = new Token(signal, handler);
  4.     PosixSignalRegistration result = new PosixSignalRegistration(token);
  5.     lock (s_registrations)
  6.     {
  7.         if (s_registrations.Count == 0 && !Interop.Kernel32.SetConsoleCtrlHandler((delegate* unmanaged<int, Interop.BOOL>)(delegate*<int, Interop.BOOL>)(&HandlerRoutine), Add: true))
  8.         {
  9.             throw Win32Marshal.GetExceptionForLastWin32Error();
  10.         }
  11.         s_registrations.Add(token);
  12.         return result;
  13.     }
  14. }
复制代码
从卦中看 handler 是通过 Kernel32.SetConsoleCtrlHandler 方法进行了注册,不相信的话也可以用 windbg 验证一下。
  1. 0:000> bp KERNEL32!SetConsoleCtrlHandler
  2. breakpoint 0 redefined
  3. 0:000> g
  4. 0:000> k 6
  5. # Child-SP          RetAddr               Call Site
  6. 00 00000064`e7b7e948 00007ff9`8162b797     KERNEL32!SetConsoleCtrlHandler
  7. 01 00000064`e7b7e950 00007ff9`817ac3cd     System_Private_CoreLib+0x1ab797
  8. 02 00000064`e7b7ea20 00007ff9`817ac270     System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.Register+0xdd
  9. 03 00000064`e7b7ea90 00007ffa`144f8437     System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.Create+0x10
  10. 04 00000064`e7b7eac0 00007ff9`226f29a1     System_Console!System.Console.add_CancelKeyPress+0x97
  11. 05 00000064`e7b7eb20 00007ff9`8229af33     ConsoleApp1!ConsoleApp1.Program.Main+0x61
  12. ...
复制代码
2. 发布事件在哪里

熟悉Win32编程的朋友相信已经很明白了,原来 C# 的  Ctrl+C 就是基于 win32api 封装的一套玩法,即用KERNEL32!SetConsoleCtrlHandler 来注册, 用KERNELBASE!CtrlRoutine 来发布,要想验证非常简单,可以在回调函数中加一个 Debugger.Break(); 即可。
  1.         static void CancelKeyPressHandler(object sender, ConsoleCancelEventArgs e)
  2.         {
  3.             Console.WriteLine("你按下了 Ctrl+C!");
  4.             // 在这里可以添加你希望执行的代码
  5.             e.Cancel = true;
  6.             Debugger.Break();
  7.         }
复制代码
将程序跑起来后,在控制台上使用Ctrl+C快捷键,这里要注意一点,这个事件会引发一个中断,我们用 gn (Go with Exception Not Handled)来处理,否则 windbg 就会把这个异常通知给吞掉。
  1. 0:000> g
  2. (224c.51c8): Control-C exception - code 40010005 (first chance)
  3. First chance exceptions are reported before any exception handling.
  4. This exception may be expected and handled.
  5. KERNELBASE!CtrlRoutine+0x369ff:
  6. 00007ffa`4ab9169f 0f1f440000      nop     dword ptr [rax+rax]
  7. 0:008> dp rax+rax L1
  8. 00000456`73806260  ????????`????????
  9. 0:008> gn
  10. (224c.51c8): Break instruction exception - code 80000003 (first chance)
  11. KERNELBASE!wil::details::DebugBreak+0x2:
  12. 00007ffa`4ab9d962 cc              int     3
  13. 0:008> k
  14. # Child-SP          RetAddr               Call Site
  15. 00 0000003f`63b7f848 00007ff9`82343ed9     KERNELBASE!wil::details::DebugBreak+0x2
  16. 01 0000003f`63b7f850 00007ff9`8184a66a     coreclr!DebugDebugger::Break+0x149 [D:\a\_work\1\s\src\coreclr\vm\debugdebugger.cpp @ 148]
  17. 02 0000003f`63b7f9d0 00007ff9`227198ca     System_Private_CoreLib!System.Diagnostics.Debugger.Break+0xa [/_/src/coreclr/System.Private.CoreLib/src/System/Diagnostics/Debugger.cs @ 18]
  18. 03 0000003f`63b7fa00 00007ffa`1448922d     ConsoleApp1!ConsoleApp1.Program.CancelKeyPressHandler+0x4a [D:\code\MyApplication\ConsoleApp1\Program.cs @ 32]
  19. 04 0000003f`63b7fa30 00007ff9`817ac6c3     System_Console!System.Console.HandlePosixSignal+0x7d [/_/src/libraries/System.Console/src/System/Console.cs @ 952]
  20. 05 0000003f`63b7fa80 00007ffa`4ab91704     System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.HandlerRoutine+0x193 [/_/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/PosixSignalRegistration.Windows.cs @ 106]
  21. 06 0000003f`63b7fb20 00007ffa`4b667614     KERNELBASE!CtrlRoutine+0x36a64
  22. 07 0000003f`63b7fc10 00007ffa`4cdc26a1     KERNEL32!BaseThreadInitThunk+0x14
  23. 08 0000003f`63b7fc40 00000000`00000000     ntdll!RtlUserThreadStart+0x21
复制代码
从上面的卦信息来看,果然走了 KERNELBASE!CtrlRoutine 逻辑触发了我们的自定义回调函数,我相信心细的朋友肯定会有一个疑问?这个线程是怎么 new 出来的,我的代码中没有创建呀!
3. CtrlRoutine 线程是怎么来的

要回答这个问题,需要你对 windows 操作系统中的一些重要进程有一个了解,比如说 csrss.exe 是干什么的,可以咨询一下 chatgpt。

它的话已经含沙射影的告诉我们,线程有可能是 csrss进程 远程注入的,那是不是这样呢?可以下断点观察。
  1. 0: kd> !process 0 0 csrss.exe
  2. PROCESS ffffe001d350f300
  3.     SessionId: 0  Cid: 0180    Peb: 7ff755c16000  ParentCid: 0178
  4.     DirBase: 1037cd000  ObjectTable: ffffc000a88e0480  HandleCount: <Data Not Accessible>
  5.     Image: csrss.exe
  6. PROCESS ffffe001d351c080
  7.     SessionId: 1  Cid: 01d8    Peb: 7ff75628d000  ParentCid: 01c8
  8.     DirBase: 10471f000  ObjectTable: ffffc000a907a140  HandleCount: <Data Not Accessible>
  9.     Image: csrss.exe
  10. 0: kd> bp /p ffffe001d351c080 ntdll!NtCreateThreadEx
  11. 0: kd> g
  12. 3: kd> .reload /user
  13. 3: kd> k
  14. # Child-SP          RetAddr               Call Site
  15. 00 000000ff`917ff238 00007fff`9e9d6720     ntdll!NtCreateThreadEx
  16. 01 000000ff`917ff240 00007fff`9e9d6602     ntdll!RtlpCreateUserThreadEx+0x110
  17. 02 000000ff`917ff380 00007fff`9b310290     ntdll!RtlCreateUserThread+0x62
  18. 03 000000ff`917ff3f0 00007fff`9b30efb9     winsrv!InternalCreateCallbackThread+0x114
  19. 04 000000ff`917ff4b0 00007fff`9b3109e9     winsrv!CreateCtrlThread+0xe9
  20. 05 000000ff`917ff610 00007fff`9b365837     winsrv!SrvEndTask+0xa9
  21. 06 000000ff`917ff880 00007fff`9e969f75     CSRSRV!CsrApiRequestThread+0x4d7
  22. 07 000000ff`917ffd10 00000000`00000000     ntdll!RtlUserThreadStart+0x45
复制代码
从卦中的 CreateCtrlThread 和 ntdll!NtCreateThreadEx 来看,貌似真的创建了Ctrl+C相关的远程线程,那到底是不是呢,方法签名如下:
  1. NTSTATUS NtCreateThreadEx(
  2.   PHANDLE               ThreadHandle,
  3.   ACCESS_MASK           DesiredAccess,
  4.   POBJECT_ATTRIBUTES    ObjectAttributes,
  5.   HANDLE                ProcessHandle,
  6.   PVOID                 StartRoutine,
  7.   PVOID                 Argument,
  8.   ULONG                 CreateFlags,
  9.   ULONG_PTR             ZeroBits,
  10.   SIZE_T                StackSize,
  11.   SIZE_T                MaximumStackSize,
  12.   PVOID                 AttributeList
  13. );
复制代码
然后用 windbg 提取第五个参数(StartRoutine) 验证下即可,截图如下:

从卦中信息看确实是用 kernelbase!CtrlRoutine 作为线程入口点的,也就得到了验证。
到这里可能又有朋友提出了一个新的问题,上一篇你不是说 conhost.exe 的 GetMessageW 是用来承接窗口事件的吗?比如这个 Ctrl+C 事件,那它怎么通知 csrss.exe 给 ConsoleApp1.exe 注入一个远程线程呢?
4. conhost 如何通知 csrss

这个问题听起来挺烧脑的,其实熟悉Windows编程的朋友都知道,在Windows内核中有一个叫做ALPC的机制专门用来实现进程间通讯,言外之意就是 conhost 和 csrss 有一个 ALPC连接,可以用windbg 的 !alpc 命令观察。
  1. 1: kd> !process 0n4028 0
  2. Searching for Process with Cid == fbc
  3. PROCESS ffffe001d26a3080
  4.     SessionId: 1  Cid: 0fbc    Peb: 7ff680afc000  ParentCid: 05e4
  5.     DirBase: 8b8de000  ObjectTable: ffffc000ab252cc0  HandleCount: <Data Not Accessible>
  6.     Image: conhost.exe
  7. 1: kd> !alpc /lpp ffffe001d26a3080
  8. Ports the process ffffe001d26a3080 is connected to:
  9.         ffffe001d28a25c0 0 -> ffffe001d1749090 ('ApiPort') 1 ffffe001d351c080 ('csrss.exe')
  10.     ...
  11. 1: kd> !process ffffe001d26a3080
  12. ...
  13.         THREAD ffffe001d2250080  Cid 0fbc.0f94  Teb: 00007ff680afe000 Win32Thread: ffffe001d4559fa0 WAIT: (WrLpcReply) UserMode Non-Alertable
  14.             ffffe001d22506b8  Semaphore Limit 0x1
  15.         Waiting for reply to ALPC Message ffffc000b1c6a7a0 : queued at port ffffe001d1749090 : owned by process ffffe001d351c080
  16.         Not impersonating
  17.         DeviceMap                 ffffc000a9ea6f50
  18.         Owning Process            ffffe001d26a3080       Image:         conhost.exe
  19.         Attached Process          N/A            Image:         N/A
  20.         Wait Start TickCount      48619          Ticks: 1 (0:00:00:00.015)
  21.         Context Switch Count      1406           IdealProcessor: 1            
  22.         UserTime                  00:00:00.031
  23.         KernelTime                00:00:00.687
  24.         Win32 Start Address 0x00007fff8e601c90
  25.         Stack Init ffffd00030df4c90 Current ffffd00030df4500
  26.         Base ffffd00030df5000 Limit ffffd00030def000 Call 0000000000000000
  27.         Priority 12 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5
  28.         Child-SP          RetAddr               Call Site
  29.         ffffd000`30df4540 fffff802`792c0090     nt!KiSwapContext+0x76
  30.         ffffd000`30df4680 fffff802`792bfaa8     nt!KiSwapThread+0x160
  31.         ffffd000`30df4730 fffff802`792b86e5     nt!KiCommitThreadWait+0x148
  32.         ffffd000`30df47c0 fffff802`792bc643     nt!KeWaitForSingleObject+0x385
  33.         ffffd000`30df4870 fffff802`7969e70b     nt!AlpcpSignalAndWait+0x213
  34.         ffffd000`30df4910 fffff802`7969f32a     nt!AlpcpReceiveSynchronousReply+0x5b
  35.         ffffd000`30df4970 fffff802`7978f1fd     nt!AlpcpProcessSynchronousRequest+0x34a
  36.         ffffd000`30df4a60 fffff802`7978f142     nt!LpcpRequestWaitReplyPort+0x95
  37.         ffffd000`30df4ac0 fffff802`793cdb63     nt!NtRequestWaitReplyPort+0x6e
  38.         ffffd000`30df4b00 00007fff`9e9f3a4a     nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`30df4b00)
  39.         00000062`3d2bf5d8 00000000`00000000     ntdll!NtRequestWaitReplyPort+0xa
复制代码
仔细观察卦中的信息可以看到,确实有一条和 csrss.exe 通信的 ALPC连接,并且 conhost 正在等待 csrss的消息返回,即 Waiting for reply to ALPC Message。
到这里我觉得所有的疑问都打通了,画一张图大概就是这个样子。

三:总结

这一篇详细的解读了 Ctrl+C 的底层玩法,我觉得更重要的是如何用 windbg 眼见为实,这个才是调试的价值,希望能够给这个问题有疑惑的朋友带来一点价值。

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

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x

举报 回复 使用道具