記一次 .NET某上位視覺程序離奇崩潰分析
一、背景
1. 講故事
前段時間有位朋友找到我，說他們有一個崩潰的dump讓我幫忙看下怎么回事。
話不多說，既然有 dump 來了，那就上 windbg 說話吧。
二：WinDbg 分析
1. 為什么會崩潰
說實話windbg非常強大，雙擊打開dump就能第一時間幫你顯示出簡略的異常信息，輸出如下：
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(bf8.5dc4): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
clr!WKS::gc_heap::mark_object_simple1+0x220:
00007ffb`380453c4 833a00 cmp dword ptr [rdx],0 ds:00007ffa`35451300=????????從卦中又看到了經典的 mark_object_simple1 方法，這個方法是GC用來做對象標記之用的，所以大概率又是托管堆損壞，真是無語了，接下來用 !verifyheap 檢查下托管堆。
0:083> !verifyheap
object 00000218e96963d8: bad member 00000218E9696450 at 00000218E9696420
Last good object: 00000218E96963C0.
Could not request method table data for object 00000218E9696450 (MethodTable: 00007FFA35451300).
Last good object: 00000218E96963D8.一看這卦就很不吉利，真的是有對象的mt是不對的，至此我們把崩潰的直接原因給找到了。
2. 為什么對象損壞了
要找到這個答案就需要深挖 00000218e96963d8 對象，分別使用 !do 命令以及 dp 來觀察內存地址。
0:083> !do 00000218e96963d8
Name: System.Threading.Tasks.Task+DelayPromise
MethodTable: 00007ffb3542b3e8
EEClass: 00007ffb3567c7c0
Size: 120(0x78) bytes
File: C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
...
00007ffb35451300 40035d5 48 ...m.Threading.Timer 0 instance 00000218e9696450 Timer
0:083> dp 00000218e9696450 L6
00000218`e9696450 00007ffa`35451301 00000000`00000000
00000218`e9696460 00000218`e96964c8 00000000`00000000
00000218`e9696470 00007ffb`353e4b51 00000218`e9696368仔細觀察卦中對象 00000218e9696450 所顯示的mt，你會發現一個是 00007ffb35451300，一個是 00007ffa35451301，很顯然前者是對的，后者是錯的，可以分別用 !dumpmt 做個驗證。
0:083> !dumpmt 00007ffb35451300
EEClass: 00007ffb356942f0
Module: 00007ffb353b1000
Name: System.Threading.Timer
mdToken: 0000000002000504
File: C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
BaseSize: 0x20
ComponentSize: 0x0
Slots in VTable: 23
Number of IFaces in IFaceMap: 1
0:083> !dumpmt 00007ffa35451301
00007ffa35451301 is not a MethodTable細心的朋友會發現雖然兩個mt地址不一樣，但已經非常相近，看樣子又是一例經典的bit位翻轉，我去，用 .formats 轉成二進制觀察一下，截圖如下：
圖片
從卦中可以清晰的看到當前地址有兩個 bit 的翻轉，分別是第0位和第32位，接下來就要洞察為什么會有兩個bit位的翻轉？
3. 真的存在兩個bit位翻轉嗎
接下來我們逐一來聊一下。
- bit 0 為什么會翻轉
熟悉 coreclr 底層的朋友應該知道，gc 在標記的過程中會給 mt 的第0位設置為1，表示當前對象在深度優先中已經標記過，防止重復標記，當然這個也是有源碼作證的,簡化后的代碼如下：
inline BOOL gc_heap::gc_mark(uint8_t* o, uint8_t* low, uint8_t* high, int condemned_gen)
{
if ((o >= low) && (o < high))
{
BOOL already_marked = marked(o);
if (already_marked)
{
return FALSE;
}
set_marked(o);
return TRUE;
}
}
#define marked(i) header(i)->IsMarked()
BOOL IsMarked() const
{
return !!(((size_t)RawGetMethodTable()) & GC_MARKED);
}有了這段源碼，這個 bit 為什么為 1 就能輕松的解釋了，所以這個翻轉是一個正常情況。
- bit 32 為什么會翻轉
這個是我無法解釋的，也正是因為這個 bit32 的翻轉導致 gc 認為這個 obj 是一個損壞的對象，到底是什么原因呢？民間眾說紛紜，在我的過往分析旅程中我已見過兩例，但我不敢確定自己又遇到了輻射類的奇葩情況，所以也第一時間找朋友確認程序周邊是否存在輻射環境。
圖片
朋友反饋過來附近有 伺服電機 類，說實話工控的東西我是真的不太懂，只能上網搜搜這玩意是否有輻射，截圖如下：
圖片
到底是不是這玩意導致的，其實我心里也沒底，跟朋友的溝通后說是只出現過一次，這就更加玄乎了。
圖片
不管怎么說，我只能給出如下兩個方案：
- 上 ECC 糾錯內存
- 遠離輻射環境
三：總結
在大工控領域里，這是我見過第三例bit位翻轉導致的程序崩潰，太無語了，惡魔到底是不是旁邊的 伺服電機 ?
