一：背景
1. 講故事
昨晚給訓練營裏面的一位朋友分析了一個程序崩潰的故障，因爲看小夥子昨天在羣裏問了一天也沒搞定，乾脆自己親自上陣吧，抓取的dump也是我極力推薦的用 procdump 註冊 AEDebug 的方式，省去了很多溝通成本。
二：WinDbg分析
1. 爲什麼會崩潰
windbg有一個非常強大的點就是當你雙擊打開後，會自動幫你切換到崩潰的線程以及崩潰處的彙編代碼，省去了 !analyze -v 命令的龜速輸出，參考信息如下：
................................................................
...................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(10f4.f58): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
eax=00000000 ebx=00000000 ecx=00000040 edx=00000000 esi=004c1b98 edi=07a8ed4c
eip=7008508f esp=07a8ec74 ebp=07a8ec80 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
clr!Thread::GetSafelyRedirectableThreadContext+0x7c:
7008508f 8038eb cmp byte ptr [eax],0EBh ds:002b:00000000=??
...
從卦中可以看到，當前崩潰是因爲 eax=0 導致的，那爲什麼 eax 等於 0 呢？要想尋找這個答案，需要觀察崩潰前的線程棧上下文，可以使用命令 .ecxr;k 9 即可。
0:009> .ecxr;k 9
eax=00000000 ebx=00000000 ecx=00000040 edx=00000000 esi=004c1b98 edi=07a8ed4c
eip=7008508f esp=07a8ec74 ebp=07a8ec80 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
clr!Thread::GetSafelyRedirectableThreadContext+0x7c:
7008508f 8038eb cmp byte ptr [eax],0EBh ds:002b:00000000=??
# ChildEBP RetAddr
00 07a8ec80 6fe7f6cd clr!Thread::GetSafelyRedirectableThreadContext+0x7c
01 07a8f030 6fe7f2f3 clr!Thread::HandledJITCase+0x31
02 07a8f0a4 6fee23da clr!Thread::SuspendRuntime+0x260
03 07a8f184 6fedf72d clr!WKS::GCHeap::SuspendEE+0x1fe
04 07a8f1b0 6fe309ca clr!WKS::GCHeap::GarbageCollectGeneration+0x168
05 07a8f1c0 6fe30a2e clr!WKS::GCHeap::GarbageCollectTry+0x56
06 07a8f1e4 6fe30a90 clr!WKS::GCHeap::GarbageCollect+0xa5
07 07a8f230 6f058b01 clr!GCInterface::Collect+0x5d
08 07a8f26c 055fa4b1 mscorlib_ni+0x3b8b01
從卦中信息看，尼瑪，真無語了 GCInterface::Collect 說明有人用 GC.Collect() 手工觸發GC，不知道爲什麼要這麼做來污染GC內部的統計信息，不管怎麼說這個肯定不是崩潰的原因。
2. GC正在幹什麼
我們繼續觀察線程棧，可以看到它的邏輯大概是這樣的，通過 SuspendRuntime 把所有的託管線程進行邏輯上暫停，在暫停其中的一個線程時拋出了異常。
稍微提醒一下，這個 HandledJITCase 方法是用 ip 劫持技術將代碼引入到 coreclr 中進行 GC完成等待，這種神操作有些殺毒軟件會認爲是病毒！！！
有些朋友肯定會說，有沒有代碼支撐。。。這裏我就找一下 coreclr 的源碼貼一下吧。
void ThreadSuspend::SuspendRuntime(ThreadSuspend::SUSPEND_REASON reason)
{
while ((thread = ThreadStore::GetThreadList(thread)) != NULL)
{
...
if (workingOnThreadContext.Acquired() && thread->HandledJITCase())
{
...
}
...
}
}
結合源碼分析思路就非常清晰了，這裏的 thread->HandledJITCase() 中的 thread 到底是哪一個線程？ 可以觀察 kb 輸出然後用 !t 去做比對。
從卦中看，當前 GC 正在 Suspend 主線程，並且還看到了主線程有一個 System.AccessViolationException 異常，無語了。。。
3. 主線程到底怎麼了
主線程進入到視野之後，那就重點關注一下它，可以用 k 看一下輸出。
0:009> ~0s
eax=00000000 ebx=0029ea50 ecx=0029ea90 edx=00000000 esi=7efdb800 edi=000d0000
eip=00000000 esp=0029ea4c ebp=75146381 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210202
00000000 ?? ???
0:000> k
00 75146381 7efdb800 0x0
01 75146381 7517fa04 0x7efdb800
02 0029ea80 7736013a user32!__fnHkINLPKBDLLHOOKSTRUCT+0x28
03 0029eae4 7514908d ntdll!KiUserCallbackDispatcher+0x2e
04 0029eae4 076e3912 user32!CallNextHookEx+0x84
05 0029eb28 076e3064 0x76e3912
06 0029eb5c 0011d48f xxx!xxx.ScanerHook.KeyboardHookProc+0xe4
07 0029eb8c 75146381 0x11d48f
08 0029eba8 7517fa04 user32!DispatchHookW+0x38
09 0029ebd8 7736013a user32!__fnHkINLPKBDLLHOOKSTRUCT+0x28
0a 0029ec3c 751406eb ntdll!KiUserCallbackDispatcher+0x2e
0b 0029ec3c 75140751 user32!_PeekMessage+0x88
0c 0029ec68 6d8af3bf user32!PeekMessageW+0x108
...
從卦象看，這卦非常奇怪，有如下兩點信息：
- eip=00000000，這個很無語，線程已經瘋了
- KeyboardHookProc ，居然有鍵盤鉤子
熟悉 eip 的朋友應該知道，它相當於一輛車的方向盤，一輛高速行駛的車突然沒了方向盤，真的太可怕了，最後必然車毀人亡。
4. 是 eip=0 導致的崩潰嗎
在彙編中是因爲eax=0導致，而這裏eip恰好也等於0，彷彿冥冥之中自有牽連，帶着強烈的好奇心我們來反彙編下 GetSafelyRedirectableThreadContext 方法邏輯，簡化後如下：
0:000> uf 7008508f
clr!Thread::GetSafelyRedirectableThreadContext:
6fe7f60e 55 push ebp
6fe7f60f 8bec mov ebp,esp
6fe7f611 53 push ebx
6fe7f612 56 push esi
6fe7f613 57 push edi
6fe7f614 8bf1 mov esi,ecx
...
7008506d ffe9 jmp rcx
7008506f fd std
70085070 c1daff rcr edx,0FFh
70085073 f6450801 test byte ptr [ebp+8],1
70085077 0f84efa5dfff je clr!Thread::GetSafelyRedirectableThreadContext+0xcc (6fe7f66c)
7008507d 8b8604010000 mov eax,dword ptr [esi+104h]
70085083 3987b8000000 cmp dword ptr [edi+0B8h],eax
70085089 0f85dda5dfff jne clr!Thread::GetSafelyRedirectableThreadContext+0xcc (6fe7f66c)
7008508f 8038eb cmp byte ptr [eax],0EBh
從上面的彙編代碼看eax的取值鏈條是: eax <- esi+104h <- ecx ，很顯然這裏的 ecx 是 thiscall 協議中的 Thread=004c1b98 參數，可以用 dp 驗證下。
0:000> dp 004c1b98+0x104 L1
004c1c9c 00000000
從卦中看果然是 0，有些朋友好奇這個 104 偏移到底是個什麼東西，參考 coreclr 源碼其實就是 m_LastRedirectIP 字段，參考如下：
BOOL Thread::GetSafelyRedirectableThreadContext(DWORD dwOptions, CONTEXT* pCtx, REGDISPLAY* pRD)
{
if (!EEGetThreadContext(this, pCtx))
{
return FALSE;
}
...
if (GetIP(pCtx) == m_LastRedirectIP)
{
const BYTE short_jmp = 0xeb;
const BYTE self = 0xfe;
BYTE* ip = (BYTE*)m_LastRedirectIP;
if (ip[0] == short_jmp && ip[1] == self)
m_LastRedirectIP = 0;
return FALSE;
}
}
結合彙編代碼其實我們崩潰在 ip[0] == short_jmp 這一句上，仔細分析上面的C++代碼會發現一個很奇怪的信息，那就是爲什麼 GetIP(pCtx)= 0，接下來用 dt 觀察下寄存器上下文。
0:009> kb 2
# ChildEBP RetAddr Args to Child
00 07a8ec80 6fe7f6cd 00000003 07a8ed4c 07a8ecf0 clr!Thread::GetSafelyRedirectableThreadContext+0x7c
01 07a8f030 6fe7f2f3 004c1b98 0b367326 76a016a1 clr!Thread::HandledJITCase+0x31
0:009> dt _CONTEXT 07a8ed4c
ntdll!_CONTEXT
+0x000 ContextFlags : 0x10007
...
+0x01c FloatSave : _FLOATING_SAVE_AREA
+0x08c SegGs : 0x2b
+0x090 SegFs : 0x53
+0x094 SegEs : 0x2b
+0x098 SegDs : 0x2b
+0x09c Edi : 0xd0000
+0x0a0 Esi : 0x7efdb800
+0x0a4 Ebx : 0x29ea50
+0x0a8 Edx : 0
+0x0ac Ecx : 0x29ea90
+0x0b0 Eax : 0
+0x0b4 Ebp : 0x75146381
+0x0b8 Eip : 0
+0x0bc SegCs : 0x23
+0x0c0 EFlags : 0x210202
+0x0c4 Esp : 0x29ea4c
...
從卦中看果然 eip=0，這是一個非常錯誤的信息，還有一點就是 m_LastRedirectIP 字段一般用來處理一些比較詭異的兼容性問題，所以這裏兩個字段都是 0 導致崩潰的產生。
有了上面的信息，我們就知道了前因後果，原來是主線程車毀人亡(eip=0)，導致GC無法暫停它，在內部拋出了代碼異常，你可以說是 CLR 的bug，也可以說是主線程的Bug，所以給到的解決方案就是：
- 屏蔽掉
鍵盤鉤子的業務邏輯，肯定是它造成的。 - 不去掉的話，要重點觀察
鍵盤盤子，是否是代碼改動引發的。
三：總結
說實話要想解釋這個程序爲什麼會崩潰，需要分析者對GC的SuspendRuntime運作邏輯有一定的瞭解，否則真抓瞎了，所以.NET調試訓練營中的GC理論知識一定是分析這些 dump 的基石。
