浅析 C# 控制台的 Ctrl+C 是怎么玩的
一：背景
1. 讲故事
上一篇我们聊到了 Console 为什么会卡死，读过那篇文章的朋友相信对 conhost.exe 有了一个大概的了解，这一篇更进一步聊一聊窗口的特殊事件 Ctrl+C 底层流转到底是什么样的，为了方便讲述，让 chagtgpt 给我生成一段Ctrl+C 的业务代码。
class Program
{
static void Main(string[] args)
{
Console.CancelKeyPress += new ConsoleCancelEventHandler(CancelKeyPressHandler);
Console.WriteLine("按下 Ctrl+C 试试看！");
while (true)
{
// 这里写你的代码
}
}
static void CancelKeyPressHandler(object sender, ConsoleCancelEventArgs e)
{
Console.WriteLine("你按下了 Ctrl+C！");
// 在这里可以添加你希望执行的代码
e.Cancel = true;
}
}
然后简单跑一下，确认代码没毛病。
二：发布订阅模式
1. 订阅事件在哪里
相信很多朋友看了这段代码知道这是一种发布订阅模式，代码订阅了 Console.CancelKeyPress 事件，一旦有 Ctrl+C 或者 Ctrl+Break 发生就会自动执行对应的订阅逻辑，但这里有一个问题，Ctrl+C 是一种窗口事件，所以必然会有 Win32 API 的参与，有了这个思路就可以反编译看下 Console.CancelKeyPress 底层到底用没用到 Win32 API ，参考代码如下：
private unsafe static PosixSignalRegistration Register(PosixSignal signal, Action<PosixSignalContext> handler)
{
Token token = new Token(signal, handler);
PosixSignalRegistration result = new PosixSignalRegistration(token);
lock (s_registrations)
{
if (s_registrations.Count == 0 && !Interop.Kernel32.SetConsoleCtrlHandler((delegate* unmanaged<int, Interop.BOOL>)(delegate*<int, Interop.BOOL>)(&HandlerRoutine), Add: true))
{
throw Win32Marshal.GetExceptionForLastWin32Error();
}
s_registrations.Add(token);
return result;
}
}
从卦中看 handler 是通过 Kernel32.SetConsoleCtrlHandler 方法进行了注册，不相信的话也可以用 windbg 验证一下。
0:000> bp KERNEL32!SetConsoleCtrlHandler
breakpoint 0 redefined
0:000> g
0:000> k 6
# Child-SP RetAddr Call Site
00 00000064`e7b7e948 00007ff9`8162b797 KERNEL32!SetConsoleCtrlHandler
01 00000064`e7b7e950 00007ff9`817ac3cd System_Private_CoreLib+0x1ab797
02 00000064`e7b7ea20 00007ff9`817ac270 System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.Register+0xdd
03 00000064`e7b7ea90 00007ffa`144f8437 System_Private_CoreLib!System.Runtime.InteropServices.PosixSignalRegistration.Create+0x10
04 00000064`e7b7eac0 00007ff9`226f29a1 System_Console!System.Console.add_CancelKeyPress+0x97
05 00000064`e7b7eb20 00007ff9`8229af33 ConsoleApp1!ConsoleApp1.Program.Main+0x61
...
2. 发布事件在哪里
熟悉Win32编程的朋友相信已经很明白了，原来 C# 的 Ctrl+C 就是基于 win32api 封装的一套玩法，即用KERNEL32!SetConsoleCtrlHandler 来注册, 用KERNELBASE!CtrlRoutine 来发布，要想验证非常简单，可以在回调函数中加一个 Debugger.Break(); 即可。
static void CancelKeyPressHandler(object sender, ConsoleCancelEventArgs e)
{
Console.WriteLine("你按下了 Ctrl+C！");
// 在这里可以添加你希望执行的代码
e.Cancel = true;
Debugger.Break();
}
将程序跑起来后，在控制台上使用Ctrl+C快捷键，这里要注意一点，这个事件会引发一个中断，我们用 gn （Go with Exception Not Handled）来处理，否则 windbg 就会把这个异常通知给吞掉。
0:000> g
(224c.51c8): Control-C exception - code 40010005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
KERNELBASE!CtrlRoutine+0x369ff:
00007ffa`4ab9169f 0f1f440000 nop dword ptr [rax+rax]
0:008> dp rax+rax L1
00000456`73806260 ????????`????????
0:008> gn
(224c.51c8): Break instruction exception - code 80000003 (first chance)
KERNELBASE!wil::details::DebugBreak+0x2:
00007ffa`4ab9d962 cc int 3
0:008> k
# Child-SP RetAddr Call Site
00 0000003f`63b7f848 00007ff9`82343ed9 KERNELBASE!wil::details::DebugBreak+0x2
01 0000003f`63b7f850 00007ff9`8184a66a coreclr!DebugDebugger::Break+0x149 [D:\a\_work\1\s\src\coreclr\vm\debugdebugger.cpp @ 148]
02 0000003f`63b7f9d0 00007ff9`227198ca System_Private_CoreLib!System.Diagnostics.Debugger.Break+0xa [/_/src/coreclr/System.Private.CoreLib/src/System/Diagnostics/Debugger.cs @ 18]
03 0000003f`63b7fa00 00007ffa`1448922d ConsoleApp1!ConsoleApp1.Program.CancelKeyPressHandler+0x4a [D:\code\MyApplication\ConsoleApp1\Program.cs @ 32]
04 0000003f`63b7fa30 00007ff9`817ac6c3 System_Console!System.Console.HandlePosixSignal+0x7d [/_/src/libraries/System.Console/src/System/Console.cs @ 952]
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]
06 0000003f`63b7fb20 00007ffa`4b667614 KERNELBASE!CtrlRoutine+0x36a64
07 0000003f`63b7fc10 00007ffa`4cdc26a1 KERNEL32!BaseThreadInitThunk+0x14
08 0000003f`63b7fc40 00000000`00000000 ntdll!RtlUserThreadStart+0x21
从上面的卦信息来看，果然走了 KERNELBASE!CtrlRoutine 逻辑触发了我们的自定义回调函数，我相信心细的朋友肯定会有一个疑问？这个线程是怎么 new 出来的，我的代码中没有创建呀！
3. CtrlRoutine 线程是怎么来的
要回答这个问题，需要你对 windows 操作系统中的一些重要进程有一个了解，比如说 csrss.exe 是干什么的，可以咨询一下 chatgpt。
它的话已经含沙射影的告诉我们，线程有可能是 csrss进程 远程注入的，那是不是这样呢？可以下断点观察。
0: kd> !process 0 0 csrss.exe
PROCESS ffffe001d350f300
SessionId: 0 Cid: 0180 Peb: 7ff755c16000 ParentCid: 0178
DirBase: 1037cd000 ObjectTable: ffffc000a88e0480 HandleCount: <Data Not Accessible>
Image: csrss.exe
PROCESS ffffe001d351c080
SessionId: 1 Cid: 01d8 Peb: 7ff75628d000 ParentCid: 01c8
DirBase: 10471f000 ObjectTable: ffffc000a907a140 HandleCount: <Data Not Accessible>
Image: csrss.exe
0: kd> bp /p ffffe001d351c080 ntdll!NtCreateThreadEx
0: kd> g
3: kd> .reload /user
3: kd> k
# Child-SP RetAddr Call Site
00 000000ff`917ff238 00007fff`9e9d6720 ntdll!NtCreateThreadEx
01 000000ff`917ff240 00007fff`9e9d6602 ntdll!RtlpCreateUserThreadEx+0x110
02 000000ff`917ff380 00007fff`9b310290 ntdll!RtlCreateUserThread+0x62
03 000000ff`917ff3f0 00007fff`9b30efb9 winsrv!InternalCreateCallbackThread+0x114
04 000000ff`917ff4b0 00007fff`9b3109e9 winsrv!CreateCtrlThread+0xe9
05 000000ff`917ff610 00007fff`9b365837 winsrv!SrvEndTask+0xa9
06 000000ff`917ff880 00007fff`9e969f75 CSRSRV!CsrApiRequestThread+0x4d7
07 000000ff`917ffd10 00000000`00000000 ntdll!RtlUserThreadStart+0x45
从卦中的 CreateCtrlThread 和 ntdll!NtCreateThreadEx 来看，貌似真的创建了Ctrl+C相关的远程线程，那到底是不是呢，方法签名如下：
NTSTATUS NtCreateThreadEx(
PHANDLE ThreadHandle,
ACCESS_MASK DesiredAccess,
POBJECT_ATTRIBUTES ObjectAttributes,
HANDLE ProcessHandle,
PVOID StartRoutine,
PVOID Argument,
ULONG CreateFlags,
ULONG_PTR ZeroBits,
SIZE_T StackSize,
SIZE_T MaximumStackSize,
PVOID AttributeList
);
然后用 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: kd> !process 0n4028 0
Searching for Process with Cid == fbc
PROCESS ffffe001d26a3080
SessionId: 1 Cid: 0fbc Peb: 7ff680afc000 ParentCid: 05e4
DirBase: 8b8de000 ObjectTable: ffffc000ab252cc0 HandleCount: <Data Not Accessible>
Image: conhost.exe
1: kd> !alpc /lpp ffffe001d26a3080
Ports the process ffffe001d26a3080 is connected to:
ffffe001d28a25c0 0 -> ffffe001d1749090 ('ApiPort') 1 ffffe001d351c080 ('csrss.exe')
...
1: kd> !process ffffe001d26a3080
...
THREAD ffffe001d2250080 Cid 0fbc.0f94 Teb: 00007ff680afe000 Win32Thread: ffffe001d4559fa0 WAIT: (WrLpcReply) UserMode Non-Alertable
ffffe001d22506b8 Semaphore Limit 0x1
Waiting for reply to ALPC Message ffffc000b1c6a7a0 : queued at port ffffe001d1749090 : owned by process ffffe001d351c080
Not impersonating
DeviceMap ffffc000a9ea6f50
Owning Process ffffe001d26a3080 Image: conhost.exe
Attached Process N/A Image: N/A
Wait Start TickCount 48619 Ticks: 1 (0:00:00:00.015)
Context Switch Count 1406 IdealProcessor: 1
UserTime 00:00:00.031
KernelTime 00:00:00.687
Win32 Start Address 0x00007fff8e601c90
Stack Init ffffd00030df4c90 Current ffffd00030df4500
Base ffffd00030df5000 Limit ffffd00030def000 Call 0000000000000000
Priority 12 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5
Child-SP RetAddr Call Site
ffffd000`30df4540 fffff802`792c0090 nt!KiSwapContext+0x76
ffffd000`30df4680 fffff802`792bfaa8 nt!KiSwapThread+0x160
ffffd000`30df4730 fffff802`792b86e5 nt!KiCommitThreadWait+0x148
ffffd000`30df47c0 fffff802`792bc643 nt!KeWaitForSingleObject+0x385
ffffd000`30df4870 fffff802`7969e70b nt!AlpcpSignalAndWait+0x213
ffffd000`30df4910 fffff802`7969f32a nt!AlpcpReceiveSynchronousReply+0x5b
ffffd000`30df4970 fffff802`7978f1fd nt!AlpcpProcessSynchronousRequest+0x34a
ffffd000`30df4a60 fffff802`7978f142 nt!LpcpRequestWaitReplyPort+0x95
ffffd000`30df4ac0 fffff802`793cdb63 nt!NtRequestWaitReplyPort+0x6e
ffffd000`30df4b00 00007fff`9e9f3a4a nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`30df4b00)
00000062`3d2bf5d8 00000000`00000000 ntdll!NtRequestWaitReplyPort+0xa
仔细观察卦中的信息可以看到，确实有一条和 csrss.exe 通信的 ALPC连接，并且 conhost 正在等待 csrss的消息返回，即 Waiting for reply to ALPC Message。
到这里我觉得所有的疑问都打通了，画一张图大概就是这个样子。
三：总结
这一篇详细的解读了 Ctrl+C 的底层玩法，我觉得更重要的是如何用 windbg 眼见为实，这个才是调试的价值，希望能够给这个问题有疑惑的朋友带来一点价值。
