主頁 > .NET開發 > 記一次 .NET 某新能源汽車鋰電池檢測程式 UI掛死分析

記一次 .NET 某新能源汽車鋰電池檢測程式 UI掛死分析

2021-09-09 14:45:18 .NET開發

更多高質量干貨:參見我的 GitHub: dotnetfly

一:背景

1. 講故事

這世間事說來也奇怪,近兩個月有三位朋友找到我,讓我幫忙分析下他的程式hangon現象,這三個dump分別涉及: 醫療,新能源,POS系統,截圖如下:



那這篇為什么要拿其中的 新能源 說事呢? 因為這位朋友解決的最順利,在提供的一些線索后比較順利的找出了問題代碼,

說點題外話,我本人對 winform 是不熟的,又奈何它三番五次的出現在我的視野里,所以我決定寫一篇文章好好的總結下,介于沒有太多的參考資料,能力有限,只能自己試著解讀,

二: Windbg 分析

1. 程式現象

開始之前先吐槽一下,這幾位大佬抓的dump檔案都是 wow64,也就是用64bit任務管理器抓了32bit的程式,見如下輸出:


wow64cpu!CpupSyscallStub+0x9:
00000000`756d2e09 c3              ret

所以就不好用 windbg preview 來分析了,首先要用 !wow64exts.sw 將 64bit 轉為 32bit ,本篇用的是 windbg10,好了,既然是UI卡死,首當其沖就是要看一下UI執行緒到底被什么東西卡住了,可以用命令 !clrstack 看一下,


0:000:x86> !clrstack 
OS Thread Id: 0x1d90 (0)
Child SP       IP Call Site
0019ee6c 0000002b [HelperMethodFrame_1OBJ: 0019ee6c] System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
0019ef50 6c4fc7c1 System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)
0019ef68 6c4fc788 System.Threading.WaitHandle.WaitOne(Int32, Boolean)
0019ef7c 6e094e7e System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle)
0019efbc 6e463b96 System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control, System.Delegate, System.Object[], Boolean)
0019efc0 6e09722b [InlinedCallFrame: 0019efc0] 
0019f044 6e09722b System.Windows.Forms.Control.Invoke(System.Delegate, System.Object[])
0019f078 6e318556 System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback, System.Object)
0019f090 6eef65a8 Microsoft.Win32.SystemEvents+SystemEventInvokeInfo.Invoke(Boolean, System.Object[])
0019f0c4 6eff850c Microsoft.Win32.SystemEvents.RaiseEvent(Boolean, System.Object, System.Object[])
0019f110 6eddb134 Microsoft.Win32.SystemEvents.OnUserPreferenceChanged(Int32, IntPtr, IntPtr)
0019f130 6f01f0b0 Microsoft.Win32.SystemEvents.WindowProc(IntPtr, Int32, IntPtr, IntPtr)
0019f134 001cd246 [InlinedCallFrame: 0019f134] 
0019f2e4 001cd246 [InlinedCallFrame: 0019f2e4] 
0019f2e0 6dbaefdc DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef)
0019f2e4 6db5e039 [InlinedCallFrame: 0019f2e4] System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
0019f318 6db5e039 System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
0019f31c 6db5dc49 [InlinedCallFrame: 0019f31c] 
0019f3a4 6db5dc49 System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
0019f3f4 6db5dac0 System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
0019f420 6db4a7b1 System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
0019f434 003504a3 xxx.Program.Main()
0019f5a8 6f191366 [GCFrame: 0019f5a8] 

從呼叫堆疊上看,代碼是由于 Microsoft.Win32.SystemEvents.OnUserPreferenceChanged 被觸發,然后在 System.Windows.Forms.Control.WaitForWaitHandle處被卡死,從前者的名字上就能看到,OnUserPreferenceChanged(用戶首選項) 是一個系統級別的 Microsoft.Win32.SystemEvents 事件,那到底是什么導致了這個系統事件被觸發,為此我查了下資料,大概是說:如果應用程式的 Control 注冊了這些系統級事件,那么當windows發出 WM_SYSCOLORCHANGE, WM_DISPLAYCHANGED, WM_THEMECHANGED(主題,首選項,界面顯示) 訊息時,這些注冊了系統級事件的 Control 的handle將會被執行,比如重繪自身,

覺得文字比較拗口的話,我試著畫一張圖來闡明一下,

從本質上來說,它就是一個觀察者模式,但這和UI卡死沒有半點關系,充其量就是解決問題前需要了解的背景知識,還有一個重要概念沒有說,那就是: WindowsFormsSynchronizationContext

2. 理解 WindowsFormsSynchronizationContext

為什么一定要了解 WindowsFormsSynchronizationContext 呢?理解了它,你就搞明白了為什么會卡死,我們知道 winform 的UI執行緒是一個 STA 模型,它的一個特點就是單執行緒,其他執行緒想要更新Control,都需要調度到UI執行緒的Queue佇列中,不存在也不允許并發更新Control的情況,參考如下:


0:000:x86> !t
ThreadCount:      207
UnstartedThread:  0
BackgroundThread: 206
PendingThread:    0
DeadThread:       0
Hosted Runtime:   no
                                                                         Lock  
       ID OSID ThreadOBJ    State GC Mode     GC Alloc Context  Domain   Count Apt Exception
   0    1 1d90 003e2430   2026020 Preemptive  00000000:00000000 003db8b8 0     STA 
   2    2 2804 003f0188     2b220 Preemptive  00000000:00000000 003db8b8 0     MTA (Finalizer) 

Winform 還有一個特點:它會給那些創建 Control 的執行緒配一個 WindowsFormsSynchronizationContext 同步背景關系,也就是說如果其他執行緒想要更新那個 Control,那就必須將更新的值通過 WindowsFormsSynchronizationContext 調度到那個創建它的執行緒上,這里的執行緒不僅僅是 UI 執行緒哦,有了這些基礎知識后,再來分析下為什么會被卡死,

3. 卡死的真正原因

再重新看下主執行緒的呼叫堆疊,它的走勢是這樣的: OnUserPreferenceChanged -> WindowsFormsSynchronizationContext.Send -> Control.MarshaledInvoke -> WaitHandle.WaitOneNative ,哈哈,有看出什么問題嗎???

眼尖的朋友會發現,為什么主執行緒會呼叫 WindowsFormsSynchronizationContext.Send 方法呢? 難道那個注冊 handler的 Control 不是由主執行緒創建的嗎?要想回答這個問題,需要看一下 WindowsFormsSynchronizationContext 類的 destinationThreadRef 欄位值,原始碼如下:


public sealed class WindowsFormsSynchronizationContext : SynchronizationContext, IDisposable
{
    private Control controlToSendTo;

    private WeakReference destinationThreadRef;
}

可以用 !dso 命令把執行緒堆疊上的 WindowsFormsSynchronizationContext 給找出來,簡化輸出如下:


0:000:x86> !dso
OS Thread Id: 0x1d90 (0)
ESP/REG  Object   Name
0019ED70 027e441c System.Windows.Forms.WindowsFormsSynchronizationContext
0019EDC8 112ee43c Microsoft.Win32.SafeHandles.SafeWaitHandle
0019F078 11098b74 System.Windows.Forms.WindowsFormsSynchronizationContext
0019F080 1107487c Microsoft.Win32.SystemEvents+SystemEventInvokeInfo
0019F08C 10fa386c System.Object[]    (System.Object[])
0019F090 1107487c Microsoft.Win32.SystemEvents+SystemEventInvokeInfo
0019F0AC 027ebf60 System.Object
0019F0C0 10fa386c System.Object[]    (System.Object[])
0019F0C8 027ebe3c System.Object
0019F0CC 10fa388c Microsoft.Win32.SystemEvents+SystemEventInvokeInfo[]
...

0:000:x86> !do 11098b74
Name:        System.Windows.Forms.WindowsFormsSynchronizationContext
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
6dbd8f30  4002567        8 ...ows.Forms.Control  0 instance 11098c24 controlToSendTo
6c667c2c  4002568        c System.WeakReference  0 instance 11098b88 destinationThreadRef

0:000:x86> !do 11098b88
Name:        System.WeakReference
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
6c66938c  4000705        4        System.IntPtr  1 instance  86e426c m_handle

0:000:x86> !do poi(86e426c)
Name:        System.Threading.Thread
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
6c663cc4  40018a5       24         System.Int32  1 instance        2 m_Priority
6c663cc4  40018a6       28         System.Int32  1 instance        7 m_ManagedThreadId
6c66f3d8  40018a7       2c       System.Boolean  1 instance        1 m_ExecutionContextBelongsToOuterScope

果然不出所料, 從卦象上看 Thread=7 執行緒上有 Control 注冊了系統事件,那 Thread=7 到底是什么執行緒呢? 可以通過 !t 查看,


0:028:x86> !t
ThreadCount:      207
UnstartedThread:  0
BackgroundThread: 206
PendingThread:    0
DeadThread:       0
Hosted Runtime:   no
                                                                         Lock  
       ID OSID ThreadOBJ    State GC Mode     GC Alloc Context  Domain   Count Apt Exception
   0    1 1d90 003e2430   2026020 Preemptive  00000000:00000000 003db8b8 0     STA 
   2    2 2804 003f0188     2b220 Preemptive  00000000:00000000 003db8b8 0     MTA (Finalizer) 
  28    7 27f0 0b29cd30   3029220 Preemptive  00000000:00000000 003db8b8 0     MTA (Threadpool Worker) 

從卦象上看: ID=7 是一個執行緒池執行緒,而且是 MTA 模式,按理說它應該將創建控制元件的邏輯調度給UI執行緒,而不是自己創建,所以UI執行緒一直在 WaitOneNative 處等待 7號執行緒訊息泵回應,所以導致了無限期等待,

4. 7號執行緒到底創建了什么控制元件

這又是一個考驗底層知識的問題,也困擾著我至今,太難了,我曾今嘗試著把 UserPreferenceChangedEventHandler 事件上的所有 handles 撈出來,寫了一個腳本大概如下:


"use strict";

// 32bit
let arr = ["xxxx"];

function initializeScript() { return [new host.apiVersionSupport(1, 7)]; }
function log(str) { host.diagnostics.debugLog(str + "\n"); }
function exec(str) { return host.namespace.Debugger.Utility.Control.ExecuteCommand(str); }

function invokeScript() {

    for (var address of arr) {
        var commandText = ".printf \"%04x\", poi(poi(poi(poi(" + address + "+0x4)+0xc)+0x4))";
        var output = exec(commandText).First();

        if (parseInt(output) == 0) continue; //not exists thread info

        commandText = ".printf \"%04x\", poi(poi(poi(poi(poi(" + address + "+0x4)+0xc)+0x4))+0x28)";
        output = exec(commandText).First();

        //thread id
        var tid = parseInt(output);

        if (tid > 1) log("Thread=" + tid + ",systemEventInvokeInfo=" + address);
    }
}

輸出結果:


||2:2:438>     !wow64exts.sw
Switched to Guest (WoW) mode
Thread=7,systemEventInvokeInfo=1107487c

從輸出中找到了 7號執行緒 對應的處理事件 systemEventInvokeInfo ,然后對其追查如下:


0:028:x86> !do 1107487c
Name:        Microsoft.Win32.SystemEvents+SystemEventInvokeInfo
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
6c65ae34  4002e9f        4 ...ronizationContext  0 instance 11098b74 _syncContext
6c6635ac  4002ea0        8      System.Delegate  0 instance 1107485c _delegate

0:028:x86> !DumpObj /d 1107485c
Name:        Microsoft.Win32.UserPreferenceChangedEventHandler
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
6c66211c  40002b0        4        System.Object  0 instance 110747bc _target
6c66211c  40002b1        8        System.Object  0 instance 00000000 _methodBase
6c66938c  40002b2        c        System.IntPtr  1 instance  6ebdc00 _methodPtr
6c66938c  40002b3       10        System.IntPtr  1 instance        0 _methodPtrAux
6c66211c  40002bd       14        System.Object  0 instance 00000000 _invocationList
6c66938c  40002be       18        System.IntPtr  1 instance        0 _invocationCount

0:028:x86> !DumpObj /d 110747bc
Name:        DevExpress.LookAndFeel.Design.UserLookAndFeelDefault

從輸出中可以看到,最后的控制元件是 DevExpress.LookAndFeel.Design.UserLookAndFeelDefault ,我以為找到了答案,拿著這個結果去 google,結果 devExpress 踢皮球,截圖如下:

咳,到這里貌似就查不下去了,有其他資料上說 Control 在跨執行緒注冊 handler 時會經過 MarshalingControl ,所以在這個控制元件設定bp斷點是能夠抓到的,參考命令如下:


bp xxx ".echo MarshalingControl creation detected. Callstack follows.;!clrstack;.echo

這里我就沒法驗證了,

三:總結

雖然知道這三起事故都是由于非UI執行緒創建Control所致,但很遺憾的是我盡了最大的知識邊界還沒有找到最重要的罪魁禍首,不過值得開心的是基于現有線索有一位朋友終于找到了問題代碼,真替他開心??????,解決辦法也很簡單,將 創建控制元件 通過 Invoke 調度到 UI執行緒 執行,截圖如下:

通過這個案例,我發現高級除錯真的是一場苦行之旅,且調且珍惜!

圖片名稱

轉載請註明出處,本文鏈接:https://www.uj5u.com/net/298772.html

標籤:.NET技术

上一篇:WPF 水印裝飾器

下一篇:WPF 水印裝飾器

標籤雲
其他(123570) Java(13369) Python(12731) C(7545) 區塊鏈(7372) JavaScript(7059) 基礎類(6313) AI(6244) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4120) MySQL(4012) Linux(3394) C語言(3288) C++語言(3117) Java相關(2746) 疑難問題(2699) 單片機工控(2479) Web開發(1951) 網絡通信(1793) 數據庫相關(1767) VB基礎類(1755) PHP(1727) 開發(1646) 系統維護與使用區(1617) .NETCore(1586) 基礎和管理(1579) JavaEE(1566) C++(1527) 專題技術討論區(1515) Windows客戶端使用(1484) HtmlCss(1466) ASP.NET(1428) Unity3D(1354) VCL組件開發及應用(1353) HTML(CSS)(1220) 其他技術討論專區(1200) WindowsServer(1192) .NET技术(1165) 交換及路由技術(1149) 語言基礎算法系統設計(1133) WindowsSDKAPI(1124) 界面(1088) JavaSE(1075) Qt(1074) VBA(1048) 新手樂園(1016) 其他開發語言(947) Go(907) HTML5(901) 新技術前沿(898) 硬件設計(872) 區塊鏈技術(860) 網絡編程(857) 非技術版(846) 一般軟件使用(839) 網絡協議與配置(835) Eclipse(790) Spark(750) 下載資源懸賞專區(743)

熱門瀏覽
  • WebAPI簡介

    Web體系結構: 有三個核心:資源(resource),URL(統一資源識別符號)和表示 他們的關系是這樣的:一個資源由一個URL進行標識,HTTP客戶端使用URL定位資源,表示是從資源回傳資料,媒體型別是資源回傳的資料格式。 接下來我們說下HTTP. HTTP協議的系統是一種無狀態的方式,使用請求/ ......

    uj5u.com 2020-09-09 22:07:47 more
  • asp.net core 3.1 入口:Program.cs中的Main函式

    本文分析Program.cs 中Main()函式中代碼的運行順序分析asp.net core程式的啟動,重點不是剖析原始碼,而是理清程式開始時執行的順序。到呼叫了哪些實體,哪些法方。asp.net core 3.1 的程式入口在專案Program.cs檔案里,如下。ususing System; us ......

    uj5u.com 2020-09-09 22:07:49 more
  • asp.net網站作為websocket服務端的應用該如何寫

    最近被websocket的一個問題困擾了很久,有一個需求是在web網站中搭建websocket服務。客戶端通過網頁與服務器建立連接,然后服務器根據ip給客戶端網頁發送資訊。 其實,這個需求并不難,只是剛開始對websocket的內容不太了解。上網搜索了一下,有通過asp.net core 實作的、有 ......

    uj5u.com 2020-09-09 22:08:02 more
  • ASP.NET 開源匯入匯出庫Magicodes.IE Docker中使用

    Magicodes.IE在Docker中使用 更新歷史 2019.02.13 【Nuget】版本更新到2.0.2 【匯入】修復單列匯入的Bug,單元測驗“OneColumnImporter_Test”。問題見(https://github.com/dotnetcore/Magicodes.IE/is ......

    uj5u.com 2020-09-09 22:08:05 more
  • 在webform中使用ajax

    如果你用過Asp.net webform, 說明你也算是.NET 開發的老兵了。WEBform應該是2011 2013左右,當時還用visual studio 2005、 visual studio 2008。后來基本都用的是MVC。 如果是新開發的專案,估計沒人會用webform技術。但是有些舊版 ......

    uj5u.com 2020-09-09 22:08:50 more
  • iis添加asp.net網站,訪問提示:由于擴展配置問題而無法提供您請求的

    今天在iis服務器配置asp.net網站,遇到一個問題,記錄一下: 問題:由于擴展配置問題而無法提供您請求的頁面。如果該頁面是腳本,請添加處理程式。如果應下載檔案,請添加 MIME 映射。 WindowServer2012服務器,添加角色安裝完.netframework和iis之后,運行aspx頁面 ......

    uj5u.com 2020-09-09 22:10:00 more
  • WebAPI-處理架構

    帶著問題去思考,大家好! 問題1:HTTP請求和回傳相應的HTTP回應資訊之間發生了什么? 1:首先是最底層,托管層,位于WebAPI和底層HTTP堆疊之間 2:其次是 訊息處理程式管道層,這里比如日志和快取。OWIN的參考是將訊息處理程式管道的一些功能下移到堆疊下端的OWIN中間件了。 3:控制器處理 ......

    uj5u.com 2020-09-09 22:11:13 more
  • 微信門戶開發框架-使用指導說明書

    微信門戶應用管理系統,采用基于 MVC + Bootstrap + Ajax + Enterprise Library的技術路線,界面層采用Boostrap + Metronic組合的前端框架,資料訪問層支持Oracle、SQLServer、MySQL、PostgreSQL等資料庫。框架以MVC5,... ......

    uj5u.com 2020-09-09 22:15:18 more
  • WebAPI-HTTP編程模型

    帶著問題去思考,大家好!它是什么?它包含什么?它能干什么? 訊息 HTTP編程模型的核心就是訊息抽象,表示為:HttPRequestMessage,HttpResponseMessage.用于客戶端和服務端之間交換請求和回應訊息。 HttpMethod類包含了一組靜態屬性: private stat ......

    uj5u.com 2020-09-09 22:15:23 more
  • 部署WebApi隨筆

    一、跨域 NuGet參考Microsoft.AspNet.WebApi.Cors WebApiConfig.cs中配置: // Web API 配置和服務 config.EnableCors(new EnableCorsAttribute("*", "*", "*")); 二、清除默認回傳XML格式 ......

    uj5u.com 2020-09-09 22:15:48 more
最新发布