記一次 .NET某爐膛鍋爐檢測系統 崩潰分析

2024-04-18碼農

一：背景

1. 講故事

上個月有個朋友在微信上找到我，說他們的軟體在客戶那邊隔幾天就要崩潰一次，一直都沒有找到原因，讓我幫忙看下怎麽回事，確實工控類的軟體環境復雜難搞，朋友手上有一個崩潰的dump，剛好丟給我來分析一下。

二：WinDbg分析

1. 程式為什麽會崩潰

windbg 有一個厲害之處在於雙擊之後可以幫你自動定位到崩潰處，輸出如下：

................................................................ ................................................................ ....................................................... This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (1418.89c): Access violation - code c0000005 (first/second chance not available) For analysis of this file, run !analyze -v clr!WKS::gc_heap::background_mark_simple1+0x5a1: 000007fe`f5316d40 41f70300000080 test dword ptr [r11],80000000h ds:00000000`00000000=????????

從卦中資訊看，這不是一件好事情，崩潰居然落在bgc執行緒上，此時bgc執行緒正在做後台物件標記，依據過往經驗有可能是托管堆損壞了，可以用 !verifyheap 命令來驗證下。

0:038> !verifyheap Object 000000000476a0a8 has an invalid method table. Last good object: 000000000476A058. 0:038> !lno 000000000476a0a8 Before: 000000000476a058 80 (0x50) System.Text.RegularExpressions.RegexWriter After: 000000000476a0c0 152 (0x98) System.Int32[] 0:038> dp 000000000476a058 00000000`0476a058 000007fe`f0e47390 00000000`0476a0c0 00000000`0476a068 00000000`0476a1d0 00000000`0476a158 00000000`0476a078 00000000`0476a1a8 00000000`00000000 00000000`0476a088 0000001a`0000000000000006`0000001a 00000000`0476a098 00000000`0000000000000000`00000018 00000000`0476a0a8 00000000`0000000000000000`00000000 00000000`0476a0b8 00000000`00000000000007fe`f2ce9250 00000000`0476a0c8 00000000`0000002000000004`00000000

從卦中看確實有一個物件處於失真狀態，它的 mt=0 ,objheader=0x18 ，這個資訊還是蠻奇怪的，接下來觀察下記憶體地址的布局，找出失真地址空間，截圖如下：

上面圈出來的地址段也不像是 C++ 故意改的，那到底是真破壞還是假破壞呢？因為這一點確實可以決定後續的分析方向。

2. 托管堆真假破壞之謎

熟悉 bgc 運轉邏輯的朋友都知道會有三個階段，分別為 初始標記 , 並行標記 , 最終標記 ，所以接下來的問題是當前這個程式處於什麽階段呢? 這個觀察手段比較多，除了看bgc流程也可以 !t -special 看看 SuspendEE 標記。

0:038> !t -special ThreadCount: 40 ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 2412174c 000000001e71c210 1029220 Cooperative 0000000000000000:0000000000000000000000000027ba40 2 MTA (GC) (Threadpool Worker) ... 381389c 000000001e52913021220 Preemptive 0000000000000000:0000000000000000000000000027ba40 0 Ukn System.ExecutionEngineException 00000000022f1228 OSID Special thread type 24174c SuspendEE ThreadpoolWorker

從卦中可以清晰的看到24號執行緒觸發了一個 前台GC ，同時38號的 bgc拋了 執行引擎異常 ，這個災難性的異常也是程式崩潰的原因，接下來觀察下 24號正在做什麽。

0:024> k 10 # Child-SP RetAddr Call Site 0000000000`205ebcf0 000007fe`f52fb444 clr!GcInfoDecoder::EnumerateLiveSlots+0x4df 0100000000`205ec140 000007fe`f52fbd81 clr!EECodeManager::EnumGcRefs+0xc4 0200000000`205ec2a0 000007fe`f5380aee clr!GcStackCrawlCallBack+0x171 0300000000`205ec3a0 000007fe`f52fbc28 clr!Thread::StackWalkFrames+0x172 0400000000`205ed820 000007fe`f53141f0 clr!CNameSpace::GcScanRoots+0x144 0500000000`205ed8c0 000007fe`f5310a8e clr!WKS::gc_heap::relocate_phase+0x40 0600000000`205ed930 000007fe`f5310fd0 clr!WKS::gc_heap::plan_phase+0xa01 0700000000`205edb90 000007fe`f530df61 clr!WKS::gc_heap::gc1+0x9f 0800000000`205edbe0 000007fe`f530dccd clr!WKS::gc_heap::garbage_collect+0x222 0900000000`205edc70 000007fe`f530e220 clr!WKS::GCHeap::GarbageCollectGeneration+0xdd 0a 00000000`205edcc0 000007fe`f516ae69 clr!WKS::GCHeap::Alloc+0x29d 0b00000000`205edd10 000007fe`f2b2ab2a clr!FramedAllocateString+0x139 ...

從卦中可以清晰的看到此時的GC正在 relocate_phase 重定位階段，重定位階段通俗來說就是 兵馬未動，糧草先行 ，這是一種非原子性的操作，簡單來說bgc拿到的可能是移動後的新地址（糧草），但物件（兵馬）還是在老地方，所以剛才看到的托管堆那塊空間是初始化狀態，同時物件頭的 0x18 應該是一種中間狀態的物件標記，這個暫時不去深挖了，但不管怎麽說，此時的托管堆大機率是沒有問題的。

既然托管堆沒有問題，後面的研究方向就得深挖 bgc 的邏輯了。

3. bgc執行緒到底怎麽了

要知道 bgc 到底怎麽了，必須要觀察它附近的組譯程式碼，可以用 ub 命令，輸出如下：

0:024> r Last set context: rax=000000000001b83b rbx=0000000020e5e5b0 rcx=0000000000370707 rdx=00000000029b78a0 rsi=0000000000000000 rdi=0000000020e5e0c0 rip=000007fef5316d40 rsp=0000000020e5e680 rbp=000000001a30a2fc r8=0000000003707670 r9=000007fef2c94438 r10=00000000029b88b0 r11=0000000000000000 r12=0000000000000010 r13=000007fef2c94438 r14=0000000000291808 r15=0000000000001f60 iopl=0 nv up ei pl zr na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010244 clr!WKS::gc_heap::background_mark_simple1+0x5a1: 000007fe`f5316d40 41f70300000080 test dword ptr [r11],80000000h ds:00000000`00000000=???????? 0:024> ub 000007fe`f5316d40 clr!WKS::gc_heap::background_mark_simple1+0x584: 000007fe`f5316d23 48c1e809 shr rax,9 000007fe`f5316d27 80e11f and cl,1Fh 000007fe`f5316d2a 41d3e3 shl r11d,cl 000007fe`f5316d2d 44855c8500 test dword ptr [rbp+rax*4],r11d 000007fe`f5316d32 7548 jne clr!WKS::gc_heap::background_mark_simple1+0x5f3 (000007fe`f5316d7c) 000007fe`f5316d34 44095c8500 or dword ptr [rbp+rax*4],r11d 000007fe`f5316d39 4d8b18 mov r11,qword ptr [r8] 000007fe`f5316d3c 4983e3fe and r11,0FFFFFFFFFFFFFFFEh

從卦中數據來看，崩潰的原因是 r11=0 導致的，r11 的值又來自於 r8，這裏有一個寫死值 0FFFFFFFFFFFFFFFEh ，這個值在程式碼中應該是 -2 或者是 ~1 這兩種情況，接下來觀察下 background_mark_simple1() 的方法源碼，尼瑪。。。還真給我找到了，簡化後如下：

voidgc_heap::background_mark_simple1(uint8_t * oo THREAD_NUMBER_DCL) { ... uint8_t* start = oo; if ((size_t)oo & 1) { oo = (uint8_t*)((size_t)oo & ~1); start = *(--background_mark_stack_tos); dprintf(4, ("oo: %Ix, start: %Ix\n", (size_t)oo, (size_t)start)); } ... }

先簡單解釋下程式碼的意思， oo & ~1 是將 oo 物件的 gcmark標記 給去掉，後面的 background_mark_stack_tos 就是深度優先遍歷過程中使用的棧結構，再結合組譯程式碼，我們知道 r8 其實就是 oo，那這個 oo 到底是獨立存在還是歸屬於誰呢？

4. oo 到底是何方神聖

要想知道這個答案，可以用 !lno 命令觀察下 r8 附近記憶體來尋找蛛絲馬跡，輸出如下：

0:024> r r8 Last set context: r8=0000000003707670 0:024> !lno 0000000003707670 Before: 000000000370765880 (0x50) xxx.ComponentData After: 00000000037076a8 1416 (0x588) Free Heap local consistency confirmed. 0:024> ? 0000000003707670 - 0000000003707658 Evaluate expression: 24 = 00000000`00000018 0:024> !DumpObj /d 0000000003707658 Name: xxx.ComponentData MethodTable: 000007fe95c0b058 EE class: 000007fe95c2bbb0 Size: 80(0x50) bytes File: C:\xxxDriver.dll Fields: MT Field Offset Type VT Attr Value Name 000007fef2cecf58 400008c 38 System.DateTime 1 instance 0000000003707690 wWfscFiguq 000007fef2cffc90 400008d 18 System.Double 1 instance 0.000000 I9ss25rNyt 000007fe95c0a888 400008e 20 System.Int32 1 instance 9 AxCs5sGCxm 000007fe95c0af00 400008f24 System.Int32 1 instance 9 fK9sgqZ2qY ...

這個卦看起來就非常奇怪，無語了。。。我苦苦尋找的 oo 物件居然是一個 int 型別的 fK9sgqZ2qY 欄位，這不是亂套了嗎？int 型別在這裏也沒有裝箱，怎麽可能會提取出 mt 呢？真的是莫名奇怪。

5. int 為什麽當參照型別了

線索到了這裏越來越不可思議了，基本就可以斷定這是 BGC 標記的錯亂，直白的說就是 BGC 出現了 bug，再看下當前的作業系統和framework的版本,依次是 windows7 和 4.0 。

0:024> vertarget Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64 Product: WinNt, suite: SingleUserTS Edition build lab: kernel32.dll version: 6.1.7601.17514 (win7sp1_rtm.101119-1850) 0:024> !eeversion 4.0.30319.18408 free Workstation mode In plan phase of garbage collection SOS Version: 4.0.30319.18408 retail build