一個超經典WinForm，WPF卡死問題的終極反思
一、背景
1. 講故事
寫這篇文章起源于訓練營里一位朋友最近在微信聊到他對這個問題使用了一種非常切實可行，簡單粗暴的方式，并且也成功解決了公司里幾個這樣的卡死dump，如今在公司已是靈魂級人物，讓我也嘗到了什么叫反哺！對，這個東西叫 Harmony, github網址：https://github.com/pardeike/Harmony，一個非常牛逼的C#程序函數修改器。
二：卡死問題的回顧
1. 故障成因
為了方便講述，先把 WinForm/WPF 程序故障的調用堆棧給大家呈現一下。
0:000:x86> !clrstack
OS Thread Id: 0x4eb688 (0)
Child SP IP Call Site
002fed38 0000002b [HelperMethodFrame_1OBJ: 002fed38] System.Threading.WaitHandle.WaitOneNative(System.Runtime.InteropServices.SafeHandle, UInt32, Boolean, Boolean)
002fee1c 5cddad21 System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)
002fee34 5cddace8 System.Threading.WaitHandle.WaitOne(Int32, Boolean)
002fee48 538d876c System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle)
002fee88 53c5214a System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control, System.Delegate, System.Object[], Boolean)
002fee8c 538dab4b [InlinedCallFrame: 002fee8c]
002fef14 538dab4b System.Windows.Forms.Control.Invoke(System.Delegate, System.Object[])
002fef48 53b03bc6 System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback, System.Object)
002fef60 5c774708 Microsoft.Win32.SystemEvents+SystemEventInvokeInfo.Invoke(Boolean, System.Object[])
002fef94 5c6616ec Microsoft.Win32.SystemEvents.RaiseEvent(Boolean, System.Object, System.Object[])
002fefe8 5c660cd4 Microsoft.Win32.SystemEvents.OnUserPreferenceChanged(Int32, IntPtr, IntPtr)
002ff008 5c882c98 Microsoft.Win32.SystemEvents.WindowProc(IntPtr, Int32, IntPtr, IntPtr)
...這個程序之所以被卡死，底層原因到底大概是這樣的。
- 程序在t1時間，有非主線程創建了控件。
- 程序在t2時間，用戶主動或被動做了 遠程連接，Windows主題色刷新 等操作，這種系統級操作Windows需要同步刷新給所有UI控件。
- 那些非主線程控件由于沒有 MessageLoop 機制，導致主線程給這些UI發消息時得不到響應，最終引發悲劇。
t2時間的卡死是由于t1時間的錯誤創建導致，要想在dump中反向追溯目前是無法做到的，所以要想找到禍根需要監控t1，即MarshalingControl到底是誰創建的，為此我也寫過兩篇文章來仔細分析此事。
- (一個超經典 WinForm 卡死問題的再反思 )[https://www.cnblogs.com/huangxincheng/p/16868486.html]
- (一個超經典 WinForm 卡死問題的最后一次反思)[https://www.cnblogs.com/huangxincheng/p/17654394.html]
第一種方式是啟動 windbg 對 System_Windows_Forms_ni System.Windows.Forms.Application+MarshalingControl..ctor 進行攔截，說實話這種方式很多程序員搞不定，原因在于windbg的使用門檻較高，現實中很多程序員連CURD都沒摸明白，所以可想而知了。。。
第二種方式是啟動 perfview 對 winform/wpf 程序進行監控，直到程序出現卡死停止收集。最后在錄播中尋找 MarshalingControl..ctor 的調用棧，這種方式也有不可行的時候，如果說卡死發生在程序啟動的10天后，那這個錄播文件將會超級超級大，或者有更極端的情況發生。
所以這兩種方案都有各自的優缺點，現實可行性雖然有，但不高。。。今天作為終結篇，必須把這個問題安排掉，繼續提供兩種切實可行的方案。
三：兩種修改方案
1. 使用 Harmony 注入
Harmony作為一款運行時C#方法修改器，借助它我完全可以將一些邏輯注入到 MarshalingControl..ctor 中，比如記錄下初始化該方法的 堆棧信息 ，是不是就可以輕松找到這個非主線程控件到底是誰？對不對，有了思路，我們在 nuget 上引用 Lib.Harmony ，上代碼說話。
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
var harmony = new Harmony("一線碼農聊技術");
Type applicationType = typeof(Application);
Type marshalingControlType = applicationType.GetNestedType("MarshalingControl", BindingFlags.NonPublic);
ConstructorInfo constructor = marshalingControlType.GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, Type.EmptyTypes, null);
var prefix = typeof(HookMarshalingControl).GetMethod("OnActionExecuting");
harmony.Patch(constructor, new HarmonyMethod(prefix));
}
private void Form1_Load(object sender, EventArgs e)
{
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
Button btn = new Button();
var query = btn.Handle;
}
private void button1_Click(object sender, EventArgs e)
{
backgroundWorker1.RunWorkerAsync();
}
}
/// <summary>
/// Hook MarshalingControl 的描述類
/// </summary>
public class HookMarshalingControl
{
/// <summary>
/// 原生方法之前執行的 action
/// </summary>
public static void OnActionExecuting()
{
Console.WriteLine("----------------------------");
Console.WriteLine($"控件創建線程:{Thread.CurrentThread.ManagedThreadId}");
Console.WriteLine(Environment.StackTrace);
Console.WriteLine("----------------------------");
}
}卦中的代碼邏輯我就不詳述了，核心就是將 OnActionExecuting 方法注入到 MarshalingControl..ctor 構造函數里，把程序運行起來后觀察 output 窗口，截圖如下：
圖片
終于是一個臥槽，禍根居然是一個 tid=3 的線程初始化了 new Button() 控件。。。
2. 使用 DnSpy
Harmony 作為一款修改器，它對程序的侵入性是非常高的，目前還是有一些bug，比如對 .NET7 的支持還不是很好，但相對 perfview 和 windbg 的方式已經非常輕量級了，極大的降低了使用門檻。
問題來了，那有沒有一種對程序無侵入，可行性超高的方式呢？當然是有的，dnspy 此時可以閃亮登場，用過 dnspy 的朋友應該知道它是一款輕量級，免安裝綠色的調試器，當然除了調試器功能，它還是一款程序集修改器，可以實現 Harmony 的所有功能，在實踐中我們可以將 dnspy copy 到客戶機使用 啟動調試 或者 附加進程 的方式對程序進行干預。
如何使用 dnspy 對 MarshalingControl..ctor 進行干預呢？可以使用 斷點日志 的功能，日志信息如下：
控件創建線程：{Environment.CurrentManagedThreadId} \n $CALLSTACK
圖片
有些人可能要問了 $CALLSTACK 是什么東西？很顯然是堆棧信息，除了這個關鍵詞還有很多，具體可以看后面的 問號面板。
圖片
接下來把程序跑起來，觀察 output面板。
圖片
從面板中可以清楚的看到，原來有個 tid=3 的線程創建了一個 Button 控件，這就是我們要找的禍根。
到這里，可能有些人要說，dnspy 啟動 exe 的方式因為各種原因在我們這邊行不通，有沒有其他的方式呢？當然是有的，我們還可以在程序啟動之后以 進程附加 的方式注入，同樣也是一種非常可行且低侵入的方式。
為了能夠更早的介入，可以在 Form1 初始化之前彈一個MessageBox，有更好的方式大家也可以說一下，感謝。參考代碼如下：
public partial class Form1 : Form
{
public Form1()
{
MessageBox.Show("開啟你的注入吧...");
InitializeComponent();
}
}彈框之后，使用 dnspy 的進程附加。
圖片
附加好了之后關閉彈框讓程序繼續運行，點擊 buttton 按鈕，可以看到 output 上的輸出。
11:20:01.548 控件創建線程：<<<當線程位于不安全狀態時無法對表達式進行求值。按步調試或運行直到觸發斷點。>>>
11:20:01.550 System.Windows.Forms.Application.MarshalingControl.MarshalingControl
11:20:01.551 System.Windows.Forms.Application.ThreadContext.MarshalingControl.get
11:20:01.552 System.Windows.Forms.WindowsFormsSynchronizationContext.WindowsFormsSynchronizationContext
11:20:01.553 System.Windows.Forms.WindowsFormsSynchronizationContext.InstallIfNeeded
11:20:01.553 System.Windows.Forms.Control.Control
11:20:01.554 System.Windows.Forms.ButtonBase.ButtonBase
11:20:01.554 System.Windows.Forms.Button.Button
11:20:01.554 WindowsFormsApp1.Form1.backgroundWorker1_DoWork
11:20:01.555 System.ComponentModel.BackgroundWorker.OnDoWork
11:20:01.555 System.ComponentModel.BackgroundWorker.WorkerThreadStart
11:20:01.556 System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage
11:20:01.556 System.Threading.ExecutionContext.RunInternal
11:20:01.557 System.Threading.ExecutionContext.Run
11:20:01.557 System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem
11:20:01.557 System.Threading.ThreadPoolWorkQueue.Dispatch
11:20:01.558 [本機到托管的轉換]
11:20:01.558這里稍微提醒一下，tid 在這里沒有顯示出來，大家可以換成問號面板上的關鍵詞 $TID 即可，不過TID不是最重要的，最重要的是調用棧給弄出來了。
四、總結
作為一名專業的 .NET高級調試師，在這個經典卡死的問題溯源上一直沒有提供非常好的解決方案，還是有些內疚的，在我的高級調試之旅中還是會不間斷的收到類似dump，相信這篇文章之后，不再有人被它所困擾！
