一：背景
1. 講故事
前些天有一位朋友在公衆號上找到我，說他們的WinForm程序部署在20多臺機器上，只有兩臺機器上的程序會出現崩潰的情況，自己找了好久也沒分析出來，讓我幫忙看下怎麼回事，就喜歡這些有點調試基礎的，dump也不需要我指導怎麼去抓，接下來我們就上windbg開始分析吧。
二：WinDbg分析
1. 爲什麼會崩潰
尋找崩潰的表象比較簡單，使用 windbg 的 !analyze -v 命令即可。
0:000> !analyze -v
...
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
...
STACK_TEXT:
0000003f`76f7ed58 00007ffa`f7c66d88 : 0000003f`00006120 00007ffa`f7bf98da 00000000`00000000 0000e4f5`bb3ba231 : user32!NtUserWaitMessage+0xa
0000003f`76f7ed60 00007ffa`f7bf9517 : 0000003f`00006120 0000003f`76f7ee80 00000000`00000000 00000000`00000000 : System_Windows_Forms_ni+0x2b6d88
0000003f`76f7ee10 00007ffa`f7bf8c2c : 0000003f`0006ec30 0000003f`00000001 0000003f`000c88c0 00000000`00000000 : System_Windows_Forms_ni+0x249517
0000003f`76f7ef10 00007ffa`f7bf8a25 : 0000003f`00006120 00000000`ffffffff 0000003f`00054848 0000003f`76f7f300 : System_Windows_Forms_ni+0x248c2c
0000003f`76f7efa0 00007ffa`9b4a0a08 : 0000003f`00007970 00000000`ffffffff 0000003f`000c88c0 0000003f`770bda90 : System_Windows_Forms_ni+0x248a25
0000003f`76f7f000 00007ffa`fab13753 : 00000000`00000001 0000003f`76f7f530 00007ffa`fac6710d 00000000`00000001 : 0x00007ffa`9b4a0a08
0000003f`76f7f040 00007ffa`fab1361c : 0000003f`00003330 00007ffa`f9acd94c 00000000`20000001 0000003f`00000000 : clr!CallDescrWorkerInternal+0x83
0000003f`76f7f080 00007ffa`fab144d3 : 00000000`00000000 00000000`00000004 0000003f`76f7f300 0000003f`76f7f3b8 : clr!CallDescrWorkerWithHandler+0x4e
0000003f`76f7f0c0 00007ffa`fac6f75a : 0000003f`76f7f200 00000000`00000000 00000000`00000000 00000000`00000000 : clr!MethodDescCallSite::CallTargetWorker+0x2af
0000003f`76f7f250 00007ffa`fac6f596 : 00000000`00000000 00000000`00000001 0000003f`00000000 00000000`00000000 : clr!RunMain+0x1ba
0000003f`76f7f430 00007ffa`fac6f4d4 : 0000003f`770bda90 0000003f`000015b0 0000003f`770bda90 0000003f`77093490 : clr!Assembly::ExecuteMainMethod+0xba
0000003f`76f7f720 00007ffa`fac6ea02 : 0000003f`76f7fd88 0000003f`76de0000 00000000`00000000 00000000`00000000 : clr!SystemDomain::ExecuteMainMethod+0x6b9
0000003f`76f7fd60 00007ffa`fac6e9b2 : 0000003f`76de0000 0000003f`76f7fee0 00000000`00000000 00007ffb`03c420e8 : clr!ExecuteEXE+0x43
0000003f`76f7fdd0 00007ffa`fac6e8f4 : ffffffff`ffffffff 00000000`00000000 00000000`00000000 00000000`00000000 : clr!_CorExeMainInternal+0xb2
0000003f`76f7fe60 00007ffb`03be6cf5 : 00000000`00000000 00000000`00000091 00000000`00000000 0000003f`76f7fe48 : clr!CorExeMain+0x14
0000003f`76f7fea0 00007ffb`03c8ea5b : 00000000`00000000 00007ffa`fac6e8e0 00000000`00000000 00000000`00000000 : mscoreei!CorExeMain+0xe0
0000003f`76f7fef0 00007ffb`0dc716ad : 00007ffb`03be0000 00000000`00000000 00000000`00000000 00000000`00000000 : mscoree!_CorExeMain_Exported+0xcb
0000003f`76f7ff20 00007ffb`0f924629 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
0000003f`76f7ff50 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
STACK_COMMAND: ~0s; .ecxr ; kb
...
從卦中看，真的吸了一口涼氣，尼瑪這dump沒記錄到 crash 信息，有些朋友說這個 int 3 不是嗎？簡單的說不是，它是一個軟trap，抓dump的時候會有一個進程的凍結，這個凍結就是 int 3，所以你看dump中有這個異常 99% 都是正常的。
2. 異常哪裏去了
按往常的套路，我都會推薦procdump這款工具讓朋友再抓一下，在重抓之前先看看可還有其他線索，可以用 !t 看看託管線程上是否掛了異常。
0:000> !t
ThreadCount: 76
UnstartedThread: 0
BackgroundThread: 69
PendingThread: 0
DeadThread: 6
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 26c4 0000003f770bda90 26020 Preemptive 0000000000000000:0000000000000000 0000003f77093490 0 STA
...
74 77 c544 0000003f1a08c470 21220 Preemptive 0000000000000000:0000000000000000 0000003f77093490 0 Ukn System.ExecutionEngineException 0000003f000011f8
75 78 18a88 0000003f1a329ae0 8029220 Preemptive 0000000000000000:0000000000000000 0000003f77093490 0 MTA (Threadpool Completion Port)
從卦中可以看到有一個線程拋了 System.ExecutionEngineException 異常，這是一個災難性的情況，表示 CLR 在執行自身代碼的時候崩掉了，驚訝之餘趕緊看看它的線程棧爲什麼會崩。
0:074> k
# Child-SP RetAddr Call Site
00 0000003f`1bafea90 00007ffa`fb0283aa clr!WKS::gc_heap::background_mark_simple+0x36
01 0000003f`1bafeac0 00007ffa`fb028701 clr!WKS::gc_heap::revisit_written_page+0x2fe
02 0000003f`1bafeb50 00007ffa`fb01ffec clr!WKS::gc_heap::revisit_written_pages+0x251
03 0000003f`1bafec10 00007ffa`facefd01 clr!WKS::gc_heap::background_mark_phase+0x298
04 0000003f`1bafeca0 00007ffa`fb021fe5 clr!WKS::gc_heap::gc1+0xc0
05 0000003f`1bafed10 00007ffa`fab33e1e clr!WKS::gc_heap::bgc_thread_function+0x169
06 0000003f`1bafed50 00007ffb`0dc716ad clr!Thread::intermediateThreadProc+0x7d
07 0000003f`1baff810 00007ffb`0f924629 kernel32!BaseThreadInitThunk+0xd
08 0000003f`1baff840 00000000`00000000 ntdll!RtlUserThreadStart+0x1d
0:074> r
rax=000000001f808000 rbx=0000003f1bafe870 rcx=0000003efac80140
rdx=0000003f01000000 rsi=0000000000000000 rdi=0000003f1bafe380
rip=00007ffafb020c06 rsp=0000003f1bafea90 rbp=0000003f01c63270
r8=0000000000000000 r9=0000003f01c64000 r10=0000003f04271000
r11=0000000000000001 r12=00007ffa9bca83c0 r13=0000003f01c632a8
r14=ffffffffffffffff r15=0000003f01c63000
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_simple+0x36:
00007ffa`fb020c06 41f70000000080 test dword ptr [r8],80000000h ds:00000000`00000000=????????
從卦中信息看，當前是一個 bgc 線程，在後臺標記對象的時候踩到了0區導致的崩潰，經驗告訴我，是不是此時的託管堆損壞了? 可以用 !verifyheap 驗證下。
0:000> !verifyheap
No heap corruption detected.
從卦中信息看，當前託管堆並沒有損壞，作爲一個經常爲sos輸出坑過的人，現在我是不相信這個輸出的，所以我要找一下這個 r8 對象到底是什麼對象，接下來反彙編下 background_mark_simple 方法。
0:074> ub 00007ffa`fb020c06
clr!WKS::gc_heap::background_mark_simple+0x1a:
00007ffa`fb020bea 0941d3 or dword ptr [rcx-2Dh],eax
00007ffa`fb020bed e048 loopne clr!WKS::gc_heap::background_mark_simple+0x67 (00007ffa`fb020c37)
00007ffa`fb020bef 8b0dd3253c00 mov ecx,dword ptr [clr!WKS::gc_heap::mark_array (00007ffa`fb3e31c8)]
00007ffa`fb020bf5 44850481 test dword ptr [rcx+rax*4],r8d
00007ffa`fb020bf9 7548 jne clr!WKS::gc_heap::background_mark_simple+0x73 (00007ffa`fb020c43)
00007ffa`fb020bfb 44090481 or dword ptr [rcx+rax*4],r8d
00007ffa`fb020bff 4c8b02 mov r8,qword ptr [rdx]
00007ffa`fb020c02 4983e0fe and r8,0FFFFFFFFFFFFFFFEh
0:074> r rdx
rdx=0000003f01000000
0:074> !lno rdx
Before: 0000003f00ffff38 512 (0x200) xxx.xxx
After: 0000003f01000138 32 (0x20) System.String
Heap local consistency confirmed.
0:074> ? 0000003f01000000 - 0000003f00ffff38
Evaluate expression: 200 = 00000000`000000c8
0:074> !do 0000003f00ffff38
Name: xxx.xxx
MethodTable: 00007ffa9c0ac278
EEClass: 00007ffa9c095b20
Size: 512(0x200) bytes
Fields:
MT Field Offset Type VT Attr Value Name
...
00007ffaf9d1da88 40012e6 c8 System.String 0 instance 0000000000000000 <OPPORTUNITY>k__BackingField
...
經過我上面的一頓分析，原來bgc標記的對象是 <OPPORTUNITY>k__BackingField 字段，同時也驗證了確實託管堆沒有損壞，接下來的問題是爲什麼BGC在mark這個字段的時候拋出來了異常呢？
3. 繼續尋找真相
找不到突破口那就只能從線程棧上去挖，熟悉 bgc 後臺標記的朋友應該知道，後臺標記會分成三個階段。
- 初始標記階段
- 併發標記階段
- 最終標記階段
截一張我在 .NET高級調試訓練營 PPT裏的圖。
接下來的問題是這個程序目前處於哪一個階段呢？根據線程棧上的 revisit_written_pages 方法，很顯然是處於第二階段，在第二階段中爲了能夠識別對象修改的情況，CLR 使用了 Win32 的GetWriteWatch函數對內存頁進行監控，監控到的髒內存頁會在第三階段做最後的清洗。
說了這麼多，有沒有源碼支撐呢？這裏我們簡單看一下 coreclr 的源代碼即可。
void gc_heap::revisit_written_pages(BOOL concurrent_p, BOOL reset_only_p)
{
get_write_watch_for_gc_heap(reset_watch_state, base_address, region_size,
(void**)background_written_addresses,
&bcount, is_runtime_suspended);
}
// static
void gc_heap::get_write_watch_for_gc_heap(bool reset, void * base_address, size_t region_size,
void * *dirty_pages, uintptr_t * dirty_page_count_ref,
bool is_runtime_suspended)
{
bool success = GCToOSInterface::GetWriteWatch(reset, base_address, region_size, dirty_pages,
dirty_page_count_ref);
}
bool GCToOSInterface::GetWriteWatch(bool resetState, void * address, size_t size, void * *pageAddresses, uintptr_t * pageAddressesCount)
{
uint32_t flags = resetState ? 1 : 0;
ULONG granularity;
bool success = ::GetWriteWatch(flags, address, size, pageAddresses, (ULONG_PTR*)pageAddressesCount, &granularity) == 0;
if (success)
{
assert(granularity == OS_PAGE_SIZE);
}
return success;
}
給了這麼多的代碼，主要是想說 bgc的併發標記利用了 Windows 提供的功能，結合朋友說的只有兩臺機器會出現這種情況，到這裏大概可以給出兩種方案：
-
更新Windows補丁，升級framework，大概率是兩者的兼容性問題，導致內存頁監控上出了問題。
-
修改配置文件禁用 bgc，這樣就不會走這些邏輯，從根子上繞過這個問題。
三：總結
說實話在我的dump分析旅程中，這個dump的分析難度還是比較大的，它考驗着你對bgc線程底層運作的理解，所幸的是我在調試訓練營裏用windbg讓大家親眼目睹了後臺標記三階段的詳細過程，真是三生有幸！
