记一次 .NET某医疗器械清洗系统卡死分析-Toy模板网

这篇具有很好参考价值的文章主要介绍了记一次 .NET某医疗器械清洗系统卡死分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一：背景

1. 讲故事

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

二：WinDbg 分析

1. 为什么会卡死

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


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

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


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

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

2. 真的卡在内核态吗

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

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

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


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

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


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

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

3. 到底给哪个窗体发消息

要想获取发送窗体的句柄，需要提取 win32kfull!xxxSendMessage 方法的第一个参数，在 x64 的调用协定下，它是用 rcx 传递的，需要分析下汇编代码，如果 rcx 没有放到栈里，那就无法提取了。

为了少点麻烦，建议让朋友看下 32bit 的操作系统上是否也有这个问题？结果反馈说也存在，使用 !thread xxx 切到目标线程，使用 kb 提取第一个参数地址上的值，即：00010598，截图如下：

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

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

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

从 Spy++ 看当前窗体是由进程号:000016E0下的线程号0000109C 创建的，经过比对，这个线程就是本进程的某个线程号。

分析到这里其实就很明朗了，是因为这个线程 0000109C 创建了一个用户控件，导致内核态 在某种情况下给它发消息，接下来就是寻找到底是什么控件创建的。

4. 罪魁祸首

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

接下来就是朋友的苦苦调试，终于给找到了，截图如下：

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