记一次 .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某医疗器械清洗系统 卡死分析

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

三:总结

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

相信这个案例也让公司老板对他 刮目相看

原文链接:https://www.cnblogs.com/huangxincheng/archive/2023/04/18/17328225.html

本站文章如无特殊说明,均为本站原创,如若转载,请注明出处:记一次 .NET某医疗器械清洗系统 卡死分析 - Python技术站

(0)
上一篇 2023年4月18日
下一篇 2023年4月18日

相关文章

  • C#开发WinForm清空DataGridView控件绑定的数据

    下面我来详细讲解一下。 1. 背景 在 WinForm 应用程序的开发过程中,经常需要使用 DataGridView 控件来显示数据。当需要清空 DataGridView 控件中显示的数据时,我们可以使用如下两种方法: 将 DataGridView 控件绑定的数据源清空; 遍历 DataGridView 控件中的行并逐一删除。 下面分别介绍这两种方法的实现方…

    C# 2023年5月15日
    00
  • 浅谈Java多线程实现及同步互斥通讯

    浅谈Java多线程实现及同步互斥通讯 引言 多线程是指一种多个线程执行完毕后可以得到更好的系统性能的机制。Java多线程的实现是通过创建Thread实例或者继承Thread类并重写它的run()方法来完成的。Java也提供了一个Java.util.concurrent包,它为Java多线程编程提供了更多的助力。在多线程编程中,同步互斥是一种非常重要的问题,它…

    C# 2023年6月7日
    00
  • C#使用async和await实现异步编程

    下面是C#使用async和await实现异步编程的完整攻略。 什么是异步编程? 异步编程是指同时执行多个操作,而且不用等待当前操作完成再去执行下一个操作的编程方式。使用异步编程可以在所有操作都完成之前充分利用资源,提高性能和效率。 C#异步编程的实现方式 在C#中,异步编程可以使用async和await关键字实现。async关键字用于修饰方法,表明该方法是异…

    C# 2023年5月15日
    00
  • .Net实现图片裁剪图片缩放及图片加水印详解

    以下是“.Net实现图片裁剪图片缩放及图片加水印详解”的完整攻略,包括图片裁剪、图片缩放、图片加水印等内容。 图片裁剪 在.NET中实现图片裁剪,您可以使用System.Drawing命名间中的Image类和Graphics类。以下是一个示例,演示如何在.NET中实现图片裁剪: using.Drawing; using System.Drawing.Imag…

    C# 2023年5月12日
    00
  • C#基础知识之GetType与typeof的区别小结

    下面为您详细讲解“C#基础知识之GetType与typeof的区别小结”的攻略。 1. GetType方法 GetType方法是C#中的一个对象方法,返回对象的实际类型。它位于System.Object类中,并且可以被所有派生自System.Object的类调用。 1.1 语法格式 public Type GetType(); 1.2 返回值 GetType…

    C# 2023年6月7日
    00
  • C#表达式树讲解

    C# 表达式树讲解 在 C# 中,表达式树(Expression Tree)是一个类似于代码的树形数据结构,可以表示出一个语法树、一个 lambda 表达式、一个 LINQ 查询等等。 表达式树是由表达式节点构成的,每个节点代表一个表达式或语句。 表达式树的语法 表达式树和 C# 中的 lambda 表达式比较类似,都是由参数、箭头符号和表达式组成。例如以下…

    C# 2023年6月1日
    00
  • Unity实现UI光晕效果(发光效果)

    接下来我将为您介绍如何在Unity中实现UI光晕效果(发光效果)的完整攻略。本攻略中,我将提供两个示例说明来帮助您更好地理解如何实现UI光晕效果。 一、准备工作 在开始实现UI光晕效果之前,我们需要进行一些准备工作: 1. 创建UI元素 我们需要在Unity中创建一个UI元素作为展示光晕效果的对象。您可以按下快捷键“Ctrl + Shift + N”创建一个…

    C# 2023年6月3日
    00
  • 详解datagrid使用方法(重要)

    详解datagrid使用方法(重要) 什么是datagrid? datagrid是一种网格组件,可以在Web应用程序中展示和编辑数据。它以类似于表格的形式,将数据呈现给用户,通常用于显示大量数据的情况,比如数据报表、数据分析等。 如何使用datagrid? 在使用datagrid之前,需要引入datagrid的库文件。目前较为常用的有jQuery EasyU…

    C# 2023年6月1日
    00
合作推广
合作推广
分享本页
返回顶部