記一次 .NET某企業數位化平台 崩潰分析

2024-05-28碼農

一：背景

1. 講故事

前些天群裏有一個朋友說他們軟體會偶發崩潰，想分析看看是怎麽回事，所幸的是自己會抓dump檔，有了dump就比較好分析了，接下來我們開始吧。

二：WinDbg 分析

1. 程式為什麽會崩潰

windbg 還是非常強大的，當你雙擊開啟的時候會自動幫你定位過去展示崩潰時刻的寄存器和執行緒棧上下文，都省了 !analyze -v 命令分析了，輸出如下：

Loading unloaded module list ............... This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (1dc.774): Stack overflow - code c00000fd (first/second chance not available) For analysis of this file, run !analyze -v 000007f8`93111989 837c243000 cmp dword ptr [rsp+30h],0 ss:0000007b`e7894160=00000000

從卦中可以看到有一個 Stack overflow 異常，說明當前棧溢位了，有點意思。

2. 棧溢位了嗎

如果你想探究下棧溢位也是可以的，用 rsp 比較下 !teb 中的 StackLimit 值。

0:019> r rsp rsp=0000007be7894130 0:019> !teb TEB at 000007f6cd664000 ExceptionList: 0000000000000000 StackBase: 0000007be7a10000 StackLimit: 0000007be7891000 SubSystemTib: 0000000000000000 FiberData: 0000000000001e00 ArbitraryUserPointer: 0000000000000000 Self: 000007f6cd664000 EnvironmentPointer: 0000000000000000 ClientId: 00000000000001dc . 0000000000000774 RpcHandle: 0000000000000000 Tls Storage: 0000007be84b5b90 PEB Address: 000007f6cd7af000 LastErrorValue: 0 LastStatusValue: c0000302 Count Owned Locks: 0 HardErrorMode: 0 0:019> !address -f:Stack BaseAddress EndAddress+1 RegionSize Type State Protect Usage -------------------------------------------------------------------------------------------------------------------------- 7b`e7890000 7b`e7891000 0`00001000 MEM_PRIVATE MEM_RESERVE Stack [~19; 1dc.774] 7b`e7891000 7b`e7a10000 0`0017f000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~19; 1dc.774]

從卦中看 PAGE_GUARD 頁已經抹掉了，這就表示當前的 rsp 已經進入到這個 0x3000 大小的 PAGE_GUARD 頁面裏去了。

有些朋友可能會有一個疑問，這個異常是怎麽被界定為 StackOverflowException 的呢？如果你了解哨兵頁就比較簡單了，一旦rsp進了這個哨兵頁，在這裏丟擲的異常會被界定為 c00000fd ，最後這個異常會被 coreclr 的 MapWin32FaultToCOMPlusException 方法強制轉為托管的 StackOverflowException 異常，這個都是有源碼支撐的。

EXCEPTION_RECORD: (.exr -1) ExceptionAddress: 000007f8ed571a90 (coreclr!MetaDataImport::Enum+0x0000000000000030) ExceptionCode: c00000fd (Stack overflow) ExceptionFlags: 00000001 NumberParameters: 2 Parameter[0]: 0000000000000001 Parameter[1]: 0000007be7893f38 DWORD MapWin32FaultToCOMPlusException(EXCEPTION_RECORD *pExceptionRecord) { switch (pExceptionRecord->ExceptionCode) { ... case STATUS_STACK_OVERFLOW: return (DWORD) kStackOverflowException; .... default: return kSEHException; } }

3. 到底誰給弄溢位了

現在我們定位到的執行緒就是棧溢位執行緒，使用 kc 觀察呼叫棧，輸出如下：

0:019> kc # Call Site 00 System_Private_CoreLib!System.Reflection.RuntimeCustomAttributeData.GetCustomAttributeRecords 01 System_Private_CoreLib!System.Reflection.CustomAttribute.AddCustomAttributes 02 System_Private_CoreLib!System.Reflection.CustomAttribute.GetCustomAttributes 03 System_Private_CoreLib!System.Attribute.GetCustomAttributes ... 0c SqlSugar!SqlSugar.MemberExpressionResolve..ctor 0d SqlSugar!SqlSugar.BaseResolve.Start 0e SqlSugar!SqlSugar.BinaryExpressionResolve.Right 0f SqlSugar!SqlSugar.BinaryExpressionResolve.DefaultBinary 10 SqlSugar!SqlSugar.BinaryExpressionResolve.Other 11 SqlSugar!SqlSugar.BinaryExpressionResolve..ctor 12 SqlSugar!SqlSugar.BaseResolve.Start 13 SqlSugar!SqlSugar.BinaryExpressionResolve.Right 14 SqlSugar!SqlSugar.BinaryExpressionResolve.DefaultBinary 15 SqlSugar!SqlSugar.BinaryExpressionResolve.Other 16 SqlSugar!SqlSugar.BinaryExpressionResolve..ctor 17 SqlSugar!SqlSugar.BaseResolve.Start ...

預設的 kc 只能顯示 255 個執行緒棧，在棧溢位場景下沒辦法完全展開，不管怎麽樣從棧看貌似是 SqlSugar 導致的棧溢位，那它是這次災難的罪魁禍首嗎？

4. SqlSugar 是禍首嗎

要想找到這個答案，需要看下 SqlSugar 是被怎樣的使用者程式碼呼叫的，有兩種辦法，要麽在 k 上設定 StackPtr，要麽設定最大的棧個數 0xffff ，這裏選擇後者。

0:019> kc 0xffff # Call Site .... 145b SqlSugar!SqlSugar.ExpressionContext.Resolve 145c SqlSugar!SqlSugar.QueryBuilder.GetExpressionValue 145d SqlSugar!SqlSugar.QueryableProvider<xxx>._Where 145e SqlSugar!SqlSugar.QueryableProvider<xxxx>.Where 145f SqlSugar!SqlSugar.SimpleClient<xxx>.GetListAsync 1460 xxx!xxx.TSqlSugar.xxx<xxx.Entities.Quality.xxxSummaryEntity>.<QueryAsync>d__37.MoveNext 1461 System_Private_CoreLib!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<<QueryAsync>d__37> 1462 xxx!xxx.TSqlSugar.BaseRepository<xxx.xxxSummaryEntity>.QueryAsync 1463 xxx!xxxxCalculateService.<xxxnRate>d__26.MoveNext ...

從卦中可以看到有一個 xxxxCalculateService 使用者類呼叫了 QueryAsync 方法，接下來直接到源碼定位，截圖如下：

這段程式碼乍一看貌似沒有問題，但仔細看還是有一些端倪的，對，就是當 diffMonth 很大時， expressionable 就會累計出很多的 And 條件，在QueryAsync的時候底層的 SqlSugar 在拆解 expressionable 的過程中丟擲了異常。

5. SqlSugar 真的在拆解中異常了嗎

拆解運算式樹的程式碼太難了，我真的看不懂，在這種情況下如何尋找突破口呢？這裏可以逆向的想一想，既然是拆解，自然就會產生很多小段sql，所以直接到托管堆中看下當前的 string 情況即可。

0:019> !strings Address Gen Length Value --------------------------------------- ... 0000007bc15a0240 LOH 97005 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc15cf850 LOH 97005 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc15fee60 LOH 97009 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc162e478 LOH 97009 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc165da90 LOH 97074 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc168d130 LOH 97099 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc16bc800 LOH 97099 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc16ebed0 LOH 97103 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc171b5a8 LOH 97103 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... 0000007bc174ac80 LOH 97113 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((... .... --------------------------------------- 39498 strings