記一次 .NET 某汽車控制焊接軟件卡死分析

一：背景

1. 講故事

前些天有位朋友找到我，說他們開發(fā)的在客戶工廠里的窗體程序出現(xiàn)了卡死情況，并且 Ctrl+C 也退不出來，自己分析了下也沒找出是什么原因，后來在網絡上就找到了我，讓我?guī)兔聪略趺椿厥拢?畢竟我在這一塊是專業(yè)的。。。哈哈，既然有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 完成不了？很顯然有線程沒有優(yōu)雅的退出，所以目光就轉移到其他的線程棧，使用 !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) 字樣，表示當前程序觸發(fā)了 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鎖阻塞了當前的執(zhí)行流，接下來的問題是 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觸發(fā)的時候會暫停所有的托管線程，俗稱 STW（Stop The World），這里的暫停是一個抽象概念，CLR 會通過各種途徑將托管線程引流到一個 event 事件上，其中就不乏 HiJack 方式，這個在coreclr源碼中都是有痕跡的，截圖如下：

這種 線程劫持 行為是被大多數殺毒軟件所不容的，有些智能點的殺毒軟件會放行，有些則不放，最后就導致這種災難性的后果。

解決辦法也比較簡單：

關閉亞信安全。
添加白名單，或者你懂的的方式

三：總結

這次卡死事故原因是安全軟件介入了 GC 過程，讓 STW 遲遲得不到結束，哎，窗體類程序的生存環(huán)境舉步維艱啊。。。

posted @ 2025-08-12 11:08 一線碼農閱讀(1655) 評論(5) 收藏舉報

刷新頁面返回頂部

記一次 .NET 某汽車控制焊接軟件 卡死分析