关键词:
一:背景
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线程 执行。截图如下:
通过这个案例,我发现高级调试真的是一场苦行之旅,且调且珍惜!
END
工作中的你,是否已遇到 ...
1. CPU爆高
2. 内存暴涨
3. 资源泄漏
4. 崩溃死锁
5. 程序呆滞
等紧急事件,全公司都指望着你能解决... 危难时刻才能展现你的技术价值,作为专注于.NET高级调试的技术博主,欢迎微信搜索: 一线码农聊技术,免费协助你分析Dump文件,希望我能将你的踩坑经验分享给更多的人。
记一次.net某纺织工厂mes系统api挂死分析(代码片段)
一:背景1.讲故事这个月中旬,有位朋友加我wx求助他的程序线程占有率很高,寻求如何解决,截图如下:说实话,和不同行业的程序员聊天还是蛮有意思的,广交朋友,也能扩大自己的圈子,... 查看详情
记一次.net某上市工业智造cpu+内存+挂死三高分析(代码片段)
一:背景1.讲故事上个月有位朋友加wx告知他的程序有挂死现象,询问如何进一步分析,截图如下:看这位朋友还是有一定的分析基础,可能玩的少,缺乏一定的分析经验,当我简单分析之后,我发... 查看详情
记一次.net某新能源系统线程疯涨分析(代码片段)
一:背景1.讲故事前段时间收到一个朋友的求助,说他的程序线程数疯涨,寻求如何解决。等我分析完之后,我觉得这个问题很有代表性,所以拿出来和大家分享下,还是上老工具WinDbg。二:WinDbg分析1.... 查看详情
记一次.net某云采购平台api挂死分析(代码片段)
一:背景1.讲故事大概有两个月没写博客了,关注我的朋友应该知道我最近都把精力花在了星球,这两个月时间也陆陆续续的有朋友求助如何分析dump,有些朋友太客气了,给了大大的红包,哈哈????,手... 查看详情
记一次.net某消防物联网后台服务内存泄漏分析
一:背景1.讲故事去年十月份有位朋友从微信找到我,说他的程序内存要炸掉了。。。截图如下:时间有点久,图片都被清理了,不过有点讽刺的是,自己的程序本身就是做监控的,结果自己出了问题,太尴尬了 查看详情
记一次.net某消防物联网后台服务内存泄漏分析
一:背景1.讲故事去年十月份有位朋友从微信找到我,说他的程序内存要炸掉了。。。截图如下:时间有点久,图片都被清理了,不过有点讽刺的是,自己的程序本身就是做监控的,结果自己出了问题,太尴尬了 查看详情
记一次.net某电厂web系统内存泄漏分析
一:背景1.讲故事前段时间有位朋友找到我,说他的程序内存占用比较大,寻求如何解决,截图就不发了,分析下来我感觉除了程序本身的问题之外,.NET5在内存管理方面做的也不够好,所以有必要给大家分享一下。二:WinDbg分... 查看详情
记一次.net某智能交通后台服务cpu爆高分析
一:背景1.讲故事前天有位朋友加微信求助他的程序出现了CPU爆高的问题,开局就是一个红包,把我吓懵了! 查看详情
记一次.net某工控mes程序崩溃分析(代码片段)
一:背景1.讲故事前几天有位朋友找到我,说他的程序出现了偶发性崩溃,已经抓到了dump文件,Windows事件日志显示的崩溃点在clr.dll中,让我帮忙看下是怎么回事,那到底怎么回事呢?上WinDbg说话。二:W... 查看详情
记一次.net某医疗器械程序崩溃分析(代码片段)
一:背景1.讲故事前段时间有位朋友在微信上找到我,说他的程序偶发性崩溃,让我帮忙看下怎么回事,上面给的压力比较大,对于这种偶发性崩溃,比较好的办法就是利用AEDebug在程序崩溃的时候自动抽一... 查看详情
记一次.net某机械臂智能机器人控制系统mrscpu爆高分析(代码片段)
一:背景1.讲故事这是6月中旬一位朋友加wx求助dump的故事,他的程序cpu爆高➕UI卡死,问如何解决,截图如下:在拿到这个dump后,我发现这是一个关于机械臂的MRS程序,哈哈,在机械臂这种智能机... 查看详情
记一次.net某制造业mes系统崩溃分析(代码片段)
一:背景1.讲故事前段时间有位朋友微信找到我,说他的程序偶尔会出现内存溢出崩溃,让我帮忙看下是怎么回事,咨询了下程序是x86部署,听到这个词其实心里已经有了数,不管怎么样还是用windbg分析一... 查看详情
记一次.net某化妆品webapi卡死分析(代码片段)
一:背景1.讲故事10月份星球里的一位老朋友找到我,说他们公司的程序在一个网红直播带货下给弄得无响应了,无响应期间有大量的RabbitMQ超时,寻求如何找到根源,聊天截图我就不发了。既然无响应了,那必然是程序的大量线... 查看详情
记一次.net某智慧物流wcs系统cpu爆高分析
一:背景1.讲故事哈哈,再次见到物流类软件,上个月有位朋友找到我,说他的程序出现了CPU爆高,让我帮忙看下什么原因,由于那段时间在苦心研究C++,分析和经验分享也就懈怠了,今天就给大家安排上。话不多说,上windbg说... 查看详情
记一次.net某金融企业wpf程序卡死分析(代码片段)
一:背景1.讲故事前段时间遇到了一个难度比较高的dump,经过几个小时的探索,终于给找出来了,在这里做一下整理,希望对大家有所帮助,对自己也是一个总结,好了,老规矩,上WinDBG说话。... 查看详情
记一次.net某智能服装智造系统内存泄漏分析(代码片段)
一:背景1.讲故事上个月有位朋友找到我,说他的程序出现了内存泄漏,不知道如何进一步分析,截图如下:朋友这段话已经说的非常言简意赅了,那就上windbg说话吧。二:Windbg分析1.到底是哪一方面的泄漏根据朋友描述,程序... 查看详情
记一次.net某电子病历cpu爆高分析(代码片段)
一:背景1.讲故事前段时间有位朋友微信找到我,说他的程序出现了CPU爆高,帮忙看下程序到底出了什么情况?图就不上了,我们直接进入主题。二:WinDbg分析1.CPU真的爆高吗?要确认是否真的爆高... 查看详情
记一次.net某工控自动化控制系统卡死分析(代码片段)
一:背景1.讲故事前段时间遇到了好几起关于窗体程序的进程加载锁引发的程序卡死和线程暴涨问题,这种dump分析难度较大,主要涉及到Windows操作系统和C++的基础知识,所以有必要简单整理和大家分享一下&... 查看详情