記一次 .NET某工業設計軟體 崩潰分析

来源:https://www.cnblogs.com/huangxincheng/p/18224311
-Advertisement-
Play Games

一：背景 1. 講故事 前些天有位朋友找到我，說他的軟體在客戶那邊不知道什麼原因崩掉了，從windows事件日誌看崩潰在 clr 里，讓我能否幫忙定位下，dump 也抓到了，既然dump有了，接下來就上 windbg 分析吧。 二：WinDbg 分析 1. 為什麼崩潰在 clr 一般來說崩潰在clr ...


一：背景

1. 講故事

前些天有位朋友找到我，說他的軟體在客戶那邊不知道什麼原因崩掉了，從windows事件日誌看崩潰在 clr 里，讓我能否幫忙定位下，dump 也抓到了，既然dump有了，接下來就上 windbg 分析吧。

二：WinDbg 分析

1. 為什麼崩潰在 clr

一般來說崩潰在clr里都不是什麼好事情，這預示著 clr 在執行自身代碼的時候拋了異常，即災難的 ExecutionEngineException，可以用 !t 驗證下。


0:000> !t
ThreadCount:      18
UnstartedThread:  0
BackgroundThread: 7
PendingThread:    0
DeadThread:       11
Hosted Runtime:   no
                                                                         Lock  
       ID OSID ThreadOBJ    State GC Mode     GC Alloc Context  Domain   Count Apt Exception
   0    1 52e8 18998d50     24220 Preemptive  639B0D58:00000000 18c361f0 0     STA System.ExecutionEngineException 1f421120
   ...

既然是災難性異常，那為什麼會出現呢？可以用 !analyze -v 觀察下。


0:000> !analyze -v
CONTEXT:  0115a98c -- (.cxr 0x115a98c)
eax=00000000 ebx=00000000 ecx=00000000 edx=18c364a4 esi=00030000 edi=18998d50
eip=552bfff1 esp=0115ae6c ebp=0115af24 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!VirtualCallStubManager::ResolveWorker+0x33:
552bfff1 8bb968020000    mov     edi,dword ptr [ecx+268h] ds:002b:00000268=????????
Resetting default scope

READ_ADDRESS:  00000268 

STACK_TEXT:  
0115af24 552c0698     0115afdc 1f4222c0 00030000 clr!VirtualCallStubManager::ResolveWorker+0x33
0115affc 552c070b     0115b010 1f4222c0 00030000 clr!VSD_ResolveWorker+0x1d2
0115b024 28a3a949     639b0d38 00000000 00000000 clr!ResolveWorkerAsmStub+0x1b
0115b0a4 28a3a8bd     00000000 00000000 00000000 xxxx!xxx
...

我去，真無語了，我卦中數據看，這是一個介面Stub調用的崩潰，在這裡崩潰真的是少之又少，從彙編代碼 edi,dword ptr [ecx+268h] ds:002b:00000268=???????? 上看就是因為 ecx =0 導致的，接下來觀察下方法的彙編代碼。

從彙編上看這個 ecx 其實就是這個方法的 this 指針，那為什麼 this =null 呢？這就很奇葩了。

2. 為什麼 this =null

要想找到這個答案，只能看clr源代碼，簡化後如下：


PCODE VSD_ResolveWorker(TransitionBlock* pTransitionBlock,
                        TADDR siteAddrForRegisterIndirect,
                        size_t token
                        )
{
    ...
    VirtualCallStubManager::StubKind stubKind = VirtualCallStubManager::SK_UNKNOWN;
    VirtualCallStubManager* pMgr = VirtualCallStubManager::FindStubManager(callSiteTarget, &stubKind);
    
    ...
    target = pMgr->ResolveWorker(&callSite, protectedObj, representativeToken, stubKind);
}

從卦中代碼看，問題就是 pMgr=null 導致的，無語了，這個 VirtualCallStubManager::FindStubManager 方法的本意就是根據 callSite的stub的首碼找到對應的 虛調用管理器，它的核心邏輯如下：


StubKind getStubKind(PCODE stubStartAddress, BOOL usePredictStubKind = TRUE)
{
    StubKind predictedKind = (usePredictStubKind) ? predictStubKind(stubStartAddress) : SK_UNKNOWN;
    ...
    if (predictedKind == SK_LOOKUP)
    {
        if (isLookupStub(stubStartAddress))
            return SK_LOOKUP;
    }
    ...
    return SK_UNKNOWN;
}

VirtualCallStubManager::StubKind VirtualCallStubManager::predictStubKind(TADDR stubStartAddress)
{
    StubKind stubKind = SK_UNKNOWN;

    WORD firstWord = *((WORD*)stubStartAddress);

    if (firstWord == 0x05ff)
    {
        stubKind = SK_DISPATCH;
    }
    else if (firstWord == 0x6850)
    {
        stubKind = SK_LOOKUP;
    }
    else if (firstWord == 0x8b50)
    {
        stubKind = SK_RESOLVE;
    }

    return stubKind;
}

接下來需要找到 stubStartAddress 的地址是多少？這個只需要提取 ResolveWorker 方法的第一個參數 callSite 即可。


0:000> dp poi(0115afdc) L1
0c740040  0c746012

0:000> u 0c746012
0c746012 50              push    eax
0c746013 6800000300      push    30000h
0c746018 e9d3a6b748      jmp     clr!ResolveWorkerAsmStub (552c06f0)
0c74601d 0000            add     byte ptr [eax],al
0c74601f 0000            add     byte ptr [eax],al
0c746021 005068          add     byte ptr [eax+68h],dl
0c746024 0000            add     byte ptr [eax],al
0c746026 46              inc     esi

0:000> dp 0c746012 L1
0c746012  00006850

對比剛纔的代碼既然都返回來了 SK_LOOKUP 那為什麼還是 SK_UNKNOWN 呢？ 這個也可以通過線上程棧上找到 &stubKind 變數得到驗證。

0:000> uf 552c0698
...
clr!VSD_ResolveWorker+0x1ab:
552c065f 8b85e0ffffff    mov     eax,dword ptr [ebp-20h]
552c0665 83a5ecffffff00  and     dword ptr [ebp-14h],0
552c066c 8d95ecffffff    lea     edx,[ebp-14h]
552c0672 8b08            mov     ecx,dword ptr [eax]
552c0674 e858feffff      call    clr!VirtualCallStubManager::FindStubManager (552c04d1)
552c0679 ffb5ecffffff    push    dword ptr [ebp-14h]
552c067f 51              push    ecx
552c0680 8bcc            mov     ecx,esp
552c0682 8931            mov     dword ptr [ecx],esi
552c0684 ffb5e8ffffff    push    dword ptr [ebp-18h]
552c068a 8d8de0ffffff    lea     ecx,[ebp-20h]
552c0690 51              push    ecx
552c0691 8bc8            mov     ecx,eax
552c0693 e823f9ffff      call    clr!VirtualCallStubManager::ResolveWorker (552bffbb)
552c0698 8bf0            mov     esi,eax
...

0:000> dp 0115affc-0x14 L1
0115afe8  00000000

我感覺這邏輯也只有clr團隊幫忙解釋，我已經搞不清楚了，接下來我們回頭看托管方法，看能不能繼續下去。

3. 在托管層尋找突破口

高級調試就是這樣，一個方向走不通就需要在另一個方向上突破，接下來使用 !clrstack 觀察一下。


0:000> !clrstack
OS Thread Id: 0x52e8 (0)
Child SP       IP Call Site
0115af50 775c2aac [GCFrame: 0115af50] 
0115afac 775c2aac [StubDispatchFrame: 0115afac]xxx.GetListDrawerType(System.String)
0115b02c 28a3a949 xxx.PluginInvoker.InvokeMothod[[System.__Canon, mscorlib]](System.String, System.Object[])
0115b0b0 28a3a8bd xxx.xxx.OnFinishSizeCheck(Int64)
...

從調用棧來看，貌似是用反射來實現功能增強，不管怎麼說先看下xxxCheck 方法幹了什麼？簡化後的代碼如下：


public string OnFinishSizeCheck(long uuid)
{
    return PluginInvoker.InvokeMothod<string>("xxxCheck", new object[1] { uuid });
}

public static T InvokeMothod<T>(string methodName, params object[] args)
{
    IPluginInvoker pluginInvoker = GetPluginInvoker();

    return (T)pluginInvoker.InvokeMothod(methodName, args);
}

從代碼上可以看到原來是使用 (T)pluginInvoker.InvokeMothod(methodName, args); 實現的介面調用，在coreclr層面也能觀察得到，找到對象 1f4222c0 之後按圖索驥即可。


0:000> !do 1f4222c0
Name:        xxx.xxx.BusinessAppDomainInvoker
MethodTable: 0c73a144
EEClass:     0c6d6f0c
Size:        12(0xc) bytes
File:        E:\xxx\xxx.dll
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
0c73a4e8  400000a        4 ....AppDomainManager  0 instance 1f42236c appDomainManager
0c73a2dc  4000009       18 ..., xxx]]  0   static 1f422214 lazy

0:000> !dumpmt -md 0c73a144
EEClass:         0c6d6f0c
Module:          0c7383dc
Name:            xxx.xxx.BusinessAppDomainInvoker
mdToken:         02000006
File:            E:\xxx\xxx.dll
BaseSize:        0xc
ComponentSize:   0x0
Slots in VTable: 10
Number of IFaces in IFaceMap: 1
--------------------------------------
MethodDesc Table
   Entry MethodDe    JIT Name
   ...
0c6c3400 0c73a110    JIT xxx.xxx.InvokeMothod(System.String, System.Object[])

0:000> !do  poi(0c73a144+0x24)
Name:        xxx.IPluginInvoker
MethodTable: 0c739f30
EEClass:     0c6d6d34
Size:        0(0x0) bytes
File:        E:\xxx\xxx.dll
Fields:
None
ThinLock owner 1 (18998d50), Recursive 0

對比那個 token=30000h 發現什麼地方都沒有問題，奇葩的就是一個簡單介面調用就出現了問題，仔細觀察代碼之後發現了兩個和別人不一樣的地方。

4. 與眾不同的地方在哪裡

第一個是他的程式是多 AppDomain 的，可以用 !dumpdomain 觀察。


0:000> !dumpdomain
--------------------------------------
System Domain:      55a6caa0
...
--------------------------------------
Shared Domain:      55a6c750
LowFrequencyHeap:   55a6cdc4
Stage:              OPEN
--------------------------------------
Domain 1:           18b04690
LowFrequencyHeap:   18b04afc
Name:               DefaultDomain
--------------------------------------
Domain 2:           18c361f0
LowFrequencyHeap:   18c3665c
...

第二個是我發現托管調用棧上還有很多 托管C++，這種混合編程真的是無語了。

到這裡我想到了三個辦法：

1）如果可以先把介面方法預熱，clr會直接把方法入口塞到彙編里，就不會再走clr底層邏輯了。

2）能否將 托管C++ 和 C# 隔離，不要混合編程。

3）重點觀察下多Domain下這個托管調用是不是有什麼問題。

三：總結

這種 多domain + 托管C++混合C# 編程，真出問題了基本上就是無解，一般人hold不住，無語了。

圖片名稱
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • MyBatis中的介面代理機制及其使用
    1. MyBatis中的介面代理機制及其使用 @目錄1. MyBatis中的介面代理機制及其使用2. 實操2.1 準備工作2.2 insert 增加操作2.3 delete 刪除操作2.4 update 修改操作2.5 select 查詢一條記錄操作2.6 select 查詢多條記錄操作3. 總結： ...
  • 基於WPF開發動態可交互混淆矩陣
    最近在項目中，為了演算法結果的可視化，需要用到混淆矩陣(Confusion Matrix)，而網上資源大多是基於Python繪製的混淆矩陣，並且是輸出圖片格式，並不能響應用戶點擊，今天以一個簡單的小例子，簡述如何通過WPF繪製混淆矩陣，並可響應用戶點擊事件，僅供學習分享使用，如有不足之處，還請指正。 ...
  • 分享下最近基於Avalonia UI和MAUI寫跨平臺時間管理工具的體驗
    ReZero AP ReZero是一款.NET中間件 ： 一款通過界面操作就能生成API , 可以集成到任何.NET6+ API項目,無破壞性，也可讓非.NET用戶使用exe文件 ReZero生成器功能簡介 1、表文檔導出：支持目錄導航 2、線上創建表、線上建庫 3、一鍵導入現有表 4、模版線上調試 ...
  • .NET集成DeveloperSharp實現"高效分頁"&"無主鍵分頁"
    DeveloperSharp系列近期又被製造業ERP、民航飛行App、建築BIM、電力掌上營業廳、等多家大型採用，站在巨人的肩膀上你能走的更遠。 支持.Net Core2.0及以上，支持.Net Framework4.0及以上 數據分頁，幾乎是任何應用系統的必備功能。但當數據量較大時，分頁操作的效率 ...
  • C#.Net築基-深入解密小數內部存儲的秘密
    為什麼0.1 + 0.2 不等於 0.3？為什麼16777216f 等於 16777217f？為什麼金錢計算都推薦用decimal？本文主要學習瞭解一下數字背後不為人知的存儲秘密。 ...
  • .NET程式對接 OpenTelemetry logs
    OpenTelemetry 簡介 OpenTelemetry 是一個由 CNCF（Cloud Native Computing Foundation）托管的開源項目，旨在為觀察性（Observability）提供一套全面的工具，包括度量（Metrics）、日誌（Logs）和追蹤（Traces）。它的 ...
  • C#使用RegNotifyChangeKeyValue監聽註冊表更改的幾種方式
    先上兩個通用Modbus幫助類,下麵這個是多線程不安全版，在多線程多電機同一埠通信下，可能造成步進電機丟步或者輸出口無響應等，還有個多線程安全版，只是基於這個不安全版加上了LOCK,THIS using Modbus.Device; using Sunny.UI; using System; us ...
  • gRPC入門學習之旅（九）
    最近在項目中，業務上需要與Python進行交互，而Python程式用的配置文件主要是YAML，程式以命令行形式運行，前端頁面由C#通過WPF開發完成。現在需要通過C#生成YAML配置文件，並經過Python讀取和修改後，再次由C#進行讀取。在C#開發程式中，主要用的配置文件主要是XML，JSON，I... ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類