共计 4920 个字符，预计需要花费 13 分钟才能阅读完成。
一：背景
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:\dumps\3.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
