一：背景 1. 講故事 前些天有位朋友找到我，說他們的程式崩潰了，也自己分析了下初步結果，讓我幫忙再確認下，既然讓我確認，那就開始dump分析之旅吧。 二：WinDbg 分析 1. 為什麼會崩潰 windbg 有一個強大之處就是帶有一個自動化的分析命令 !analyze -v 可以幫助我們快速的分析 ...
一：背景
1. 講故事
前些天有位朋友找到我，說他們的程式崩潰了，也自己分析了下初步結果，讓我幫忙再確認下，既然讓我確認，那就開始dump分析之旅吧。
二：WinDbg 分析
1. 為什麼會崩潰
windbg 有一個強大之處就是帶有一個自動化的分析命令 !analyze -v 可以幫助我們快速的分析，輸出如下：
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
CONTEXT: (.ecxr)
rax=00007ff95c5a9877 rbx=00007ff959d6d8e0 rcx=0000000000000000
rdx=0000000000000000 rsi=000000e394b98de0 rdi=000000e394b99530
rip=00007ff959c7b699 rsp=000000e394b99510 rbp=000000e394b99d00
r8=0000000000000000 r9=0000000000000007 r10=0000000000000000
r11=0000000000000000 r12=0000022da11451d0 r13=0000000000000000
r14=000000e394b9a9e0 r15=0000000000040ae4
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000200
KERNELBASE!RaiseException+0x69:
00007ff9`59c7b699 0f1f440000 nop dword ptr [rax+rax]
Resetting default scope
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ff959c7b699 (KERNELBASE!RaiseException+0x0000000000000069)
ExceptionCode: c000041d
ExceptionFlags: 00000001
NumberParameters: 0
PROCESS_NAME: xxx.Desktop.dll
ERROR_CODE: (NTSTATUS) 0xc000041d - <Unable to get error code text>
EXCEPTION_CODE_STR: c000041d
...
從卦中可以看到當前的崩潰碼是 c000041d，即 An unhandled exception was encountered during a user callback,這個異常碼是個統稱異常，言外之意就是內部還藏有真實的異常碼，那真實的異常碼是多少呢？
2. 真實的異常碼在哪裡
要想知道這個答案，可以切到異常上下文找到 RaiseException 的父函數在圖觀察，輸出如下：
0:000> k 5
# Child-SP RetAddr Call Site
00 000000e3`94b99510 00007ff8`eb52cb19 KERNELBASE!RaiseException+0x69
01 000000e3`94b995f0 00007ff8`eb52cb4b coreclr!NakedThrowHelper2+0x9
02 000000e3`94b99620 00007ff8`eb52cb55 coreclr!NakedThrowHelper_RspAligned+0x1e
03 000000e3`94b99b48 00007ff8`8da3caa3 coreclr!NakedThrowHelper_FixRsp+0x5
04 000000e3`94b99b50 00007ff8`8d5a5e23 Avalonia_Base!Avalonia.Rendering.Composition.Compositor.RequestCompositionUpdate+0x83
0:000> ub 00007ff8`eb52cb19
...
00007ff8`eb52cb14 e857910b00 call coreclr!LinkFrameAndThrow (00007ff8`eb5e5c70)
0:000> uf coreclr!LinkFrameAndThrow
Flow analysis was incomplete, some code may be missing
coreclr!LinkFrameAndThrow [D:\a\_work\1\s\src\coreclr\vm\excep.cpp @ 6934]:
6934 00007ff8`eb5e5c70 4053 push rbx
6934 00007ff8`eb5e5c72 4883ec20 sub rsp,20h
6937 00007ff8`eb5e5c76 488d05bb771f00 lea rax,[coreclr!FaultingExceptionFrame::`vftable' (00007ff8`eb7dd438)]
...
6949 00007ff8`eb5e5cea 448b05c7682800 mov r8d,dword ptr [coreclr!g_SavedExceptionInfo+0x18 (00007ff8`eb86c5b8)]
6949 00007ff8`eb5e5cf1 8b15ad682800 mov edx,dword ptr [coreclr!g_SavedExceptionInfo+0x4 (00007ff8`eb86c5a4)]
6949 00007ff8`eb5e5cf7 8b0da3682800 mov ecx,dword ptr [coreclr!g_SavedExceptionInfo (00007ff8`eb86c5a0)]
6950 00007ff8`eb5e5cfd 4883c420 add rsp,20h
6950 00007ff8`eb5e5d01 5b pop rbx
6949 00007ff8`eb5e5d02 48ff2537581b00 jmp qword ptr [coreclr!_imp_RaiseException (00007ff8`eb79b540)] Branch
...
從卦中可以看到 RaiseException 的參數來自於異常信息全局變數 g_SavedExceptionInfo，這個變數中存放著當前崩潰的真實上下文以及寄存器信息，在 CLR 中的數據結構如下：
struct SavedExceptionInfo
{
EXCEPTION_RECORD m_ExceptionRecord;
CONTEXT m_ExceptionContext;
CrstStatic m_Crst;
}
有了這些之後接下來就可以用 dt 來挖了，輸出如下：
0:000> dt coreclr!g_SavedExceptionInfo 00007ff8eb86c5a0
+0x000 m_ExceptionRecord : _EXCEPTION_RECORD
+0x0a0 m_ExceptionContext : _CONTEXT
+0x570 m_Crst : CrstStatic
0:000> dx -r1 (*((coreclr!_EXCEPTION_RECORD *)0x7ff8eb86c5a0))
(*((coreclr!_EXCEPTION_RECORD *)0x7ff8eb86c5a0)) [Type: _EXCEPTION_RECORD]
[+0x000] ExceptionCode : 0xc0000005 [Type: unsigned long]
[+0x004] ExceptionFlags : 0x0 [Type: unsigned long]
[+0x008] ExceptionRecord : 0x0 [Type: _EXCEPTION_RECORD *]
[+0x010] ExceptionAddress : 0x7ff88da3caa3 [Type: void *]
[+0x018] NumberParameters : 0x2 [Type: unsigned long]
[+0x020] ExceptionInformation [Type: unsigned __int64 [15]]
從卦中信息來看當前崩潰的真正原因是 0xc0000005，即 訪問違例，同時還記錄了崩潰的那個點 RIP=0x7ff88da3caa3。
3. 什麼邏輯導致的崩潰
這個比較簡單，用 !U 和 uf 都可以試下，輸出如下：
0:000> !U 0x7ff88da3caa3
Normal JIT generated code
Avalonia.Rendering.Composition.Compositor.RequestCompositionUpdate(System.Action)
ilAddr is 0000022DC65AE2D4 pImport is 00000238EE6FECA0
Begin 00007FF88DA3CA20, size 96
...
00007ff8`8da3ca9b 488bce mov rcx,rsi
00007ff8`8da3ca9e e8cdeaa5fe call 00007ff8`8c49b570 (Avalonia.Rendering.Composition.Compositor.RequestCompositionBatchCommitAsync(), mdToken: 00000000060009D9)
>>> 00007ff8`8da3caa3 488b4008 mov rax,qword ptr [rax+8]
00007ff8`8da3caa7 8b4008 mov eax,dword ptr [rax+8]
...
0:000> dt coreclr!g_SavedExceptionInfo 00007ff8eb86c5a0
+0x000 m_ExceptionRecord : _EXCEPTION_RECORD
+0x0a0 m_ExceptionContext : _CONTEXT
+0x570 m_Crst : CrstStatic
0:000> dx -r1 (*((coreclr!_CONTEXT *)0x7ff8eb86c640))
...
[+0x078] Rax : 0x0 [Type: unsigned __int64]
...
從卦中的彙編代碼看，崩潰的原因是Avalonia 框架的 RequestCompositionBatchCommitAsync 返回 null 導致的，即 rax=0,這個 Avalonia 不就是那個跨平臺的WPF嗎，有點意思了，接下來到源碼中確認下到底是什麼變數。
從代碼邏輯上看 _nextCommit 是一個類變數而不是方法局部變數，在併發較高的情況下如果有其他方法將_nextCommit=null的話確實存在這種情況，為了驗證想法在類中搜索，真的有方法會設置 null，截圖如下：
到這裡基本就搞清楚了，這是 Avalonia 的一個bug，最後我們看下 Avalonia 的版本，發現這個版本是非常新的，輸出如下：
0:000> lmvm Avalonia_Base
...
Timestamp: A0BE2821 (This is a reproducible build file hash, not a timestamp)
CheckSum: 001CDA05
ImageSize: 001D4000
File version: 11.1.0.0
Product version: 11.1.0.0
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0000.04b0
Information from resource tables:
CompanyName: Avalonia Team
ProductName: Avalonia
InternalName: Avalonia.Base.dll
OriginalFilename: Avalonia.Base.dll
ProductVersion: 11.1.0+2a8ea17985fd739234fa0d93c3437948535d35c4
FileVersion: 11.1.0.0
FileDescription: Avalonia.Base
LegalCopyright: Copyright 2013-2024 © The AvaloniaUI Project
4. 如何解決呢
知道了這是 Avalonia 的bug，並且 Avalonia 也是非常新的版本，升級這條路就堵死了，只能提交個issue 給官方：https://github.com/AvaloniaUI/Avalonia 來解決吧。
三：總結
這次生產事故挖了點新東西，有點好奇的是現在工控行業也開始用 Avalonia 替代 WPF 了嗎？ 不過現階段穩定性和 WPF 是沒法比的，期待未來更健壯的版本吧。
