記一次 .NET某爐膛鍋爐檢測系統 崩潰分析

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

一：背景 1. 講故事 上個月有個朋友在微信上找到我，說他們的軟體在客戶那邊隔幾天就要崩潰一次，一直都沒有找到原因，讓我幫忙看下怎麼回事，確實工控類的軟體環境複雜難搞，朋友手上有一個崩潰的dump，剛好丟給我來分析一下。 二：WinDbg分析 1. 程式為什麼會崩潰 windbg 有一個厲害之處在於 ...


一：背景

1. 講故事

上個月有個朋友在微信上找到我，說他們的軟體在客戶那邊隔幾天就要崩潰一次，一直都沒有找到原因，讓我幫忙看下怎麼回事，確實工控類的軟體環境複雜難搞，朋友手上有一個崩潰的dump，剛好丟給我來分析一下。

二：WinDbg分析

1. 程式為什麼會崩潰

windbg 有一個厲害之處在於雙擊之後可以幫你自動定位到崩潰處，輸出如下：


................................................................
................................................................
.......................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1418.89c): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
clr!WKS::gc_heap::background_mark_simple1+0x5a1:
000007fe`f5316d40 41f70300000080  test    dword ptr [r11],80000000h ds:00000000`00000000=????????

從卦中信息看，這不是一件好事情，崩潰居然落在bgc線程上，此時bgc線程正在做後臺對象標記，依據過往經驗有可能是托管堆損壞了，可以用 !verifyheap 命令來驗證下。


0:038> !verifyheap 
Object 000000000476a0a8 has an invalid method table.
Last good object: 000000000476A058.

0:038> !lno 000000000476a0a8
Before:  000000000476a058           80 (0x50)	System.Text.RegularExpressions.RegexWriter
After:   000000000476a0c0          152 (0x98)	System.Int32[]

0:038> dp 000000000476a058
00000000`0476a058  000007fe`f0e47390 00000000`0476a0c0
00000000`0476a068  00000000`0476a1d0 00000000`0476a158
00000000`0476a078  00000000`0476a1a8 00000000`00000000
00000000`0476a088  0000001a`00000000 00000006`0000001a
00000000`0476a098  00000000`00000000 00000000`00000018
00000000`0476a0a8  00000000`00000000 00000000`00000000
00000000`0476a0b8  00000000`00000000 000007fe`f2ce9250
00000000`0476a0c8  00000000`00000020 00000004`00000000

從卦中看確實有一個對象處於有損狀態，它的 mt=0 ,objheader=0x18，這個信息還是蠻奇怪的，接下來觀察下記憶體地址的佈局，找出有損地址空間，截圖如下：

上面圈出來的地址段也不像是 C++ 故意改的，那到底是真破壞還是假破壞呢？因為這一點確實可以決定後續的分析方向。

2. 托管堆真假破壞之謎

熟悉 bgc 運轉邏輯的朋友都知道會有三個階段，分別為 初始標記,併發標記,最終標記，所以接下來的問題是當前這個程式處於什麼階段呢? 這個觀察手段比較多，除了看bgc流程也可以 !t -special 看看 SuspendEE 標記。


0:038> !t -special
ThreadCount:      40
       ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
   24   12 174c 000000001e71c210  1029220 Cooperative 0000000000000000:0000000000000000 000000000027ba40 2     MTA (GC) (Threadpool Worker) 
   ...
   38   13  89c 000000001e529130    21220 Preemptive  0000000000000000:0000000000000000 000000000027ba40 0     Ukn System.ExecutionEngineException 00000000022f1228

          OSID Special thread type
        24 174c SuspendEE ThreadpoolWorker

從卦中可以清晰的看到24號線程觸發了一個前臺GC，同時38號的 bgc拋了執行引擎異常，這個災難性的異常也是程式崩潰的原因，接下來觀察下 24號正在做什麼。


0:024> k 10
 # Child-SP          RetAddr               Call Site
00 00000000`205ebcf0 000007fe`f52fb444     clr!GcInfoDecoder::EnumerateLiveSlots+0x4df
01 00000000`205ec140 000007fe`f52fbd81     clr!EECodeManager::EnumGcRefs+0xc4
02 00000000`205ec2a0 000007fe`f5380aee     clr!GcStackCrawlCallBack+0x171
03 00000000`205ec3a0 000007fe`f52fbc28     clr!Thread::StackWalkFrames+0x172
04 00000000`205ed820 000007fe`f53141f0     clr!CNameSpace::GcScanRoots+0x144
05 00000000`205ed8c0 000007fe`f5310a8e     clr!WKS::gc_heap::relocate_phase+0x40
06 00000000`205ed930 000007fe`f5310fd0     clr!WKS::gc_heap::plan_phase+0xa01
07 00000000`205edb90 000007fe`f530df61     clr!WKS::gc_heap::gc1+0x9f
08 00000000`205edbe0 000007fe`f530dccd     clr!WKS::gc_heap::garbage_collect+0x222
09 00000000`205edc70 000007fe`f530e220     clr!WKS::GCHeap::GarbageCollectGeneration+0xdd
0a 00000000`205edcc0 000007fe`f516ae69     clr!WKS::GCHeap::Alloc+0x29d
0b 00000000`205edd10 000007fe`f2b2ab2a     clr!FramedAllocateString+0x139
...

從卦中可以清晰的看到此時的GC正在 relocate_phase 重定位階段，重定位階段通俗來說就是 兵馬未動，糧草先行，這是一種非原子性的操作，簡單來說bgc拿到的可能是移動後的新地址（糧草），但對象（兵馬）還是在老地方，所以剛纔看到的托管堆那塊空間是初始化狀態，同時對象頭的 0x18 應該是一種中間狀態的對象標記，這個暫時不去深挖了，但不管怎麼說，此時的托管堆大概率是沒有問題的。

既然托管堆沒有問題，後面的研究方向就得深挖 bgc 的邏輯了。

3. bgc線程到底怎麼了

要知道 bgc 到底怎麼了，必須要觀察它附近的彙編代碼，可以用 ub 命令，輸出如下：


0:024> r
Last set context:
rax=000000000001b83b rbx=0000000020e5e5b0 rcx=0000000000370707
rdx=00000000029b78a0 rsi=0000000000000000 rdi=0000000020e5e0c0
rip=000007fef5316d40 rsp=0000000020e5e680 rbp=000000001a30a2fc
 r8=0000000003707670  r9=000007fef2c94438 r10=00000000029b88b0
r11=0000000000000000 r12=0000000000000010 r13=000007fef2c94438
r14=0000000000291808 r15=0000000000001f60
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010244
clr!WKS::gc_heap::background_mark_simple1+0x5a1:
000007fe`f5316d40 41f70300000080  test    dword ptr [r11],80000000h ds:00000000`00000000=????????

0:024> ub 000007fe`f5316d40
clr!WKS::gc_heap::background_mark_simple1+0x584:
000007fe`f5316d23 48c1e809        shr     rax,9
000007fe`f5316d27 80e11f          and     cl,1Fh
000007fe`f5316d2a 41d3e3          shl     r11d,cl
000007fe`f5316d2d 44855c8500      test    dword ptr [rbp+rax*4],r11d
000007fe`f5316d32 7548            jne     clr!WKS::gc_heap::background_mark_simple1+0x5f3 (000007fe`f5316d7c)
000007fe`f5316d34 44095c8500      or      dword ptr [rbp+rax*4],r11d
000007fe`f5316d39 4d8b18          mov     r11,qword ptr [r8]
000007fe`f5316d3c 4983e3fe        and     r11,0FFFFFFFFFFFFFFFEh

從卦中數據來看，崩潰的原因是 r11=0 導致的，r11 的值又來自於 r8，這裡有一個硬編碼值 0FFFFFFFFFFFFFFFEh，這個值在代碼中應該是 -2 或者是 ~1 這兩種情況，接下來觀察下 background_mark_simple1() 的方法源碼，尼瑪。。。 還真給我找到了，簡化後如下：


void gc_heap::background_mark_simple1(uint8_t * oo THREAD_NUMBER_DCL)
{
    ...
    uint8_t* start = oo;
    if ((size_t)oo & 1)
    {
        oo = (uint8_t*)((size_t)oo & ~1);
        start = *(--background_mark_stack_tos);
        dprintf(4, ("oo: %Ix, start: %Ix\n", (size_t)oo, (size_t)start));
    }
    ...
}

先簡單解釋下代碼的意思， oo & ~1 是將 oo 對象的 gcmark標記 給去掉，後面的 background_mark_stack_tos 就是深度優先遍歷過程中使用的棧結構，再結合彙編代碼，我們知道 r8 其實就是 oo，那這個 oo 到底是獨立存在還是歸屬於誰呢？

4. oo 到底是何方神聖

要想知道這個答案，可以用 !lno 命令觀察下 r8 附近記憶體來尋找蛛絲馬跡，輸出如下：


0:024> r r8
Last set context:
r8=0000000003707670

0:024> !lno 0000000003707670
Before:  0000000003707658           80 (0x50)	xxx.ComponentData
After:   00000000037076a8         1416 (0x588)	Free
Heap local consistency confirmed.

0:024> ? 0000000003707670 - 0000000003707658
Evaluate expression: 24 = 00000000`00000018

0:024> !DumpObj /d 0000000003707658
Name:        xxx.ComponentData
MethodTable: 000007fe95c0b058
EEClass:     000007fe95c2bbb0
Size:        80(0x50) bytes
File:        C:\xxxDriver.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007fef2cecf58  400008c       38      System.DateTime  1 instance 0000000003707690 wWfscFiguq
000007fef2cffc90  400008d       18        System.Double  1 instance 0.000000         I9ss25rNyt
000007fe95c0a888  400008e       20         System.Int32  1 instance                9 AxCs5sGCxm
000007fe95c0af00  400008f       24         System.Int32  1 instance                9 fK9sgqZ2qY
...

這個卦看起來就非常奇怪，無語了。。。 我苦苦尋找的 oo 對象居然是一個 int 類型的 fK9sgqZ2qY 欄位，這不是亂套了嗎？ int 類型在這裡也沒有裝箱，怎麼可能會提取出 mt 呢？ 真的是莫名奇怪。

5. int 為什麼當 引用類型 了

線索到了這裡越來越不可思議了，基本就可以斷定這是 BGC 標記的錯亂，直白的說就是 BGC 出現了 bug，再看下當前的操作系統和framework的版本,依次是 windows7 和 4.0 。


0:024> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: kernel32.dll version: 6.1.7601.17514 (win7sp1_rtm.101119-1850)

0:024> !eeversion
4.0.30319.18408 free
Workstation mode
In plan phase of garbage collection
SOS Version: 4.0.30319.18408 retail build

綜合來說是 bgc 在老環境下做後臺標記的時候出現了 bug，這種 bug 非我能力之所及，但我能做的就是把它切除掉，即把 bgc 模式給關掉，不走這個邏輯不就行了嗎？ 參考如下：


<configuration>
   <runtime>
      <gcConcurrent enabled="false"/>
   </runtime>
</configuration>

三：總結

很多時候分析下來發現是CLR內部的bug所致，這種真的很無奈，我能做的也只能是手術切除。

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

-Advertisement-
Play Games
更多相關文章
  • 基於SpringWeb MultipartFile文件上傳、下載功能
    在Web開發中，文件上傳是一個常見的功能需求。Spring框架提供了MultipartFile介面，用於處理文件上傳請求。MultipartFile可以代表一個多部分文件上傳請求中的一個文件，提供了一系列方法用於獲取文件的各種屬性和內容，使得在後端處理文件上傳變得十分方便。下麵我們將介紹Multip ...
  • Python中2種常用數據可視化庫：Bokeh和Altair
    本文將重點比較Bokeh和Altair這兩個常用的Python數據可視化庫，探討它們的優缺點以及在不同場景下的適用性。 ...
  • 車輛信息查詢 - 高效快捷地獲取車輛相關信息的利器
    隨著汽車的普及，車輛信息查詢變得越來越重要。無論是買車、賣車還是維修保養，瞭解車輛的詳細信息是必不可少的。而如何高效快捷地查詢車輛信息成為了很多車主的需求。幸運的是，我們有一個非常實用的介面可以滿足這個需求，而這就是挖數據平臺提供的車輛信息查詢介面。 這個介面的主要功能是通過車架號vin來查詢車輛的 ...
  • vim中函數跳轉的功能實現
    左手編程，右手年華。大家好，我是一點，關註我，帶你走入編程的世界。 公眾號：一點sir，關註領取編程資料 介紹 函數跳轉是要給IDE中非常重要也非常常用的功能，而原生的 Vim 並不提供這個功能，這個確定有點讓人遺憾，按理說這麼常用的功能應該是要提供的。但是沒有關係，有插件可以實現這樣的功能更，藉助 ...
  • 【Nano Framework ESP32篇】WS2812 彩色燈帶實驗
    地球人皆知，許多物聯網教程作者的心中都深愛著一燈大師，所以第一個常式總喜歡點燈，高級一點的會來個“一閃一閃亮晶晶”。老周今天要扯的也是和燈有關的，但不單純地點個燈，那樣實在不好玩，缺乏樂趣。老周打算舞個龍燈，哦不，是用 LED 彩色燈帶給伙伴們整點炫酷樂子。 說到這LED彩燈，咱們常見到的有兩類： ...
  • iNeuOS工業互聯網操作系統，民爆遠程運維平臺案例
    民爆生產廠區有地面站和民爆車，現場地面站的控制系統為西門子PLC和歐姆龍PLC，民爆車為三菱PLC，地面站通過光纖與本地機房進行數據交互，民爆車的位置及其他數據通過4G與本地機房進行數據交互。本地機房與北京運維中心進行數據交互，實現民爆行業的綜合運維平臺。 ...
  • WPF隨筆收錄-DataGrid固定右側列
    一、前言 在項目開發過程中，DataGrid是經常使用到的一個數據展示控制項，而通常表格的最後一列是作為操作列存在，比如會有編輯、刪除等功能按鈕。但WPF的原始DataGrid中，預設只支持固定左側列，這跟大家習慣性操作列放最後不符，今天就來介紹一種簡單的方式實現固定右側列。（這裡的實現方式參考的大佬 ...
  • 一個.NET內置依賴註入的小型強化版
    前言 .NET生態中有許多依賴註入容器。在大多數情況下，微軟提供的內置容器在易用性和性能方面都非常優秀。外加ASP.NET Core預設使用內置容器，使用很方便。 但是筆者在使用中一直有一個頭疼的問題：服務工廠無法提供請求的服務類型相關的信息。這在一般情況下並沒有影響，但是內置容器支持註冊開放泛型服 ...
一周排行
    -Advertisement-
    Play Games
  • （開源）都進來！簡單易懂、功能強大的許可權+可視化流程管理系統
    1、預覽地址：http://139.155.137.144:9012 2、qq群:801913255 一、前言 隨著網路的發展，企業對於信息系統數據的保密工作愈發重視，不同身份、角色對於數據的訪問許可權都應該大相徑庭。 列如 1、不同登錄人員對一個數據列表的可見度是不一樣的，如數據列、數據行、數據按鈕 ...
  • 設計模式-C#實現簡單工廠模式
    前言 上一篇文章寫瞭如何使用RabbitMQ做個簡單的發送郵件項目，然後評論也是比較多，也是準備去學習一下如何確保RabbitMQ的消息可靠性，但是由於時間原因，先來說說設計模式中的簡單工廠模式吧！ 在瞭解簡單工廠模式之前，我們要知道C#是一款面向對象的高級程式語言。它有3大特性，封裝、繼承、多態。 ...
  • Nodify學習 一：介紹與使用
    Nodify學習 一：介紹與使用 - 可樂_加冰 - 博客園 (cnblogs.com) Nodify學習 二：添加節點 - 可樂_加冰 - 博客園 (cnblogs.com) 介紹 Nodify是一個WPF基於節點的編輯器控制項，其中包含一系列節點、連接和連接器組件，旨在簡化構建基於節點的工具的過程 ...
  • 使用C#/.NET解析Wiki百科數據實現獲取歷史上的今天
    創建一個webapi項目做測試使用。 創建新控制器，搭建一個基礎框架，包括獲取當天日期、wiki的請求地址等 創建一個Http請求幫助類以及方法，用於獲取指定URL的信息 使用http請求訪問指定url，先運行一下，看看返回的內容。內容如圖右邊所示，實際上是一個Json數據。我們主要解析 大事記 部 ...
  • .NET科普：.NET簡史、.NET Standard以及C#和.NET Framework之間的關係
    最近在不少自媒體上看到有關.NET與C#的資訊與評價，感覺大家對.NET與C#還是不太瞭解，尤其是對2016年6月發佈的跨平臺.NET Core 1.0，更是知之甚少。在考慮一番之後，還是決定寫點東西總結一下，也回顧一下.NET的發展歷史。 首先，你沒看錯，.NET是跨平臺的，可以在Windows、 ...
  • Nodify學習 二：添加節點
    Nodify學習 一：介紹與使用 - 可樂_加冰 - 博客園 (cnblogs.com) Nodify學習 二：添加節點 - 可樂_加冰 - 博客園 (cnblogs.com) 添加節點（nodes） 通過上一篇我們已經創建好了編輯器實例現在我們為編輯器添加一個節點 添加model和viewmode ...
  • 論如何直接用EF Core實現創建更新時間、用戶審計，自動化樂觀併發、軟刪除和樹形查詢（上）
    前言 資料庫併發，數據審計和軟刪除一直是數據持久化方面的經典問題。早些時候，這些工作需要手寫複雜的SQL或者通過存儲過程和觸發器實現。手寫複雜SQL對軟體可維護性構成了相當大的挑戰，隨著SQL字數的變多，用到的嵌套和複雜語法增加，可讀性和可維護性的難度是幾何級暴漲。因此如何在實現功能的同時控制這些S ...
  • C# 使用模式匹配的好處,因為好用所以推薦~
    類型檢查和轉換：當你需要檢查對象是否為特定類型，並且希望在同一時間內將其轉換為那個類型時，模式匹配提供了一種更簡潔的方式來完成這一任務，避免了使用傳統的as和is操作符後還需要進行額外的null檢查。 複雜條件邏輯：在處理複雜的條件邏輯時，特別是涉及到多個條件和類型的情況下，使用模式匹配可以使代碼更 ...
  • 推薦一種批量判斷文件是否存在的快速辦法
    在日常開發中，我們經常需要和文件打交道，特別是桌面開發，有時候就會需要載入大批量的文件，而且可能還會存在部分文件缺失的情況，那麼如何才能快速的判斷文件是否存在呢？如果處理不當的，且文件數量比較多的時候，可能會造成卡頓等情況，進而影響程式的使用體驗。今天就以一個簡單的小例子，簡述兩種不同的判斷文件是否... ...
  • 論如何直接用EF Core實現創建更新時間、用戶審計，自動化樂觀併發、軟刪除和樹形查詢（中）
    前言 資料庫併發，數據審計和軟刪除一直是數據持久化方面的經典問題。早些時候，這些工作需要手寫複雜的SQL或者通過存儲過程和觸發器實現。手寫複雜SQL對軟體可維護性構成了相當大的挑戰，隨著SQL字數的變多，用到的嵌套和複雜語法增加，可讀性和可維護性的難度是幾何級暴漲。因此如何在實現功能的同時控制這些S ...
所有分類