一:背景 1. 講故事 前些天有位朋友在微信上丟了一個崩潰的dump給我,讓我幫忙看下為什麼出現了崩潰,在 Windows 的事件查看器上顯示的是經典的 訪問違例 ,即 c0000005 錯誤碼,不管怎麼說有dump就可以上windbg開幹了。 二:WinDbg 分析 1. 程式為誰崩潰了 在 Wi ...
一:背景
1. 講故事
前些天有位朋友在微信上丟了一個崩潰的dump給我,讓我幫忙看下為什麼出現了崩潰,在 Windows 的事件查看器上顯示的是經典的 訪問違例
,即 c0000005
錯誤碼,不管怎麼說有dump就可以上windbg開幹了。
二:WinDbg 分析
1. 程式為誰崩潰了
在 Windows 平臺上比較簡單,可以用 !analyze -v
命令查看,輸出結果如下:
0:120> !analyze -v
...
CONTEXT: (.ecxr)
rax=0000000000000000 rbx=000000d5140fcf00 rcx=0000000000000000
rdx=000001d7f61cf1d8 rsi=000001d7d3635a10 rdi=000000d5140fc890
rip=00007ff80e17d233 rsp=000000d5140fc760 rbp=000000d5140fc8a0
r8=000001d7d3308144 r9=0000000000000000 r10=0000000000000000
r11=000001d96736b620 r12=000000d5140fca08 r13=00007ff80d326528
r14=000000d5140fcf00 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
00007ff8`0e17d233 3909 cmp dword ptr [rcx],ecx ds:00000000`00000000=????????
Resetting default scope
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ff80e17d233
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000
ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p 0x%p %s
EXCEPTION_CODE_STR: c0000005
STACK_TEXT:
000000d5`140fc760 00007ff8`6bcc6d93 : 000001d7`d3635a10 000000d5`140fcb80 00007ff8`6bcfda57 00007ff8`695acc92 : 0x00007ff8`0e17d233
000000d5`140fc8b0 00007ff8`6bcc6c48 : 00000000`00000004 00007ff8`6be5ba73 00000000`00000000 00000000`00000000 : clr!CallDescrWorkerInternal+0x83
000000d5`140fc8f0 00007ff8`6be5bf66 : 000001d7`d3635a10 00000000`00000000 000000d5`140fcad8 00000000`00000000 : clr!CallDescrWorkerWithHandler+0x4e
000000d5`140fc930 00007ff8`6be5c41f : 00000000`00000000 000000d5`140fca30 00000000`00000000 000000d5`140fcb60 : clr!CallDescrWorkerReflectionWrapper+0x1a
000000d5`140fc980 00007ff8`69993ee4 : 00000000`00000000 00000000`00000000 000001d7`d3635a10 00007ff8`699f9700 : clr!RuntimeMethodHandle::InvokeMethod+0x45f
000000d5`140fcf90 00007ff8`6997eeae : 000001d7`d3376af0 00000000`00000000 00000000`0000011e 00007ff8`699f82f3 : mscorlib_ni!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal+0x104
000000d5`140fd000 00007ff8`699c3a06 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : mscorlib_ni!System.Reflection.RuntimeMethodInfo.Invoke+0x8e
000000d5`140fd080 00007ff8`0dfb7bb3 : 000001d7`d3635998 000001d7`d45e28e0 00000000`0000011c 000001d7`d3376af0 : mscorlib_ni!System.RuntimeType.InvokeMember+0x306
...
STACK_COMMAND: ~120s; .ecxr ; kb
...
從卦中信息看崩潰的彙編語句是 dword ptr [rcx],ecx
,經常看C#彙編代碼的朋友我相信對這條語句非常敏感,對,它就是JIT自動插入的一條 this!=null
的防禦性判斷,看樣子程式有 this=null 的情況,接下來入手點就是RIP處 ExceptionAddress: 00007ff80e17d233
,用 !U 觀察下上下文。
0:120> !U 00007ff80e17d233
Normal JIT generated code
MyScript.Process()
Begin 00007ff80e17d1c0, size 3d5
00007ff8`0e17d1c0 55 push rbp
00007ff8`0e17d1c1 57 push rdi
00007ff8`0e17d1c2 56 push rsi
00007ff8`0e17d1c3 4881ec30010000 sub rsp,130h
00007ff8`0e17d1ca c5f877 vzeroupper
...
00007ff8`0e17d220 e813c1edfe call 00007ff8`0d059338 (xxx.GetRegion(System.String, Boolean), mdToken: 000000000600034f)
00007ff8`0e17d225 48898570ffffff mov qword ptr [rbp-90h],rax
00007ff8`0e17d22c 488b8d70ffffff mov rcx,qword ptr [rbp-90h]
>>> 00007ff8`0e17d233 3909 cmp dword ptr [rcx],ecx
00007ff8`0e17d235 e8de87edfe call 00007ff8`0d055a18 (xxx.get_Region(), mdToken: 0000000006000073)
從卦中的彙編代碼看邏輯非常清晰,即 xxx.GetRegion()
方法返回為null,然後在取其中的 Region 屬性時直接崩掉,說白了這是一個簡單的 空引用異常
,完整的代碼截圖如下:
奇怪就奇怪在這裡,代碼中明明用 try catch 給包起來了,為什麼程式直接崩掉了。
2. 為什麼try catch 無效
尼瑪,這是我這幾年做dump分析第一次遇到這種情況,真的是無語了,接下來我們驗證下這個異常是否到了托管層?
- 是否有 NullReferenceException
熟悉dump分析的朋友應該知道,如果線程拋了異常在回溯的過程中會記錄到 Thread.m_LastThrownObjectHandle
欄位中,同時 !t 命令可以在 Exception 列中看到此信息。
0:120> !t
ThreadCount: 48
UnstartedThread: 0
BackgroundThread: 47
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 29dc 000001d7d162d5d0 26020 Preemptive 000001D7D8228A00:000001D7D8228D28 000001d7d1602380 0 STA
...
159 18 22dc 000001d967906ff0 1029220 Preemptive 000001D7D834E558:000001D7D834E558 000001d7d1602380 1 MTA (GC) (Threadpool Worker)
...
但從卦中數據看所有的 Exception 列都沒有異常信息,這就表示程式沒有走到 CLR 的異常處理鏈條上,至少是不完整的。
- 是否有 AccessViolationException
參加過 C#內功修煉訓練營
的朋友應該都知道,這種 c0000005
的異常在 C#層面最終會被map成兩種異常中的其一,即 NullReferenceException 和 AccessViolationException,選擇其一的邏輯就是判斷 RIP 是在托管層還是非托管層,模型圖如下:
但遺憾的是在 !t
的列表中也沒有任何的 AccessViolationException 字樣,這也更加確認了它沒有調用異常處理鏈中的 CreateThrowable 函數。。。
事出反常必有妖,在 !t 的輸出結果中可以看到此時 159號線程觸發了 GC,接下來切過去看一看。
0:120> ~159s
ntdll!NtQueryInformationThread+0x14:
00007ff8`8317ea34 c3 ret
0:159> k
# Child-SP RetAddr Call Site
00 000000d5`00c3e7d8 00007ff8`7f216e2e ntdll!NtQueryInformationThread+0x14
01 000000d5`00c3e7e0 00007ff8`6bcea731 KERNELBASE!GetThreadPriority+0x1e
02 000000d5`00c3e850 00007ff8`6be69cc5 clr!Thread::GetThreadPriority+0x56
03 000000d5`00c3e8a0 00007ff8`6be69bc4 clr!ThreadSuspend::SuspendRuntime+0xa5
04 000000d5`00c3e990 00007ff8`6bd814e3 clr!ThreadSuspend::SuspendEE+0x128
05 000000d5`00c3ea90 00007ff8`6bd85f51 clr!WKS::GCHeap::GarbageCollectGeneration+0xb7
06 000000d5`00c3eaf0 00007ff8`6be7ee6b clr!WKS::gc_heap::trigger_gc_for_alloc+0x2d
07 000000d5`00c3eb30 00007ff8`470e53ec clr!JIT_New+0x4d6
08 000000d5`00c3eee0 00007ff8`470e537c Microsoft_VisualBasic_ni!Microsoft.VisualBasic.Strings.ReplaceInternal+0x3c [f:\dd\vb\runtime\msvbalib\Strings.vb @ 761]
09 000000d5`00c3ef80 00007ff8`0d04f81f Microsoft_VisualBasic_ni!Microsoft.VisualBasic.Strings.Replace+0x15c [f:\dd\vb\runtime\msvbalib\Strings.vb @ 737]
...
從卦中的線程棧來看,此時正在 SuspendEE 階段,而且還是處於早期階段,正在準備給 SuspendThread 安排一個好的優先順序,主要是怕優先順序太低了,導致 線程饑餓 得不到調度,畢竟 GC Process 的過程一定要是快中再快,接下來我們看下程式的 framework 版本。
0:159> !eeversion
4.7.3190.0 free
Workstation mode
SOS Version: 4.7.3190.0 retail build
可以看到還是比較老的 .netframework 4.7.3
,結合這麼多信息,我個人覺得這可能是 CLR 的一個 bug,在 SuspendEE 階段的早期(還沒有 foreach threads)剛好遇到了一個硬體異常
,這個 硬體異常
CLR 在業務邏輯上沒處理好,導致 SEH 異常沒有引入到 托管層,或者中途的某一環斷掉了,我放一張C#內功修煉訓練營
中的硬體異常完整流程圖。
最後給到朋友的建議比較簡單:
- 判 null 的時候一定要加 null 判斷,避免異常邏輯。
- 升級 framework 到最新的 4.8.1 觀察。
三:總結
這次程式崩潰的原因很簡單,就是 空引用異常 ,但詭異就詭異在明明有 trycatch 在外部,硬是沒接住,這個大概率是 CLR 的 bug,讓我這個分析多年dump的老手都嘆為觀止,開了眼界,無語了無語了。。。