一：背景 1. 讲故事 这世间事说来也奇怪，近两个月有三位朋友找到我，让我帮忙分析下他的程序hangon现象，这三个dump分别涉及： 医疗，新能源，POS系统。截图如下： 那这篇为什么要
一：背景1. 讲故事这世间事说来也奇怪，近两个月有三位朋友找到我，让我帮忙分析下他的程序hangon现象，这三个dump分别涉及： 医疗，新能源，POS系统。截图如下：
那这篇为什么要拿其中的 新能源 说事呢？ 因为这位朋友解决的最顺利，在提供的一些线索后比较顺利的找出了问题代码。 说点题外话，我本人对 winform 是不熟的，又奈何它三番五次的出现在我的视野里，所以我决定写一篇文章好好的总结下，介于没有太多的参考资料，能力有限，只能自己试着解读。 二： Windbg 分析1. 程序现象开始之前先吐槽一下，这几位大佬抓的dump文件都是 wow64，也就是用64bit任务管理器抓了32bit的程序，见如下输出：
所以就不好用 windbg preview 来分析了，首先要用 !wow64exts.sw 将 64bit 转为 32bit ，本篇用的是 windbg10，好了，既然是UI卡死，首当其冲就是要看一下UI线程到底被什么东西卡住了，可以用命令 !clrstack 看一下。
从调用栈上看，代码是由于 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的情况，参考如下：
Winform 还有一个特点：它会给那些创建 Control 的线程配一个 WindowsFormsSynchronizationContext 同步上下文，也就是说如果其他线程想要更新那个 Control，那就必须将更新的值通过 WindowsFormsSynchronizationContext 调度到那个创建它的线程上，这里的线程不仅仅是 UI 线程哦，有了这些基础知识后，再来分析下为什么会被卡死。 3. 卡死的真正原因再重新看下主线程的调用栈，它的走势是这样的： OnUserPreferenceChanged -> WindowsFormsSynchronizationContext.Send -> Control.MarshaledInvoke -> WaitHandle.WaitOneNative，哈哈，有看出什么问题吗？？？ 眼尖的朋友会发现，为什么主线程会调用 WindowsFormsSynchronizationContext.Send 方法呢？ 难道那个注册 handler的 Control 不是由主线程创建的吗？要想回答这个问题，需要看一下 WindowsFormsSynchronizationContext 类的 destinationThreadRef 字段值，源码如下：
可以用 !dso 命令把线程栈上的 WindowsFormsSynchronizationContext 给找出来，简化输出如下：
果然不出所料, 从卦象上看 Thread=7 线程上有 Control 注册了系统事件，那 Thread=7 到底是什么线程呢？ 可以通过 !t 查看。
从卦象上看： ID=7 是一个线程池线程，而且是 MTA 模式，按理说它应该将创建控件的逻辑调度给UI线程，而不是自己创建，所以UI线程一直在 WaitOneNative 处等待 7号线程消息泵响应，所以导致了无限期等待。 4. 7号线程到底创建了什么控件这又是一个考验底层知识的问题，也困扰着我至今，太难了，我曾今尝试着把 UserPreferenceChangedEventHandler 事件上的所有 handles 捞出来，写了一个脚本大概如下：
输出结果：
从输出中找到了 7号线程 对应的处理事件 systemEventInvokeInfo ，然后对其追查如下：
从输出中可以看到，最后的控件是 DevExpress.LookAndFeel.Design.UserLookAndFeelDefault ，我以为找到了答案，拿着这个结果去 google，结果 devExpress 踢皮球，截图如下：
咳，到这里貌似就查不下去了，有其他资料上说 Control 在跨线程注册 handler 时会经过 MarshalingControl ，所以在这个控件设置bp断点是能够抓到的，参考命令如下：
这里我就没法验证了。 三：总结虽然知道这三起事故都是由于非UI线程创建Control所致，但很遗憾的是我尽了最大的知识边界还没有找到最重要的罪魁祸首，不过值得开心的是基于现有线索有一位朋友终于找到了问题代码，真替他开心????????????，解决办法也很简单，将 创建控件 通过 Invoke 调度到 UI线程 执行。截图如下：
通过这个案例，我发现高级调试真的是一场苦行之旅，且调且珍惜！ |
2019-09-10
2019-09-10
2019-10-03
2022-02-21
2022-05-10
