記一次 .NET某半導體CIM系統 崩潰分析

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

一:背景 1. 講故事 前些天有一位朋友在公眾號上找到我,說他們的WinForm程式部署在20多台機器上,只有兩台機器上的程式會出現崩潰的情況,自己找了好久也沒分析出來,讓我幫忙看下怎麼回事,就喜歡這些有點調試基礎的,dump也不需要我指導怎麼去抓,接下來我們就上windbg開始分析吧。 二:Win ...


一:背景

1. 講故事

前些天有一位朋友在公眾號上找到我,說他們的WinForm程式部署在20多台機器上,只有兩台機器上的程式會出現崩潰的情況,自己找了好久也沒分析出來,讓我幫忙看下怎麼回事,就喜歡這些有點調試基礎的,dump也不需要我指導怎麼去抓,接下來我們就上windbg開始分析吧。

二:WinDbg分析

1. 為什麼會崩潰

尋找崩潰的表象比較簡單,使用 windbg 的 !analyze -v 命令即可。


0:000> !analyze -v
...
EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 0000000000000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0
...
STACK_TEXT:  
0000003f`76f7ed58 00007ffa`f7c66d88     : 0000003f`00006120 00007ffa`f7bf98da 00000000`00000000 0000e4f5`bb3ba231 : user32!NtUserWaitMessage+0xa
0000003f`76f7ed60 00007ffa`f7bf9517     : 0000003f`00006120 0000003f`76f7ee80 00000000`00000000 00000000`00000000 : System_Windows_Forms_ni+0x2b6d88
0000003f`76f7ee10 00007ffa`f7bf8c2c     : 0000003f`0006ec30 0000003f`00000001 0000003f`000c88c0 00000000`00000000 : System_Windows_Forms_ni+0x249517
0000003f`76f7ef10 00007ffa`f7bf8a25     : 0000003f`00006120 00000000`ffffffff 0000003f`00054848 0000003f`76f7f300 : System_Windows_Forms_ni+0x248c2c
0000003f`76f7efa0 00007ffa`9b4a0a08     : 0000003f`00007970 00000000`ffffffff 0000003f`000c88c0 0000003f`770bda90 : System_Windows_Forms_ni+0x248a25
0000003f`76f7f000 00007ffa`fab13753     : 00000000`00000001 0000003f`76f7f530 00007ffa`fac6710d 00000000`00000001 : 0x00007ffa`9b4a0a08
0000003f`76f7f040 00007ffa`fab1361c     : 0000003f`00003330 00007ffa`f9acd94c 00000000`20000001 0000003f`00000000 : clr!CallDescrWorkerInternal+0x83
0000003f`76f7f080 00007ffa`fab144d3     : 00000000`00000000 00000000`00000004 0000003f`76f7f300 0000003f`76f7f3b8 : clr!CallDescrWorkerWithHandler+0x4e
0000003f`76f7f0c0 00007ffa`fac6f75a     : 0000003f`76f7f200 00000000`00000000 00000000`00000000 00000000`00000000 : clr!MethodDescCallSite::CallTargetWorker+0x2af
0000003f`76f7f250 00007ffa`fac6f596     : 00000000`00000000 00000000`00000001 0000003f`00000000 00000000`00000000 : clr!RunMain+0x1ba
0000003f`76f7f430 00007ffa`fac6f4d4     : 0000003f`770bda90 0000003f`000015b0 0000003f`770bda90 0000003f`77093490 : clr!Assembly::ExecuteMainMethod+0xba
0000003f`76f7f720 00007ffa`fac6ea02     : 0000003f`76f7fd88 0000003f`76de0000 00000000`00000000 00000000`00000000 : clr!SystemDomain::ExecuteMainMethod+0x6b9
0000003f`76f7fd60 00007ffa`fac6e9b2     : 0000003f`76de0000 0000003f`76f7fee0 00000000`00000000 00007ffb`03c420e8 : clr!ExecuteEXE+0x43
0000003f`76f7fdd0 00007ffa`fac6e8f4     : ffffffff`ffffffff 00000000`00000000 00000000`00000000 00000000`00000000 : clr!_CorExeMainInternal+0xb2
0000003f`76f7fe60 00007ffb`03be6cf5     : 00000000`00000000 00000000`00000091 00000000`00000000 0000003f`76f7fe48 : clr!CorExeMain+0x14
0000003f`76f7fea0 00007ffb`03c8ea5b     : 00000000`00000000 00007ffa`fac6e8e0 00000000`00000000 00000000`00000000 : mscoreei!CorExeMain+0xe0
0000003f`76f7fef0 00007ffb`0dc716ad     : 00007ffb`03be0000 00000000`00000000 00000000`00000000 00000000`00000000 : mscoree!_CorExeMain_Exported+0xcb
0000003f`76f7ff20 00007ffb`0f924629     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
0000003f`76f7ff50 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d


STACK_COMMAND:  ~0s; .ecxr ; kb
...

從卦中看,真的吸了一口涼氣,尼瑪這dump沒記錄到 crash 信息,有些朋友說這個 int 3 不是嗎?簡單的說不是,它是一個軟trap,抓dump的時候會有一個進程的凍結,這個凍結就是 int 3,所以你看dump中有這個異常 99% 都是正常的。

2. 異常哪裡去了

按往常的套路,我都會推薦procdump這款工具讓朋友再抓一下,在重抓之前先看看可還有其他線索,可以用 !t 看看托管線程上是否掛了異常。


0:000> !t
ThreadCount:      76
UnstartedThread:  0
BackgroundThread: 69
PendingThread:    0
DeadThread:       6
Hosted Runtime:   no
                                                                                                        Lock  
       ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
   0    1 26c4 0000003f770bda90    26020 Preemptive  0000000000000000:0000000000000000 0000003f77093490 0     STA 
   ...
  74   77 c544 0000003f1a08c470    21220 Preemptive  0000000000000000:0000000000000000 0000003f77093490 0     Ukn System.ExecutionEngineException 0000003f000011f8
  75   78 18a88 0000003f1a329ae0  8029220 Preemptive  0000000000000000:0000000000000000 0000003f77093490 0     MTA (Threadpool Completion Port) 

從卦中可以看到有一個線程拋了 System.ExecutionEngineException 異常,這是一個災難性的情況,表示 CLR 在執行自身代碼的時候崩掉了,驚訝之餘趕緊看看它的線程棧為什麼會崩。


0:074> k
 # Child-SP          RetAddr               Call Site
00 0000003f`1bafea90 00007ffa`fb0283aa     clr!WKS::gc_heap::background_mark_simple+0x36
01 0000003f`1bafeac0 00007ffa`fb028701     clr!WKS::gc_heap::revisit_written_page+0x2fe
02 0000003f`1bafeb50 00007ffa`fb01ffec     clr!WKS::gc_heap::revisit_written_pages+0x251
03 0000003f`1bafec10 00007ffa`facefd01     clr!WKS::gc_heap::background_mark_phase+0x298
04 0000003f`1bafeca0 00007ffa`fb021fe5     clr!WKS::gc_heap::gc1+0xc0
05 0000003f`1bafed10 00007ffa`fab33e1e     clr!WKS::gc_heap::bgc_thread_function+0x169
06 0000003f`1bafed50 00007ffb`0dc716ad     clr!Thread::intermediateThreadProc+0x7d
07 0000003f`1baff810 00007ffb`0f924629     kernel32!BaseThreadInitThunk+0xd
08 0000003f`1baff840 00000000`00000000     ntdll!RtlUserThreadStart+0x1d

0:074> r
rax=000000001f808000 rbx=0000003f1bafe870 rcx=0000003efac80140
rdx=0000003f01000000 rsi=0000000000000000 rdi=0000003f1bafe380
rip=00007ffafb020c06 rsp=0000003f1bafea90 rbp=0000003f01c63270
 r8=0000000000000000  r9=0000003f01c64000 r10=0000003f04271000
r11=0000000000000001 r12=00007ffa9bca83c0 r13=0000003f01c632a8
r14=ffffffffffffffff r15=0000003f01c63000
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_simple+0x36:
00007ffa`fb020c06 41f70000000080  test    dword ptr [r8],80000000h ds:00000000`00000000=????????

從卦中信息看,當前是一個 bgc 線程,在後臺標記對象的時候踩到了0區導致的崩潰,經驗告訴我,是不是此時的托管堆損壞了? 可以用 !verifyheap 驗證下。


0:000> !verifyheap 
No heap corruption detected.

從卦中信息看,當前托管堆並沒有損壞,作為一個經常為sos輸出坑過的人,現在我是不相信這個輸出的,所以我要找一下這個 r8 對象到底是什麼對象,接下來反彙編下 background_mark_simple 方法。


0:074> ub 00007ffa`fb020c06
clr!WKS::gc_heap::background_mark_simple+0x1a:
00007ffa`fb020bea 0941d3          or      dword ptr [rcx-2Dh],eax
00007ffa`fb020bed e048            loopne  clr!WKS::gc_heap::background_mark_simple+0x67 (00007ffa`fb020c37)
00007ffa`fb020bef 8b0dd3253c00    mov     ecx,dword ptr [clr!WKS::gc_heap::mark_array (00007ffa`fb3e31c8)]
00007ffa`fb020bf5 44850481        test    dword ptr [rcx+rax*4],r8d
00007ffa`fb020bf9 7548            jne     clr!WKS::gc_heap::background_mark_simple+0x73 (00007ffa`fb020c43)
00007ffa`fb020bfb 44090481        or      dword ptr [rcx+rax*4],r8d
00007ffa`fb020bff 4c8b02          mov     r8,qword ptr [rdx]
00007ffa`fb020c02 4983e0fe        and     r8,0FFFFFFFFFFFFFFFEh

0:074> r rdx
rdx=0000003f01000000

0:074> !lno rdx
Before:  0000003f00ffff38          512 (0x200)	xxx.xxx
After:   0000003f01000138           32 (0x20)	System.String
Heap local consistency confirmed.

0:074> ? 0000003f01000000 - 0000003f00ffff38
Evaluate expression: 200 = 00000000`000000c8


0:074> !do 0000003f00ffff38
Name:        xxx.xxx
MethodTable: 00007ffa9c0ac278
EEClass:     00007ffa9c095b20
Size:        512(0x200) bytes
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
...
00007ffaf9d1da88  40012e6       c8        System.String  0 instance 0000000000000000 <OPPORTUNITY>k__BackingField
...

經過我上面的一頓分析,原來bgc標記的對象是 <OPPORTUNITY>k__BackingField 欄位,同時也驗證了確實托管堆沒有損壞,接下來的問題是為什麼BGC在mark這個欄位的時候拋出來了異常呢?

3. 繼續尋找真相

找不到突破口那就只能從線程棧上去挖,熟悉 bgc 後臺標記的朋友應該知道,後臺標記會分成三個階段。

  • 初始標記階段
  • 併發標記階段
  • 最終標記階段

截一張我在 .NET高級調試訓練營 PPT里的圖。

接下來的問題是這個程式目前處於哪一個階段呢?根據線程棧上的 revisit_written_pages 方法,很顯然是處於第二階段,在第二階段中為了能夠識別對象修改的情況,CLR 使用了 Win32 的GetWriteWatch函數對記憶體頁進行監控,監控到的臟記憶體頁會在第三階段做最後的清洗。

說了這麼多,有沒有源碼支撐呢?這裡我們簡單看一下 coreclr 的源代碼即可。


void gc_heap::revisit_written_pages(BOOL concurrent_p, BOOL reset_only_p)
{
    get_write_watch_for_gc_heap(reset_watch_state, base_address, region_size,
                             (void**)background_written_addresses,
                             &bcount, is_runtime_suspended);
}

// static
void gc_heap::get_write_watch_for_gc_heap(bool reset, void * base_address, size_t region_size,
                                          void * *dirty_pages, uintptr_t * dirty_page_count_ref,
                                          bool is_runtime_suspended)
{

    bool success = GCToOSInterface::GetWriteWatch(reset, base_address, region_size, dirty_pages,
    dirty_page_count_ref);
}

bool GCToOSInterface::GetWriteWatch(bool resetState, void * address, size_t size, void * *pageAddresses, uintptr_t * pageAddressesCount)
{
    uint32_t flags = resetState ? 1 : 0;
    ULONG granularity;

    bool success = ::GetWriteWatch(flags, address, size, pageAddresses, (ULONG_PTR*)pageAddressesCount, &granularity) == 0;
    if (success)
    {
        assert(granularity == OS_PAGE_SIZE);
    }

    return success;
}

給了這麼多的代碼,主要是想說 bgc的併發標記利用了 Windows 提供的功能,結合朋友說的只有兩台機器會出現這種情況,到這裡大概可以給出兩種方案:

  1. 更新Windows補丁,升級framework,大概率是兩者的相容性問題,導致記憶體頁監控上出了問題。

  2. 修改配置文件禁用 bgc,這樣就不會走這些邏輯,從根子上繞過這個問題。

三:總結

說實話在我的dump分析旅程中,這個dump的分析難度還是比較大的,它考驗著你對bgc線程底層運作的理解,所幸的是我在調試訓練營里用windbg讓大家親眼目睹了後臺標記三階段的詳細過程,真是三生有幸!
圖片名稱


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 拓展閱讀 馬斯克開源的 grok-1 底層 Transformer 模型論文 《Attention is All You Need》 馬斯克開源的 grok-1 大模型底層 Transformer 模型到底是個啥? 馬斯克開源的 grok-1 大模型硬核源碼第 1 彈 馬斯克開源的 grok-1 大 ...
  • 前言 還有個迭代器,基礎語法基本已經說完了,後面想到啥再補充,之後的教程會從以下方面來講: 基礎庫的使用,比如string、table等 基礎控制項的使用,比如listview、tab等 aardio和Python交互,比如給Python寫個界面 自帶的範常式序 我寫的一些小程式 當然,我的理解也是很 ...
  • 完美收官,本文是爬蟲實戰的最後一章了,所以儘管本文著重呈現爬蟲實戰,但其中有一大部分內容專註於數據分析。爬蟲只是整個過程的起點,其主要目的之一就是為後續數據分析等工作做好準備。通過對爬取的數據進行精確的清洗和分析,可以揭示其中隱藏的規律和趨勢,為決策提供有力支持。因此,爬蟲實戰並不僅僅是技術的展示,... ...
  • 前言 去年又重新刷了路遙的《平凡的世界》,最近也在朋友推薦下,來看了路遙的另一部成名作《人生》。 故事中的主人公高加林,雖生在農村,面朝黃土背朝天,卻不甘心像父輩一樣或者,一心想著擺脫民語的束縛,追求他的理想生活。 然而命運多舛,在他所想象的理想生活中,一次次跌倒,最終不得不承認自己的平凡,生活總得 ...
  • 1 定義 一個數據集是分散式的數據集合。Spark 1.6增加新介面Dataset,提供 RDD的優點:強類型、能夠使用強大lambda函數 Spark SQL優化執行引擎的優點 可從JVM對象構造Dataset,然後函數式轉換(map、flatMap、filter等)操作。Dataset API在 ...
  • 一、前言 隨著網路的發展,企業對於信息系統數據的保密工作愈發重視,不同身份、角色對於數據的訪問許可權都應該大相徑庭。 列如 1、不同登錄人員對一個數據列表的可見度是不一樣的,如數據列、數據行、數據按鈕等都可能不太一樣。 2、表單的靈活設計及呈現。 3、流程的靈活設計及呈現。 4、介面的調用信息者及性能 ...
  • 概述:WPF支持綁定到對象的屬性而不是欄位,主要因為屬性提供了更多控制和擴展性。屬性包含get和set方法,支持數據驗證和通知屬性更改,而欄位通常被認為是內部實現。使用屬性使WPF能夠更靈活、可控地與數據交互,提高代碼的可讀性和可維護性。 WPF(Windows Presentation Found ...
  • 概述:上述C#示例演示瞭如何在同步方法中調用非同步方法。通過使用`async`和`await`關鍵字,實現了同步方法對非同步方法的調用。建議使用`await`而不是`Result`來避免潛在的死鎖問題。這種模式在處理非同步任務時能夠提高代碼的可讀性和性能。 在C#中,從同步方法調用非同步方法的過程涉及到使用 ...
一周排行
    -Advertisement-
    Play Games
  • PasteSpider是什麼? 一款使用.net編寫的開源的Linux容器部署助手,支持一鍵發佈,平滑升級,自動伸縮, Key-Value配置,項目網關,環境隔離,運行報表,差量升級,私有倉庫,集群部署,版本管理等! 30分鐘上手,讓開發也可以很容易的學會在linux上部署你得項目! [從需求角度介 ...
  • SQLSugar是什麼 **1. 輕量級ORM框架,專為.NET CORE開發人員設計,它提供了簡單、高效的方式來處理資料庫操作,使開發人員能夠更輕鬆地與資料庫進行交互 2. 簡化資料庫操作和數據訪問,允許開發人員在C#代碼中直接操作資料庫,而不需要編寫複雜的SQL語句 3. 支持多種資料庫,包括但 ...
  • 在C#中,經常會有一些耗時較長的CPU密集型運算,因為如果直接在UI線程執行這樣的運算就會出現UI不響應的問題。解決這類問題的主要途徑是使用多線程,啟動一個後臺線程,把運算操作放在這個後臺線程中完成。但是原生介面的線程操作有一些難度,如果要更進一步的去完成線程間的通訊就會難上加難。 因此,.NET類 ...
  • 一:背景 1. 講故事 前些天有位朋友在微信上丟了一個崩潰的dump給我,讓我幫忙看下為什麼出現了崩潰,在 Windows 的事件查看器上顯示的是經典的 訪問違例 ,即 c0000005 錯誤碼,不管怎麼說有dump就可以上windbg開幹了。 二:WinDbg 分析 1. 程式為誰崩潰了 在 Wi ...
  • CSharpe中的IO+NPOI+序列化 文件文件夾操作 學習一下常見的文件、文件夾的操作。 什麼是IO流? I:就是input O:就是output,故稱:輸入輸出流 將數據讀入記憶體或者記憶體輸出的過程。 常見的IO流操作,一般說的是[記憶體]與[磁碟]之間的輸入輸出。 作用 持久化數據,保證數據不再 ...
  • C#.NET與JAVA互通之MD5哈希V2024 配套視頻: 要點: 1.計算MD5時,SDK自帶的計算哈希(ComputeHash)方法,輸入輸出參數都是byte數組。就涉及到字元串轉byte數組轉換時,編碼選擇的問題。 2.輸入參數,字元串轉byte數組時,編碼雙方要統一,一般為:UTF-8。 ...
  • CodeWF.EventBus,一款靈活的事件匯流排庫,實現模塊間解耦通信。支持多種.NET項目類型,如WPF、WinForms、ASP.NET Core等。採用簡潔設計,輕鬆實現事件的發佈與訂閱。通過有序的消息處理,確保事件得到妥善處理。簡化您的代碼,提升系統可維護性。 ...
  • 一、基本的.NET框架概念 .NET框架是一個由微軟開發的軟體開發平臺,它提供了一個運行時環境(CLR - Common Language Runtime)和一套豐富的類庫(FCL - Framework Class Library)。CLR負責管理代碼的執行,而FCL則提供了大量預先編寫好的代碼, ...
  • 本章將和大家分享在ASP.NET Core中如何使用高級客戶端NEST來操作我們的Elasticsearch。 NEST是一個高級別的Elasticsearch .NET客戶端,它仍然非常接近原始Elasticsearch API的映射。所有的請求和響應都是通過類型來暴露的,這使得它非常適合快速上手 ...
  • 參考delphi的代碼更改為C# Delphi 檢測密碼強度 規則(仿 google) 仿 google 評分規則 一、密碼長度: 5 分: 小於等於 4 個字元 10 分: 5 到 7 字元 25 分: 大於等於 8 個字元 二、字母: 0 分: 沒有字母 10 分: 全都是小(大)寫字母 20 ...