淺析 C# 控制檯的 Ctrl+C 是怎麼玩的

一線碼農發表於2023-10-24
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 眼見為實，這個才是除錯的價值，希望能夠給這個問題有疑惑的朋友帶來一點價值。

圖片名稱

相關文章