记一次 .NET某医疗器械清洗系统 卡死分析

我在便是晴天

一：背景

1. 讲故事

前段时间协助训练营里的一位朋友分析了一个程序卡死的问题，回过头来看这个案例比较经典，这篇稍微整理一下供后来者少踩坑吧。
二：WinDbg 分析

1. 为什么会卡死

因为是窗体程序，理所当然就是看主线程此时正在做什么? 可以用 ~0s ; k 看一下便知。

1. 0:000> k
2. # ChildEBP RetAddr      
3. 00 00aff168 75e3bb0a     win32u!NtUserPeekMessage+0xc
4. 01 00aff168 75e3ba7e     USER32!_PeekMessage+0x2a
5. 02 00aff1a4 6a5d711c     USER32!PeekMessageW+0x16e
6. 03 00aff1f0 6a5841a6     System_Windows_Forms_ni+0x23711c
7. ...
8. 17 00afffbc 00000000     ntdll!_RtlUserThreadStart+0x1b

复制代码

从线程栈来看，当前的方法卡在 win32u!NtUserPeekMessage 上, 熟悉 Windows 窗体消息的朋友都知道这是提取 消息队列 的常规逻辑，这个方法的下一步就是通过 Wow64SystemServiceCall 进入到 Windows内核态，可以用 u 命令验证一下。

1. 0:000> ub win32u!NtUserPeekMessage+0xc
2. 761d1010 b801100000      mov     eax,1001h
3. 761d1015 ba10631d76      mov     edx,offset win32u!Wow64SystemServiceCall (761d6310)
4. 761d101a ffd2            call    edx

复制代码

朋友也给我截了图，确实出现了卡死，那接下来的问题就是看下当前线程在 内核态 到底在做什么？
2. 真的卡在内核态吗

幸好朋友可以在卡死的机器上安装 windbg，让朋友在卡死的时候使用 Attch to kernel 的方式观察内核态，截图如下：

附加成功后，可以用 !process 0 f xxxx.exe  看到主线程的线程栈。

1. lkd> !process 0 f xxxx.exe
2. PROCESS ffffab8ebea75080
3.     SessionId: 1  Cid: 0f78    Peb: 009f1000  ParentCid: 1134
4.         ...
5.         THREAD ffffab8ecad14540  Cid 0f78.38f8  Teb: 00000000009f3000 Win32Thread: ffffab8ecd5dabc0 WAIT: (WrUserRequest) UserMode Non-Alertable
6.             ffffab8ecb31bcc0  QueueObject
7.         IRP List:
8.             ffffab8ecad82b20: (0006,0478) Flags: 00060000  Mdl: 00000000
9.         Not impersonating
10.         DeviceMap                 ffffd400aa7eed50
11.         Owning Process            ffffab8ebea75080       Image:         xxxx.exe
12.         Attached Process          N/A            Image:         N/A
13.         Wait Start TickCount      1117311        Ticks: 9265 (0:00:02:24.765)
14.         Context Switch Count      60628          IdealProcessor: 2  NoStackSwap
15.         UserTime                  00:00:10.796
16.         KernelTime                00:00:06.593
17.         Win32 Start Address 0x00000000006e16aa
18.         Stack Init ffffa88b5b18fb90 Current ffffa88b5b18e780
19.         Base ffffa88b5b190000 Limit ffffa88b5b189000 Call 0000000000000000
20.         Priority 10 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
21.         Child-SP          RetAddr               Call Site
22.         ffffa88b`5b18e7c0 fffff806`6627e370     nt!KiSwapContext+0x76
23.         ffffa88b`5b18e900 fffff806`6627d89f     nt!KiSwapThread+0x500
24.         ffffa88b`5b18e9b0 fffff806`6627d143     nt!KiCommitThreadWait+0x14f
25.         ffffa88b`5b18ea50 fffff806`6628679b     nt!KeWaitForSingleObject+0x233
26.         ffffa88b`5b18eb40 ffffa9d4`bdd32b12     nt!KeWaitForMultipleObjects+0x45b
27.         ffffa88b`5b18ec50 ffffa9d4`bdd352d9     win32kfull!xxxRealSleepThread+0x362
28.         ffffa88b`5b18ed70 ffffa9d4`bdd33f8a     win32kfull!xxxInterSendMsgEx+0xdd9
29.         ffffa88b`5b18eee0 ffffa9d4`bdd37870     win32kfull!xxxSendTransformableMessageTimeout+0x3ea
30.         ffffa88b`5b18f030 ffffa9d4`bdf1e088     win32kfull!xxxSendMessage+0x2c
31.         ffffa88b`5b18f090 ffffa9d4`bdf1e0e9     win32kfull!xxxCompositedTraverse+0x40
32.         ffffa88b`5b18f0e0 ffffa9d4`bdf1e0e9     win32kfull!xxxCompositedTraverse+0xa1
33.         ffffa88b`5b18f130 ffffa9d4`bdf1e0e9     win32kfull!xxxCompositedTraverse+0xa1
34.         ffffa88b`5b18f180 ffffa9d4`bdf1e0e9     win32kfull!xxxCompositedTraverse+0xa1
35.         ffffa88b`5b18f1d0 ffffa9d4`bdf1e2a7     win32kfull!xxxCompositedTraverse+0xa1
36.         ffffa88b`5b18f220 ffffa9d4`bde5a013     win32kfull!xxxCompositedPaint+0x37
37.         ffffa88b`5b18f2b0 ffffa9d4`bdd2e438     win32kfull!xxxInternalDoPaint+0x12bce3
38.         ffffa88b`5b18f300 ffffa9d4`bdd2e03a     win32kfull!xxxInternalDoPaint+0x108
39.         ffffa88b`5b18f350 ffffa9d4`bdd30f1c     win32kfull!xxxDoPaint+0x52
40.         ffffa88b`5b18f3b0 ffffa9d4`bdd2ff08     win32kfull!xxxRealInternalGetMessage+0xfac
41.         ffffa88b`5b18f880 ffffa9d4`be1871ce     win32kfull!NtUserPeekMessage+0x158
42.         ffffa88b`5b18f940 fffff806`6640d8f5     win32k!NtUserPeekMessage+0x2a
43.         ffffa88b`5b18f990 00007ffe`1816ff74     nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffffa88b`5b18fa00)
44.         00000000`0077e558 00000000`00000000     0x00007ffe`1816ff74

复制代码

如果线程信息很少的话，可以用 .process 将此进程作为当前上下文，然后加载用户符号，输出如下：

1. lkd> .process ffffab8ebea75080
2. Implicit process is now ffffab8e`bea75080
3. lkd> .reload
4. Connected to Windows 10 19041 x64 target at (Tue Mar 21 13:21:21.213 2023 (UTC + 8:00)), ptr64 TRUE
5. Loading Kernel Symbols
6. ...............................................................
7. ................................................................
8. ................................................................
9. .................
10. Loading User Symbols
11. PEB is paged out (Peb.Ldr = 00000000`009f1018).  Type ".hh dbgerr001" for details
12. Loading unloaded module list

复制代码

从刚才的线程栈上看，很明显有一个 win32kfull!xxxSendMessage+0x2c 方法，熟悉 SendMessage 的朋友都知道这个是用来向某个窗体发消息的，那到底是哪一个窗体呢？
3. 到底给哪个窗体发消息

要想获取发送窗体的句柄，需要提取 win32kfull!xxxSendMessage 方法的第一个参数，在 x64 的调用协定下，它是用 rcx 传递的，需要分析下汇编代码，如果 rcx 没有放到栈里，那就无法提取了。
为了少点麻烦，建议让朋友看下 32bit 的操作系统上是否也有这个问题？结果反馈说也存在，使用 !thread xxx 切到目标线程，使用 kb 提取第一个参数地址上的值，即：00010598，截图如下：

丢了一个 sdbgext 插件让朋友看下窗体句柄信息，发现是个 64bit 的，其实除了它还可以用 Spy++ 观察窗体句柄，重点就是找到这个神秘窗体 是由哪个进程下的线程创建的，当把句柄号丢进去后还真给找到了，有点黑暗中寻找到了曙光。截图如下：

从 Spy++ 看当前窗体是由进程号:000016E0下的线程号0000109C 创建的，经过比对，这个线程就是本进程的某个线程号。
分析到这里其实就很明朗了，是因为这个线程 0000109C 创建了一个用户控件，导致内核态 在某种情况下给它发消息，接下来就是寻找到底是什么控件创建的。
4. 罪魁祸首

关于非主线程创建用户控件导致的卡死，我感觉都已经说破嘴皮了，还是有非常多的人犯这个毛病，无语哈，解决办法就是用 bp 去拦截 System.Windows.Forms.Application+MarshalingControl..ctor 方法，具体方案可参考我的文章：【一个超经典 WinForm 卡死问题的再反思】https://www.cnblogs.com/huangxincheng/p/16868486.html
接下来就是朋友的苦苦调试，终于给找到了，截图如下：

对，就是这么一句 Intptr handle =this.Handle 代码，内核句柄的获取让它在这个线程上生根了。
三：总结

就是这么一句代码，来来回回兜了好几圈，花费了朋友个把星期，终于给解决了，也算是一个好结果吧，这个案例需要实时观察程序的内核态和用户态，看 dump 效果不大，造成了这么多时间的浪费。
相信这个案例也让公司老板对他 刮目相看。

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