欢迎光临
我的个人博客网站

记一次 .NET WPF布草管理系统 挂死分析


一:背景

1. 讲故事

这几天看的 dump 有点多,有点伤神伤脑,晚上做梦都是dump,今天早上头晕晕的到公司就听到背后同事抱怨他负责的WPF程序挂死了,然后测试的小姑娘也跟着抱怨。。。嗨,也不知道是哪一个迭代改出来的问题,反正客户不起义问题都不大。😅😅😅

不过我听到程序无响应,内心深处真的是一拘灵。。。本能反应吧,给他发了一个 procdump 过去生成两个 dump 发过来。

话说回来,WPF这种带UI界面的挂死问题其实很好分析的,无非就是 UI线程 失去响应了,至于为啥失去响应了,肯定是做了什么见不得光的事情,比如耍小聪明用 Task.Result,还有一点要特别注意的是 UI 独有的 SynchronizationContext,如 Winform 的 : WindowsFormsSynchronizationContext ,WPF 的 DispatcherSynchronizationContext,后面我准备开一篇文章用 Windbg 深入剖析一下这个死锁形成的原因,好,说了这么多,dump 也到了,上 Windbg 分析吧。

二: windbg 分析

1. 审查UI线程

做法很简单,先通过 ~0s 切到0号,也就是UI线程,再通过 !dumpstack 调出UI线程的托管和非托管栈,为了保护隐私,我就稍微精简下。

 0:000> ~0s eax=00000000 ebx=01855bf8 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 eip=776a171c esp=014fe3b8 ebp=014fe410 iopl=0         nv up ei pl nz na pe nc cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206 ntdll!NtWaitForSingleObject+0xc: 776a171c c20c00          ret     0Ch 0:000> !dumpstack OS Thread Id: 0x4ee0 (0) Current frame: ntdll!NtWaitForSingleObject+0xc ChildEBP RetAddr  Caller, Callee 014fe3b4 7468a9c5 mswsock!SockWaitForSingleObject+0x125, calling ntdll!NtWaitForSingleObject 014fe410 7469932c mswsock!SockDoConnectReal+0x36b, calling mswsock!SockWaitForSingleObject 014fe4b4 74698df7 mswsock!SockDoConnect+0x482, calling mswsock!SockDoConnectReal 014fe544 74699861 mswsock!WSPConnect+0x61, calling mswsock!SockDoConnect 014fe564 77316cf7 ws2_32!WSAConnect+0x77 014fe5a0 6422aeea (MethodDesc 64088970 +0x5a DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Byte[], Int32, IntPtr, IntPtr, IntPtr, IntPtr)) 014fe5d4 6422aeea (MethodDesc 64088970 +0x5a DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Byte[], Int32, IntPtr, IntPtr, IntPtr, IntPtr)) 014fe5f4 641c72eb (MethodDesc 63ff4310 +0x4b System.Net.Sockets.Socket.DoConnect(System.Net.EndPoint, System.Net.SocketAddress)), calling 1d4d538c 014fe628 642160c5 (MethodDesc 640847c4 +0x7d System.Net.Sockets.Socket.Connect(System.Net.EndPoint)), calling (MethodDesc 63ff4310 +0 System.Net.Sockets.Socket.DoConnect(System.Net.EndPoint, System.Net.SocketAddress)) 014fe644 1d4d5bd3 (MethodDesc 1c93d404 +0x33 xxx.SocketHelper.xxxSocket.Connect(System.Net.IPEndPoint)), calling (MethodDesc 640847c4 +0 System.Net.Sockets.Socket.Connect(System.Net.EndPoint)) 014fe660 1d4d5834 (MethodDesc 1c01df50 +0x114 xxx.MainWindow.Connect()), calling (MethodDesc 1c93d404 +0 xxx.Utilities.SocketHelper.xxxSocket.Connect(System.Net.IPEndPoint)) 014fe714 1d4d8d84 (MethodDesc 1c01e094 +0x9c xxx.MainWindow.<IniTimer>b__18_0(System.Object, System.EventArgs)), calling (MethodDesc 1c01df50 +0 xxx.MainWindow.Connect())  

从上面的调用堆栈可以看出,MainWindow 中做了一个 Socket.Connect 连接,最后卡死在非托管的 mswsock!SockDoConnectReal方法上,应该是 Socket 连不上造成的,既然是 Socket ,把它的 ip 和 port 拿出来 telnet 一下不就好啦,对吧,可以用 !dso 把当前线程栈中所有的托管对象找出来。

 0:000> !dso OS Thread Id: 0x4ee0 (0) ESP/REG  Object   Name 014FE4D8 03a47588 System.Net.SafeCloseSocket+InnerSafeCloseSocket 014FE598 03a476bc System.Net.EndpointPermission 014FE5E4 03a4762c System.Byte[] 014FF068 03681374 System.AppDomain 014FF4D8 03681238 System.SharedStatics 014FE6B4 036a4dfc System.String    9901 014FE6C4 036a4ba0 System.String    192.168.1.79  

哈哈,从最后两行可以看出,socket 地址就是:192.168.1.79:9901, telnet 一下果然不通,问了下,原来是测试机最近重启了, Socket 服务端并没有随机器启动,貌似问题就这样找到了。。。

是不是觉得有哪里不对劲呢? 对, 就是为啥要在主线程做 Connect 呢? 万一 Socket 连不上,这不就是把自己陷入不仁不义的地步嘛,问了下实施,说WPF和SocketServer都是一同部署的,据说在现场也偶尔遇到,可能坑踩多了他们自己也摸索出来了,把 SockerServer 重启一下就搞定了,不过这次可能研发自己都看不下去了吧 😂😂😂, 真是自曝家丑。。。

2. 查看问题代码

问题还是要解决的,先把问题代码导出来,用 !name2ee + !savemodule 即可。

 0:000> !name2ee *!xxx.MainWindow.Connect Module:      01754044 Assembly:    xxx.exe Token:       06000af5 MethodDesc:  1c01df50 Name:        xxx.MainWindow.Connect() JITTED Code Address: 1d4d5720 0:000> !savemodule 01754044  E:dumps3.dll 3 sections in file section 0 - VA=2000, VASize=3835b4, FileAddr=200, FileSize=383600 section 1 - VA=386000, VASize=3520, FileAddr=383800, FileSize=3600 section 2 - VA=38a000, VASize=c, FileAddr=386e00, FileSize=200  

然后用 ILSpy 打开 3.dll ,查看精简后的代码如下:

 	private void Window_Loaded(object sender, RoutedEventArgs e) 	{ 		Connect(); 	}          private bool Connect() 	{ 		string ipString = ConfigurationManager.AppSettings["ServerSocketIp"]; 		IPAddress address = IPAddress.Parse(ipString); 		IPEndPoint iPEndPoint = new IPEndPoint(address, Convert.ToInt32(ConfigurationManager.AppSettings["ServerPort"])); 		sockClient = (xxxSocket)(object)new xxxSocket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); 		try 		{ 			sockClient.Connect(iPEndPoint); 			((Socket)(object)sockClient).IOControl(IOControlCode.KeepAliveValues, KeepAlive(1, 1000, 1000), (byte[])null); 			sockClient.add_RecievedMessage((EventHandler<SocketMessage>)sockClient_RecievedMessage); 		} 		catch (SocketException ex) 		{ 		 			return false; 		} 		return true; 	}  

很清楚的看到在主线程做了 Connect 操作,这是大忌哈。。。 可能这段 Socket 代码也是网上找的,应该也没注意太多吧。。。

三:总结

知道前因后果之后,优化办法就比较简单了。

  • 把 Connect 丢到 Task.Run 中,释放主线程,简单粗暴,
         private async void Window_Loaded(object sender, RoutedEventArgs e)         {             Task.Run(()=> { Connect() });         }  
  • 使用 async, await

在这个 1+1 都要使用异步写法的时代,不用它真的感觉落伍了。。。这里我就不费脑子怎么用 XXXAsync 家族了哈。

         private async void Window_Loaded(object sender, RoutedEventArgs e)         {             string address = "192.168.1.79";             int port = 9901;              var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);             socket.SendTimeout = 1000 * 10;             socket.ReceiveTimeout = 1000 * 10;              await socket.ConnectAsync(address, port);             //....         }  

这个真实案例很简单,难度等级0, 不知道您学会了吗? 其实有时也感叹一下,像这种案例会 Windbg 3分钟解决,不会要摸头一上午。

更多高质量干货:参见我的 GitHub: dotnetfly

记一次 .NET WPF布草管理系统 挂死分析

赞(0) 打赏
未经允许不得转载:张拓的天空 » 记一次 .NET WPF布草管理系统 挂死分析
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

专业的IT技术经验分享 更专业 更方便

联系我们本站主机

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏