一、记次监控背景

1. 讲故事

今天本来想写一篇 非托管泄露 的拍摄生产事故分析 ，但想着昨天就上了一篇非托管文章，软件连着写也没什么意思 ，死分换个口味吧，记次监控刚好前些天有位朋友也找到我 ，拍摄说他们的软件拍摄监控软件卡死了，让我帮忙分析下为什么会卡死，死分听到这种软件，记次监控让我不禁想起了前些天 在程序员桌子上安装监控 的拍摄新闻 ，参考如下 ：

图片

我在想我这不是软件尼玛作恶吗... 😂😂😂 和朋友确认了下还好不是干这个事的 。建站模板

二、死分WinDbg 分析

1. 为什么会卡死

因为这种监控软件是记次监控窗体程序，所以它的拍摄卡死理应看主线程的调用栈即可, 在windbg中有一个 k 命令。

复制0:000:x86> kb 8 # ChildEBP RetAddr Args to Child 00 00dbedc0 77835329 0fd54c08 00000000 0fd54c08 ntdll_777d0000!NtWaitForAlertByThreadId+0xc 01 00dbedc0 7783505c 00000000 00000000 0fd54c08 ntdll_777d0000!RtlpWaitOnAddressWithTimeout+0x64 02 00dbee60 77813fd8 0fd543f0 0fd54c04 0000000c ntdll_777d0000!RtlpWaitOnCriticalSection+0x1ac 03 00dbeea8 77813d99 00000000 00dbef04 09d72f87 ntdll_777d0000!RtlpEnterCriticalSectionContended+0x228 04 00dbeeb4 09d72f87 0fd54c04 09d38131 ee66de6e ntdll_777d0000!RtlEnterCriticalSection+0x49 WARNING: Stack unwind information not available. Following frames may be 软件wrong. 05 00dbef04 09d38036 ee66de46 000001fd 00000111 scvncctrl!DllUnregisterServer+0x4ed7 06 00dbef2c 09d3304d 00000111 000001fd 00000111 scvncctrl+0x48036 07 00dbef50 09d341f3 00000111 000001fd 00000001 scvncctrl+0x4304d1.2.3.4.5.6.7.8.9.10.11.

从卦象来看 ，程序在 scvncctrl!DllUnregisterServer+0x4ed7 方法中等待 临界区锁 ，即 RtlEnterCriticalSection 处。

可能有些朋友有疑问 ，为什么 scvncctrl 后面的偏移值那么大 ，这是因为 scvncctrl 没有提供公有和私有符号 ，所以无法对应函数名 ，windbg 只能以 module 为参考点设置偏移
，源码库这对 dump 分析产生了很大的阻碍！

接下来继续看 ，既然主线程在等待锁，那必然有人在持有锁，那到底是谁在持有呢？

2. 寻找持有线程

要想找到持有者，可以提取 RtlEnterCriticalSection 方法中的第一个参数 0fd54c04  ，我们使用 dt _RTL_CRITICAL_SECTION 命令即可。

复制0:000:x86> dt _RTL_CRITICAL_SECTION 0fd54c04 ntdll_777d0000!_RTL_CRITICAL_SECTION +0x000 DebugInfo : 0x07ba4428 _RTL_CRITICAL_SECTION_DEBUG +0x004 LockCount : 0n-6 +0x008 RecursionCount : 0n1 +0x00c OwningThread : 0x0000621c Void +0x010 LockSemaphore : 0xffffffff Void +0x014 SpinCount : 0x200064a1.2.3.4.5.6.7.8.

上面的 OwningThread 就是当前的持有线程，找到了之后切过去看下它的线程栈，亿华云它到底在干嘛？

复制0:005:x86> ~~[0x0000621c]s ntdll_777d0000!NtWaitForSingleObject+0xc: 7784619c c20c00 ret 0Ch 0:005:x86> kb CvRegToMachine(x86) conversion failure for 0x14f X86MachineInfo::SetVal: unknown register 0 requested # ChildEBP RetAddr Args to Child 00 0a8cf1ac 747ccfd5 00000924 00000001 00000000 ntdll_777d0000!NtWaitForSingleObject+0xc 01 0a8cf1ac 747ddb12 00000002 00000006 ae23e128 mswsock!SockWaitForSingleObject+0x125 02 0a8cf220 75c05fe5 000007e8 0a8cf258 00000001 mswsock!WSPRecv+0x232 03 0a8cf26c 09ddd32f 000007e8 011a5a30 00002000 ws2_32!recv+0x95 WARNING: Stack unwind information not available. Following frames may be wrong. 04 0a8cf3b4 09ddd0a6 011a5a30 00002000 00000003 scvncctrl!DllUnregisterServer+0x6f27f 05 0a8cf4d4 09ddd625 00000001 00000001 07ac4ae0 scvncctrl!DllUnregisterServer+0x6eff6 06 0a8cf5f0 09ddd72f 0fd1f350 07ac4ae0 00000000 scvncctrl!DllUnregisterServer+0x6f575 07 0a8cf708 09d70626 00000003 00000001 0fd543f0 scvncctrl!DllUnregisterServer+0x6f67f 08 0a8cf958 09d71b56 00000075 000001f7 0000070b scvncctrl!DllUnregisterServer+0x2576 09 0a8cf9a4 09d3140c 00000075 000001f7 0000070b scvncctrl!DllUnregisterServer+0x3aa6 0a 0a8cfa18 09d35b89 e431cbea 0fd5fbf0 0fd543f0 scvncctrl+0x4140c 0b 0a8cfa80 09d73189 00000000 09d73120 0a8cfacc scvncctrl+0x45b89 0c 0a8cfa90 09e09434 0fd543f0 e431cba6 09e093dd scvncctrl!DllUnregisterServer+0x50d9 0d 0a8cfacc 75c77ba9 0fd5fbf0 75c77b90 0a8cfb34 scvncctrl!DllUnregisterServer+0x9b384 0e 0a8cfadc 7783b79b 0fd5fbf0 c738a5e9 00000000 kernel32!BaseThreadInitThunk+0x19 0f 0a8cfb34 7783b71f ffffffff 778689f7 00000000 ntdll_777d0000!__RtlUserThreadStart+0x2b1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.

卦中的 ws2_32!recv 是一个win32体系内的方法，用于 接收客户端发送数据 ，可能有些朋友对 recv 方法不是很清楚，方法签名大概如下：

复制int recv( SOCKET s, char *buf, int len, int flags );1.2.3.4.5.6.

因为是主控端，我在网上找了一段 win32 实现的 server 版的 recv 完整代码。

复制#define _WINSOCK_DEPRECATED_NO_WARNINGS //1.头文件 #include <stdio.h> #include <Winsock2.h> #pragma comment (lib,"ws2_32.lib") int main() { WSADATA wsaData; WSAStartup(MAKEWORD(2, 2), &wsaData); if (LOBYTE(wsaData.wVersion) != 2 || HIBYTE(wsaData.wVersion) != 2) { printf("请求版本失败 ！\n"); return -1; } printf("请求版本成功 ！\n"); SOCKET serverScoket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (INVALID_SOCKET == serverScoket) { printf("创建套接字失败！\n"); WSACleanup(); return -1; } printf("创建套接字成功！模板下载\n"); SOCKADDR_IN serverAddr = { 0 }; serverAddr.sin_family = AF_INET; serverAddr.sin_port = htons(8888); serverAddr.sin_addr.S_un.S_addr = inet_addr("192.168.0.107"); if (SOCKET_ERROR == bind(serverScoket, (SOCKADDR*)&serverAddr, sizeof(serverAddr))) { printf("绑定失败 ！\n"); closesocket(serverScoket); WSACleanup(); return -1; } printf("绑定成功 ！\n"); if (SOCKET_ERROR == listen(serverScoket, 10)) { printf("监听失败 ！\n"); closesocket(serverScoket); WSACleanup(); return -1; } printf("监听成功！\n"); SOCKADDR_IN clientAddr = { 0 }; int len = sizeof(clientAddr); SOCKET clientSocket = accept(serverScoket, (sockaddr*)&clientAddr, &len); if (INVALID_SOCKET == clientSocket) { printf("接受链接失败！\n"); closesocket(serverScoket); WSACleanup(); return -1; } printf("接受客户链接成功！\n"); printf("客户ip为 ：%s", inet_ntoa(clientAddr.sin_addr)); //8.开始通讯 char recvbuff[1024] = { }; char sendbuff[1024] = { }; //参数一
：代表客户端的socket，表示从客户端进行收取数据 //参数二：接受的数据存放地址 //参数三
：接受数据的长度 //参数四：表示收发方式，0表示默认，一次收完 while (true) { //保存数据清空 memset(recvbuff, 0, sizeof(recvbuff)); //从客户端接受数据 if (recv(clientSocket, recvbuff, sizeof(recvbuff) - 1, 0) > 0) { printf("客户说：%s\n", recvbuff); } else { break; } memset(sendbuff, 0, sizeof(sendbuff)); printf("我说："); scanf_s("%s", sendbuff, sizeof(sendbuff) - 1); //发送数据给客户端 send(clientSocket, sendbuff, strlen(sendbuff), 0); } //9.关闭链接 closesocket(clientSocket);//关闭客户端socket closesocket(serverScoket);//关闭服务端socket WSACleanup(); //关闭套接字请求 return 0; }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.84.85.86.87.88.89.90.91.92.93.94.95.96.97.98.99.100.

结合上面的完整代码，业务逻辑应该是 while (true) 里的高防服务器 send 和 recv 区间内的某句代码持有了锁 ，但因为某种异常导致持有的 临界区锁 没有释放，出现了一种 锁污染 的情况。

朋友提供的信息也进一步佐证了这种说法。

大截图受控端偶发断网

这些情况组合在一起导致了 send 和 recv 之间的某处代码异常污染了 临界区锁。

本来想提取下 recv 中的 socket 信息 ，结果发现是一个网络句柄号 ，真正的socket信息在内核层 ，服务器租用没法提出来只能作罢，截图如下：

图片

也即线程栈上的 000007e8 字段。

复制0a8cf26c 09ddd32f 000007e8 011a5a30 00002000 ws2_32!recv+0x951.

那这个问题怎么解决呢？通篇分析下来应该就是 scvncctrl 的 bug ，能做的就是升级到最新版本 ，毕竟程序里还是 2020 年的。

复制0:005:x86> lmvm scvncctrl Browse full module list start end module name 09cf0000 09f06000 scvncctrl (export symbols) scvncctrl.dll Loaded symbol image file: scvncctrl.dll Image name: scvncctrl.dll Browse all global symbols functions data Timestamp: Sat Oct 10 15:14:33 2020 (5F815F59) CheckSum: 001CA728 ImageSize: 00216000 File version: 3.9.2.0 Product version: 3.9.2.0 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 Information from resource tables: CompanyName: SmartCode Pte. Ltd. ProductName: SmartCode VNC Viewer ActiveX OriginalFilename: scvncctrl.dll ProductVersion: 3.9.2.0 FileVersion: 3.9.2.0 FileDescription: SmartCode VNC Viewer ActiveX LegalCopyright: Copyright (c) 2003-2020 SmartCode Pte. Ltd. All rights reserved. Comments: https://www.s-code.com1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.

三、总结

这次卡死事故还是挺有教育意义的，告诉我们第三方插件尽量应升尽升，同时也考察了对 临界区锁 和 socket 的基础知识 。