记一次 .NET 某汽车控制焊接软件卡死分析

一：背景

1. 讲故事

前些天有位朋友找到我，说他们开发的在客户工厂里的窗体程序出现了卡死情况，并且 Ctrl+C 也退不出来，自己分析了下也没找出是什么原因，后来在网络上就找到了我，让我帮忙看下怎么回事？毕竟我在这一块是专业的。。。哈哈，既然有dump，那就拿出来分析一下。

二：卡死分析

1. 为什么会卡死

既然是窗体，那就看主线程呗，使用 ~0s;k 即可，调用栈如下：



0:030> ~0s

ntdll!NtWaitForSingleObject+0x14:

00007ff8`d2f4d5e4 c3              ret

0:000> k

 # Child-SP          RetAddr               Call Site

00 000000aa`f859e588 00007ff8`d058920e     ntdll!NtWaitForSingleObject+0x14

01 000000aa`f859e590 00007ff8`d18d6765     KERNELBASE!WaitForSingleObjectEx+0x8e

02 000000aa`f859e630 00007ff8`d18d6049     sechost!ScSendResponseReceiveControls+0x149

03 000000aa`f859e770 00007ff8`d18d5b50     sechost!ScDispatcherLoop+0x159

04 000000aa`f859e8b0 00007ff8`bbe1d439     sechost!StartServiceCtrlDispatcherW+0x70

05 000000aa`f859e8e0 00007ff8`bbe204bc     System_ServiceProcess_ni+0x2d439

06 000000aa`f859e990 00007ff8`621d08dd     System_ServiceProcess_ni!System.ServiceProcess.ServiceBase.Run+0x1dc

07 000000aa`f859ea00 00007ff8`c19812c3     AgvTaskService!AgvTaskService.Program.Main+0x4d

08 000000aa`f859ea40 00007ff8`c184961b     clr!CallDescrWorkerInternal+0x83

09 000000aa`f859ea80 00007ff8`c1898b5a     clr!CallDescrWorkerWithHandler+0x47

0a 000000aa`f859eac0 00007ff8`c1808c95     clr!MethodDescCallSite::CallTargetWorker+0xfa

0b 000000aa`f859ebc0 00007ff8`c180899e     clr!RunMain+0x269

0c 000000aa`f859eda0 00007ff8`c1808735     clr!Assembly::ExecuteMainMethod+0xae

0d 000000aa`f859f080 00007ff8`c180968f     clr!SystemDomain::ExecuteMainMethod+0x619

0e 000000aa`f859f670 00007ff8`c180977d     clr!ExecuteEXE+0x3f

0f 000000aa`f859f6e0 00007ff8`c1809b64     clr!_CorExeMainInternal+0xa9

10 000000aa`f859f770 00007ff8`c3b7d6ea     clr!CorExeMain+0x14

11 000000aa`f859f7b0 00007ff8`c3fdac42     mscoreei!CorExeMain+0xfa

12 000000aa`f859f810 00007ff8`d1e27374     mscoree!CorExeMain_Exported+0x72

13 000000aa`f859f840 00007ff8`d2efcc91     kernel32!BaseThreadInitThunk+0x14

14 000000aa`f859f870 00000000`00000000     ntdll!RtlUserThreadStart+0x21

从卦中的 StartServiceCtrlDispatcherW 来看确实响应了 Ctrl+C 事件，并在非托管层等待 NtWaitForSingleObject 事件的完成，接下来的问题是为什么 Ctrl+C 完成不了？很显然有线程没有优雅的退出，所以目光就转移到其他的线程栈，使用 !t 观察下托管线程列表。



0:000> !t

ThreadCount:      37

UnstartedThread:  0

BackgroundThread: 25

PendingThread:    0

DeadThread:       11

Hosted Runtime:   no

                                                                                                        Lock

       ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception

   0    1 154c 000001d5ee9706a0    2a020 Preemptive  0000000000000000:0000000000000000 000001d5ee945930 0     MTA

   2    2 57c0 000001d5ee999ba0    2b220 Preemptive  000001D5809EBE88:000001D5809EDDE0 000001d5ee945930 0     MTA (Finalizer)

...

  30   42 6c78 000001d5f128e7d0    2b220 Preemptive  000001D5804C0B10:000001D5804C0B10 000001d5ee945930 1     MTA (GC)

从卦象看很不吉利，有一个 (GC) 字样，表示当前程序触发了 GC，接下来就是切过来观察下 GC 此时正在做什么？使用 ~30s;k 即可。



0:000> ~30s;k

ntdll!NtWaitForAlertByThreadId+0x14:

00007ff8`d2f50f94 c3              ret

 # Child-SP          RetAddr               Call Site

00 000000aa`f9f3d2d8 00007ff8`d2f14d7d     ntdll!NtWaitForAlertByThreadId+0x14

01 000000aa`f9f3d2e0 00007ff8`d2f14c32     ntdll!RtlpWaitOnAddressWithTimeout+0x81

02 000000aa`f9f3d310 00007ff8`d2f14a4d     ntdll!RtlpWaitOnAddress+0xae

03 000000aa`f9f3d380 00007ff8`d2edfcb4     ntdll!RtlpWaitOnCriticalSection+0xfd

04 000000aa`f9f3d460 00007ff8`d2edfae2     ntdll!RtlpEnterCriticalSectionContended+0x1c4

05 000000aa`f9f3d4c0 00007ff8`d03c1999     ntdll!RtlEnterCriticalSection+0x42

06 000000aa`f9f3d4f0 00007ff8`d03c4e8e     AisEsmUmh+0x1999

07 000000aa`f9f3d560 00007ff8`d05e5c50     AisEsmUmh+0x4e8e

08 000000aa`f9f3d9d0 00007ff8`c19377c6     KERNELBASE!SuspendThread+0x10

09 000000aa`f9f3da00 00007ff8`c1824381     clr!Thread::SuspendThread+0xee

0a 000000aa`f9f3df80 00007ff8`c1823696     clr!ThreadSuspend::SuspendRuntime+0x205

0b 000000aa`f9f3e060 00007ff8`c18220c0     clr!ThreadSuspend::SuspendEE+0xf6

0c 000000aa`f9f3e140 00007ff8`c198f0cb     clr!WKS::GCHeap::GarbageCollectGeneration+0x270

0d 000000aa`f9f3e200 00007ff8`c18f58ae     clr!WKS::gc_heap::try_allocate_more_space+0x4fb

0e 000000aa`f9f3e260 00007ff8`c18ac7a8     clr!WKS::GCHeap::Alloc+0x5e

0f 000000aa`f9f3e2b0 00007ff8`622081cb     clr!JIT_New+0x1b8

10 000000aa`f9f3e540 00007ff8`62207670     System_Core_ni!System.Linq.Enumerable.TakeIterator<byte>+0x1b

11 000000aa`f9f3e580 00007ff8`bf530bf8     DAL!DAL.Request.OnReceivedServerData+0x50

12 000000aa`f9f3e5d0 00007ff8`bf530ae5     mscorlib_ni!System.Threading.ExecutionContext.RunInternal+0x108 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 980]

13 000000aa`f9f3e6a0 00007ff8`bf530ab5     mscorlib_ni!System.Threading.ExecutionContext.Run+0x15 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 928]

14 000000aa`f9f3e6d0 00007ff8`bfebd5a0     mscorlib_ni!System.Threading.ExecutionContext.Run+0x55 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 917]

15 000000aa`f9f3e720 00007ff8`c19812c3     mscorlib_ni!System.Threading.ThreadHelper.ThreadStart+0x60 [f:\dd\ndp\clr\src\BCL\system\threading\thread.cs @ 93]

16 000000aa`f9f3e760 00007ff8`c184961b     clr!CallDescrWorkerInternal+0x83

17 000000aa`f9f3e7a0 00007ff8`c1898b5a     clr!CallDescrWorkerWithHandler+0x47

18 000000aa`f9f3e7e0 00007ff8`c1b91659     clr!MethodDescCallSite::CallTargetWorker+0xfa

19 000000aa`f9f3e8e0 00007ff8`c186230b     clr!ThreadNative::KickOffThread_Worker+0x2186d9

1a 000000aa`f9f3eb30 00007ff8`c186222f     clr!ManagedThreadBase_DispatchInner+0x33

1b 000000aa`f9f3eb70 00007ff8`c18620fb     clr!ManagedThreadBase_DispatchMiddle+0x83

1c 000000aa`f9f3ec60 00007ff8`c186206f     clr!ManagedThreadBase_DispatchOuter+0x87

1d 000000aa`f9f3ecf0 00007ff8`c1979e11     clr!ManagedThreadBase_FullTransitionWithAD+0x2f

1e 000000aa`f9f3ed50 00007ff8`c19658ea     clr!ThreadNative::KickOffThread+0xe1

1f 000000aa`f9f3ee10 00007ff8`d1e27374     clr!Thread::intermediateThreadProc+0x8a

20 000000aa`f9f3f750 00007ff8`d2efcc91     kernel32!BaseThreadInitThunk+0x14

21 000000aa`f9f3f780 00000000`00000000     ntdll!RtlUserThreadStart+0x21

从卦象看，在 SuspendThread 的下游有一个 AisEsmUmh.dll，很显然这不是 coreclr 自带的，貌似被人家注入了，并且在 AisEsmUmh 的下游通过cs锁阻塞了当前的执行流，接下来的问题是 AisEsmUmh.dll 到底为何方神圣。

2. AisEsmUmh 到底是什么

要想知道是什么，可以使用 !lmi AisEsmUmh 命令即可，参考如下：



0:030> !lmi AisEsmUmh

Loaded Module Info: [aisesmumh]

         Module: AisEsmUmh

   Base Address: 00007ff8d03c0000

     Image Name: AisEsmUmh.dll

   Machine Type: 34404 (X64)

     Time Stamp: 66bc19bf Wed Aug 14 10:43:11 2024

           Size: 5a000

       CheckSum: 67da6

Characteristics: 2022

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    78, 43e90,   42a90 RSDS - GUID: {08FF691A-7607-413D-9F3C-7DD20738D992}

               Age: 1, Pdb: e:\xxx\TRUSTONE_EDR\xxx\Win64\AisEsmUmh_X64.pdb

           VC_FEATURE    10, 43f08,   42b08 [Data not mapped]

     Image Type: MEMORY   - Image read successfully from loaded memory.

    Symbol Type: NONE     - PDB not found from symbol server.

    Load Report: no symbols loaded

从卦中可以看到，这个 AisEsmUmh_X64 目录中有一个 TRUSTONE_EDR 路径，看到这个 EDR（Endpoint Detection and Response）我相信大家都知道是什么了，对。。。就是安全软件，最后在 baidu 上搜一下 AisEsmUmh_X64 即可。

原来是 亚信安全 捣的鬼。。。到这里就彻底水落石出了。

3. 亚信安全为什么要拦截

最后我们稍微解释下为什么会有拦截行为，大家都知道托管语言都有 GC 这么个东西，GC触发的时候会暂停所有的托管线程，俗称 STW（Stop The World），这里的暂停是一个抽象概念，CLR 会通过各种途径将托管线程引流到一个 event 事件上，其中就不乏 HiJack 方式，这个在coreclr源码中都是有痕迹的，截图如下：

这种 线程劫持 行为是被大多数杀毒软件所不容的，有些智能点的杀毒软件会放行，有些则不放，最后就导致这种灾难性的后果。

解决办法也比较简单：

关闭亚信安全。
添加白名单，或者你懂的的方式

三：总结

这次卡死事故原因是安全软件介入了 GC 过程，让 STW 迟迟得不到结束，哎，窗体类程序的生存环境举步维艰啊。。。