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

一：背景

1. 讲故事

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

1. 为什么会卡死

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

1. 0:030> ~0s
2. ntdll!NtWaitForSingleObject+0x14:
3. 00007ff8`d2f4d5e4 c3              ret
4. 0:000> k
5. # Child-SP          RetAddr               Call Site
6. 00 000000aa`f859e588 00007ff8`d058920e     ntdll!NtWaitForSingleObject+0x14
7. 01 000000aa`f859e590 00007ff8`d18d6765     KERNELBASE!WaitForSingleObjectEx+0x8e
8. 02 000000aa`f859e630 00007ff8`d18d6049     sechost!ScSendResponseReceiveControls+0x149
9. 03 000000aa`f859e770 00007ff8`d18d5b50     sechost!ScDispatcherLoop+0x159
10. 04 000000aa`f859e8b0 00007ff8`bbe1d439     sechost!StartServiceCtrlDispatcherW+0x70
11. 05 000000aa`f859e8e0 00007ff8`bbe204bc     System_ServiceProcess_ni+0x2d439
12. 06 000000aa`f859e990 00007ff8`621d08dd     System_ServiceProcess_ni!System.ServiceProcess.ServiceBase.Run+0x1dc
13. 07 000000aa`f859ea00 00007ff8`c19812c3     AgvTaskService!AgvTaskService.Program.Main+0x4d
14. 08 000000aa`f859ea40 00007ff8`c184961b     clr!CallDescrWorkerInternal+0x83
15. 09 000000aa`f859ea80 00007ff8`c1898b5a     clr!CallDescrWorkerWithHandler+0x47
16. 0a 000000aa`f859eac0 00007ff8`c1808c95     clr!MethodDescCallSite::CallTargetWorker+0xfa
17. 0b 000000aa`f859ebc0 00007ff8`c180899e     clr!RunMain+0x269
18. 0c 000000aa`f859eda0 00007ff8`c1808735     clr!Assembly::ExecuteMainMethod+0xae
19. 0d 000000aa`f859f080 00007ff8`c180968f     clr!SystemDomain::ExecuteMainMethod+0x619
20. 0e 000000aa`f859f670 00007ff8`c180977d     clr!ExecuteEXE+0x3f
21. 0f 000000aa`f859f6e0 00007ff8`c1809b64     clr!_CorExeMainInternal+0xa9
22. 10 000000aa`f859f770 00007ff8`c3b7d6ea     clr!CorExeMain+0x14
23. 11 000000aa`f859f7b0 00007ff8`c3fdac42     mscoreei!CorExeMain+0xfa
24. 12 000000aa`f859f810 00007ff8`d1e27374     mscoree!CorExeMain_Exported+0x72
25. 13 000000aa`f859f840 00007ff8`d2efcc91     kernel32!BaseThreadInitThunk+0x14
26. 14 000000aa`f859f870 00000000`00000000     ntdll!RtlUserThreadStart+0x21

复制代码

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

1. 0:000> !t
2. ThreadCount:      37
3. UnstartedThread:  0
4. BackgroundThread: 25
5. PendingThread:    0
6. DeadThread:       11
7. Hosted Runtime:   no
8.                                                                                                         Lock  
9.        ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
10.    0    1 154c 000001d5ee9706a0    2a020 Preemptive  0000000000000000:0000000000000000 000001d5ee945930 0     MTA
11.    2    2 57c0 000001d5ee999ba0    2b220 Preemptive  000001D5809EBE88:000001D5809EDDE0 000001d5ee945930 0     MTA (Finalizer)
12. ...
13.   30   42 6c78 000001d5f128e7d0    2b220 Preemptive  000001D5804C0B10:000001D5804C0B10 000001d5ee945930 1     MTA (GC)

复制代码

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

1. 0:000> ~30s;k
2. ntdll!NtWaitForAlertByThreadId+0x14:
3. 00007ff8`d2f50f94 c3              ret
4. # Child-SP          RetAddr               Call Site
5. 00 000000aa`f9f3d2d8 00007ff8`d2f14d7d     ntdll!NtWaitForAlertByThreadId+0x14
6. 01 000000aa`f9f3d2e0 00007ff8`d2f14c32     ntdll!RtlpWaitOnAddressWithTimeout+0x81
7. 02 000000aa`f9f3d310 00007ff8`d2f14a4d     ntdll!RtlpWaitOnAddress+0xae
8. 03 000000aa`f9f3d380 00007ff8`d2edfcb4     ntdll!RtlpWaitOnCriticalSection+0xfd
9. 04 000000aa`f9f3d460 00007ff8`d2edfae2     ntdll!RtlpEnterCriticalSectionContended+0x1c4
10. 05 000000aa`f9f3d4c0 00007ff8`d03c1999     ntdll!RtlEnterCriticalSection+0x42
11. 06 000000aa`f9f3d4f0 00007ff8`d03c4e8e     AisEsmUmh+0x1999
12. 07 000000aa`f9f3d560 00007ff8`d05e5c50     AisEsmUmh+0x4e8e
13. 08 000000aa`f9f3d9d0 00007ff8`c19377c6     KERNELBASE!SuspendThread+0x10
14. 09 000000aa`f9f3da00 00007ff8`c1824381     clr!Thread::SuspendThread+0xee
15. 0a 000000aa`f9f3df80 00007ff8`c1823696     clr!ThreadSuspend::SuspendRuntime+0x205
16. 0b 000000aa`f9f3e060 00007ff8`c18220c0     clr!ThreadSuspend::SuspendEE+0xf6
17. 0c 000000aa`f9f3e140 00007ff8`c198f0cb     clr!WKS::GCHeap::GarbageCollectGeneration+0x270
18. 0d 000000aa`f9f3e200 00007ff8`c18f58ae     clr!WKS::gc_heap::try_allocate_more_space+0x4fb
19. 0e 000000aa`f9f3e260 00007ff8`c18ac7a8     clr!WKS::GCHeap::Alloc+0x5e
20. 0f 000000aa`f9f3e2b0 00007ff8`622081cb     clr!JIT_New+0x1b8
21. 10 000000aa`f9f3e540 00007ff8`62207670     System_Core_ni!System.Linq.Enumerable.TakeIterator<byte>+0x1b
22. 11 000000aa`f9f3e580 00007ff8`bf530bf8     DAL!DAL.Request.OnReceivedServerData+0x50
23. 12 000000aa`f9f3e5d0 00007ff8`bf530ae5     mscorlib_ni!System.Threading.ExecutionContext.RunInternal+0x108 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 980]
24. 13 000000aa`f9f3e6a0 00007ff8`bf530ab5     mscorlib_ni!System.Threading.ExecutionContext.Run+0x15 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 928]
25. 14 000000aa`f9f3e6d0 00007ff8`bfebd5a0     mscorlib_ni!System.Threading.ExecutionContext.Run+0x55 [f:\dd\ndp\clr\src\BCL\system\threading\executioncontext.cs @ 917]
26. 15 000000aa`f9f3e720 00007ff8`c19812c3     mscorlib_ni!System.Threading.ThreadHelper.ThreadStart+0x60 [f:\dd\ndp\clr\src\BCL\system\threading\thread.cs @ 93]
27. 16 000000aa`f9f3e760 00007ff8`c184961b     clr!CallDescrWorkerInternal+0x83
28. 17 000000aa`f9f3e7a0 00007ff8`c1898b5a     clr!CallDescrWorkerWithHandler+0x47
29. 18 000000aa`f9f3e7e0 00007ff8`c1b91659     clr!MethodDescCallSite::CallTargetWorker+0xfa
30. 19 000000aa`f9f3e8e0 00007ff8`c186230b     clr!ThreadNative::KickOffThread_Worker+0x2186d9
31. 1a 000000aa`f9f3eb30 00007ff8`c186222f     clr!ManagedThreadBase_DispatchInner+0x33
32. 1b 000000aa`f9f3eb70 00007ff8`c18620fb     clr!ManagedThreadBase_DispatchMiddle+0x83
33. 1c 000000aa`f9f3ec60 00007ff8`c186206f     clr!ManagedThreadBase_DispatchOuter+0x87
34. 1d 000000aa`f9f3ecf0 00007ff8`c1979e11     clr!ManagedThreadBase_FullTransitionWithAD+0x2f
35. 1e 000000aa`f9f3ed50 00007ff8`c19658ea     clr!ThreadNative::KickOffThread+0xe1
36. 1f 000000aa`f9f3ee10 00007ff8`d1e27374     clr!Thread::intermediateThreadProc+0x8a
37. 20 000000aa`f9f3f750 00007ff8`d2efcc91     kernel32!BaseThreadInitThunk+0x14
38. 21 000000aa`f9f3f780 00000000`00000000     ntdll!RtlUserThreadStart+0x21

复制代码

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

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

1. 0:030> !lmi AisEsmUmh
2. Loaded Module Info: [aisesmumh]
3.          Module: AisEsmUmh
4.    Base Address: 00007ff8d03c0000
5.      Image Name: AisEsmUmh.dll
6.    Machine Type: 34404 (X64)
7.      Time Stamp: 66bc19bf Wed Aug 14 10:43:11 2024
8.            Size: 5a000
9.        CheckSum: 67da6
10. Characteristics: 2022  
11. Debug Data Dirs: Type  Size     VA  Pointer
12.              CODEVIEW    78, 43e90,   42a90 RSDS - GUID: {08FF691A-7607-413D-9F3C-7DD20738D992}
13.                Age: 1, Pdb: e:\xxx\TRUSTONE_EDR\xxx\Win64\AisEsmUmh_X64.pdb
14.            VC_FEATURE    10, 43f08,   42b08 [Data not mapped]
15.      Image Type: MEMORY   - Image read successfully from loaded memory.
16.     Symbol Type: NONE     - PDB not found from symbol server.
17.     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 迟迟得不到结束，哎，窗体类程序的生存环境举步维艰啊。。。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

新版吗？好像是停更了吧。