淺析 C# Console 控制臺為什么也會(huì)卡死
當(dāng)前位置：點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
一：背景1. 講故事在分析旅程中，總會(huì)有幾例控制臺的意外卡死導(dǎo)致的生產(chǎn)事故，有經(jīng)驗(yàn)的朋友都知道，控制臺卡死一般是動(dòng)了
雖然知道緣由，但一直沒有時(shí)間探究底層原理，市面上也沒有對這塊的底層原理介紹，昨天花了點(diǎn)時(shí)間簡單探究了下，算是記錄分享吧。 二：幾個(gè)疑問解答1. 界面為什么會(huì)卡死相信有很多朋友會(huì)有這么一個(gè)疑問？控制臺程序明明沒有 說實(shí)話這是一個(gè)好問題，其實(shí) Console 之所以能響應(yīng) 窗口事件，是因?yàn)樗_了一個(gè)配套的 conhost 窗口子進(jìn)程，用它來承接 UI 事件，為了方便闡述，上一段定時(shí)向控制臺輸出的測試代碼。 static void Main(string[] args)
{ for (int i = 0; i < int.MaxValue; i++)
{
Console.WriteLine($"i={i}");
Thread.Sleep(1000);
}
}將程序跑起來，再用 process explorer 觀察進(jìn)程樹即可。
接下來用 windbg 附加到 conshost 進(jìn)程上，觀察下有沒有 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. 進(jìn)程間如何通訊這個(gè)問題再細(xì)化一點(diǎn)就是Client 端通過 熟悉 Windows 編程的朋友都知道：Console.WriteLine 的底層調(diào)用邏輯是 說了這么多，怎么去驗(yàn)證呢？
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端的提取邏輯是在 BOOL DeviceIoControl( HANDLE hDevice, DWORD dwIoControlCode, LPVOID lpInBuffer, DWORD nInBufferSize, LPVOID lpOutBuffer, DWORD nOutBufferSize, LPDWORD lpBytesReturned, LPOVERLAPPED lpOverlapped ); 提取完了之后會(huì)通過 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.." 可以看到果然有一個(gè)
3. 為什么快捷編輯之后就卡死conhost 的源碼不是公開的，不過可以感官上推測出來。
接下來可以驗(yàn)證下 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 中對每個(gè)消息碼的介紹，可以看到會(huì)有一個(gè) 405 的自定義消息，這個(gè)就是和 三：總結(jié)這篇就是我個(gè)人對窗口卡死的推測和記錄，高級調(diào)試不易，如果大家感興趣，歡迎補(bǔ)充細(xì)節(jié)。 作者：一線碼農(nóng) 來源：博客園 該文章在 2023/10/28 10:15:11 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
