技術文章 » 淺析 C# Console 控制檯為什麼也會卡死

淺析 C# Console 控制檯為什麼也會卡死

2023-10-23 15:00:59

一：背景

1. 講故事

在分析旅程中，總會有幾例控制檯的意外卡死導致的生產事故，有經驗的朋友都知道，控制檯卡死一般是動了 快速編輯視窗 的緣故，截圖如下：

雖然知道緣由，但一直沒有時間探究底層原理，市面上也沒有對這塊的底層原理介紹，昨天花了點時間簡單探究了下，算是記錄分享吧。

二：幾個疑問解答

1. 介面為什麼會卡死

相信有很多朋友會有這麼一個疑問？控制檯程式明明沒有 message loop 機制，為什麼還能響應 視窗事件 呢？

說實話這是一個好問題，其實 Console 之所以能響應 視窗事件，是因為它開了一個配套的 conhost 視窗子程序，用它來承接 UI 事件，為了方便闡述，上一段定時向控制檯輸出的測試程式碼。


        static void Main(string[] args)
        {
            for (int i = 0; i < int.MaxValue; i++)
            {
                Console.WriteLine($"i={i}");
                Thread.Sleep(1000);
            }
        }

將程式跑起來，再用 process explorer 觀察程序樹即可。

接下來用 windbg 附加到 conshost 程序上，觀察下有沒有 GetMessageW。


0:005> ~* k
   0  Id: 3ec8.2c20 Suspend: 1 Teb: 000000d2`92014000 Unfrozen
 # Child-SP          RetAddr               Call Site
00 000000d2`922ff798 00007fff`a3e45746     ntdll!NtWaitForSingleObject+0x14
01 000000d2`922ff7a0 00007fff`a60b5bf1     KERNELBASE!DeviceIoControl+0x86
02 000000d2`922ff810 00007ff6`9087a790     KERNEL32!DeviceIoControlImplementation+0x81
03 000000d2`922ff860 00007fff`a60b7614     conhost!ConsoleIoThread+0xd0
04 000000d2`922ff9e0 00007fff`a66a26a1     KERNEL32!BaseThreadInitThunk+0x14
05 000000d2`922ffa10 00000000`00000000     ntdll!RtlUserThreadStart+0x21
...
   2  Id: 3ec8.1b70 Suspend: 1 Teb: 000000d2`9201c000 Unfrozen
 # Child-SP          RetAddr               Call Site
00 000000d2`9227f858 00007fff`a4891b9e     win32u!NtUserGetMessage+0x14
01 000000d2`9227f860 00007ff6`908735c5     user32!GetMessageW+0x2e
02 000000d2`9227f8c0 00007fff`a60b7614     conhost!ConsoleInputThreadProcWin32+0x75
03 000000d2`9227f920 00007fff`a66a26a1     KERNEL32!BaseThreadInitThunk+0x14
04 000000d2`9227f950 00000000`00000000     ntdll!RtlUserThreadStart+0x21
...

2. 程序間如何通訊

這個問題再細化一點就是Client 端通過 Console.WriteLine($"i={i}"); 寫入的內容是如何被 Server 端的conhost!ConsoleIoThread 方法接收到的。

熟悉 Windows 程式設計的朋友都知道：Console.WriteLine 的底層呼叫邏輯是 ntdll!NtWriteFile -> nt!IopSynchronousServiceTail ，前者是使用者態進入到核心態的閘道器函數，後者是使用者將irp丟到執行緒的請求包佇列後進入休眠(KeWaitForSingleObject)，直到驅動提取並處理完之後喚醒。

說了這麼多，怎麼去驗證呢？

  • 使用者端下斷點

0: kd> !process 0 0 ConsoleApp2.exe
PROCESS ffffe001b5e51840
    SessionId: 1  Cid: 0e8c    Peb: 7ff7ab226000  ParentCid: 09d4
    DirBase: 18079000  ObjectTable: ffffc00036965200  HandleCount: <Data Not Accessible>
    Image: ConsoleApp2.exe

0: kd> bp /p ffffe001b5e51840 nt!IopSynchronousServiceTail
0: kd> g
Breakpoint 0 hit
nt!IopSynchronousServiceTail:
fffff802`a94f3410 48895c2420      mov     qword ptr [rsp+20h],rbx
3: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffd000`f6477988 fffff802`a94f2e80     nt!IopSynchronousServiceTail
01 ffffd000`f6477990 fffff802`a916db63     nt!NtWriteFile+0x680
02 ffffd000`f6477a90 00007ffc`2fed38aa     nt!KiSystemServiceCopyEnd+0x13
03 0000009f`0743dbd8 00007ffc`2cd1d478     ntdll!NtWriteFile+0xa
04 0000009f`0743dbe0 00000000`00000005     0x00007ffc`2cd1d478
05 0000009f`0743dbe8 0000009f`0743dcf0     0x5
06 0000009f`0743dbf0 0000009f`0978c9b8     0x0000009f`0743dcf0
07 0000009f`0743dbf8 00007ffc`2986e442     0x0000009f`0978c9b8
08 0000009f`0743dc00 0000009f`0743dc30     0x00007ffc`2986e442
09 0000009f`0743dc08 0000009f`0743de00     0x0000009f`0743dc30
0a 0000009f`0743dc10 00000000`00000005     0x0000009f`0743de00
0b 0000009f`0743dc18 00000000`00000000     0x5

3: kd> tc
nt!IopSynchronousServiceTail+0x70:
fffff802`a94f3480 e8ebf1b5ff      call    nt!IopQueueThreadIrp (fffff802`a9052670)
  • 伺服器端下斷點

conhost端的提取邏輯是在 conhost!ConsoleIoThread 方法中，它的內部呼叫的是 kernelbase!DeviceIoControl 函數，這個方法挺有意思，可以直接給驅動程式下達命令，方法簽名如下：


BOOL DeviceIoControl(
  HANDLE       hDevice,
  DWORD        dwIoControlCode,
  LPVOID       lpInBuffer,
  DWORD        nInBufferSize,
  LPVOID       lpOutBuffer,
  DWORD        nOutBufferSize,
  LPDWORD      lpBytesReturned,
  LPOVERLAPPED lpOverlapped
);

提取完了之後會通過 conhost!DoWriteConsole 向控制檯輸出，接下來可以下個斷點驗證下。


0:000> bp conhost!DoWriteConsole
0:000> g
Breakpoint 0 hit
conhost!DoWriteConsole:
00007ff6`90876ec0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000095`d627f738=0000000000000000
0:000> r
rax=000000000000000c rbx=00000095d627f7b0 rcx=000002370df76cc0
rdx=00000095d627f768 rsi=00000095d627f7c0 rdi=00000095d627f7f0
rip=00007ff690876ec0 rsp=00000095d627f728 rbp=00000095d627f8f9
 r8=000002370bedf010  r9=00000095d627f7b0 r10=000002370df76cc0
r11=000002370e0c9d00 r12=00000095d627f970 r13=000002370bedf010
r14=000002370bedf010 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
conhost!DoWriteConsole:
00007ff6`90876ec0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000095`d627f738=0000000000000000
0:000> du 000002370df76cc0
00000237`0df76cc0  "i=18.."

可以看到果然有一個 i=18，這裡要提醒一下，要想看方法的順序邏輯，可以藉助 perfview。

3. 為什麼快捷編輯之後就卡死

conhost 的原始碼不是公開的，不過可以感官上推測出來。

  1. 快速編輯視窗 被使用者啟用後， GetMessage 會感知到這個自定義的 MSG 訊息。

  2. 這個訊息的邏輯會讓 server 處理Client訊息的流程一直處於等待中，導致 Client 的 IopSynchronousServiceTail 不能被喚醒，導致一直處於阻塞中，類似 Task 的完成狀態一直不被設定。

接下來可以驗證下 快速編輯視窗 的處理訊息碼是多少，只要在控制檯點一下滑鼠。參考指令碼如下：


0:004> bp win32u!NtUserGetMessage "dp ebp-30 L2 ; g"
0:004> g
00000095`d61ffae0  00000000`00130e6e 00000000`00000404
00000095`d61ffae0  00000000`00130e6e 00000000`00000404
00000095`d61ffae0  00000000`00130e6e 00000000`00000201
00000095`d61ffae0  00000000`00130e6e 00000000`00000405
00000095`d61ffae0  00000000`00130e6e 00000000`00000202
00000095`d61ffae0  00000000`00130e6e 00000000`00000200

從 chaggpt 中對每個訊息碼的介紹，可以看到會有一個 405 的自定義訊息，這個就是和 快速編輯視窗 有關的。

三：總結

這篇就是我個人對視窗卡死的推測和記錄，高階偵錯不易，如果大家感興趣，歡迎補充細節。

圖片名稱