记一次 .NET 某拍摄监控软件 卡死分析

这篇具有很好参考价值的文章主要介绍了记一次 .NET 某拍摄监控软件 卡死分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一:背景

1. 讲故事

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

记一次 .NET 某拍摄监控软件 卡死分析

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

二: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+0x4304d

从卦象来看,程序在 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        : 0x200064a

上面的 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+0x2b

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


int recv(
  SOCKET s,
  char *buf,
  int len,
  int flags
);

因为是主控端,我在网上找了一段 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;
}

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

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

  • 大截图
  • 受控端偶发断网

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

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

记一次 .NET 某拍摄监控软件 卡死分析

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


0a8cf26c 09ddd32f     000007e8 011a5a30 00002000 ws2_32!recv+0x95

那这个问题怎么解决呢? 通篇分析下来应该就是 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.com


三:总结

这次卡死事故还是挺有教育意义的,告诉我们第三方插件尽量应升尽升,同时也考察了对 临界区锁 和 socket 的基础知识。文章来源地址https://www.toymoban.com/news/detail-710307.html

记一次 .NET 某拍摄监控软件 卡死分析

到了这里,关于记一次 .NET 某拍摄监控软件 卡死分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次 .NET某医疗器械清洗系统 卡死分析

    前段时间协助训练营里的一位朋友分析了一个程序卡死的问题,回过头来看这个案例比较经典,这篇稍微整理一下供后来者少踩坑吧。 因为是窗体程序,理所当然就是看主线程此时正在做什么? 可以用 ~0s ; k 看一下便知。 从线程栈来看,当前的方法卡在 win32u!NtUserPeekMessage 上

    2023年04月18日
    浏览(54)
  • 记一次 .NET 某工控电池检测系统 卡死分析

    前几天有位朋友找到我,说他的窗体程序有卡死现象,让我帮忙看下怎么回事,解决这种问题就需要在卡死的时候抓一个dump下来,拿到dump之后就可以分析了。 窗体程序的卡死,需要观察主线程此时正在做什么,可以用 !clrstack 命令观察。 从卦中的线程栈数据来看,貌似是卡

    2024年02月05日
    浏览(61)
  • 记一次 .NET某MES自动化桌面程序 卡死分析

    前些天有位朋友在微信上找到我,说他们的客户端程序卡死了,让我帮忙看下是什么原因导致的?dump也拿到了手,既然有了dump就开始正式分析吧。 客户端的程序卡死比较好找原因,入手点就是主线程,看下它此时正在做什么,可以用 k 命令。 从卦中信息看,代码正在托管层

    2024年01月16日
    浏览(44)
  • 记一次 .NET某股票交易软件 灵异崩溃分析

    在dump分析的旅程中也会碰到一些让我无法解释的灵异现象,追过这个系列的朋友应该知道,上一篇我聊过 宇宙射线 导致的程序崩溃,后来我又发现了一例,而这一例恰恰是高铁的 列控连锁一体化 程序,所以更加让我确定这是由于 电离辐射 干扰了计算机的 数字信号 导致程

    2024年02月04日
    浏览(43)
  • 记一次 .NET某收银软件 非托管泄露分析

    在我的分析之旅中,遇到过很多程序的故障和杀毒软件扯上了关系,有杀毒软件导致的程序卡死,有杀毒软件导致的程序崩溃,这一篇又出现了一个杀毒软件导致的程序非托管内存泄露,真的是分析多了什么鬼都能撞上。 前几天有位朋友找到过,我他们的程序内存在慢慢的泄

    2024年02月03日
    浏览(41)
  • 记一次 .NET某账本软件 非托管泄露分析

    中秋国庆长假结束,哈哈,在老家拍了很多的短视频,有兴趣的可以上B站观看:https://space.bilibili.com/409524162 ,今天继续给大家分享各种奇奇怪怪的.NET生产事故,希望能帮助大家在未来的编程之路上少踩坑。 话不多说,这篇看一个 .NET程序集泄露 导致的CLR私有堆泄露的案例,

    2024年02月08日
    浏览(43)
  • 记一次 Visual Studio 2022 卡死分析

    最近不知道咋了,各种程序有问题都寻上我了,你说 .NET 程序有问题找我能理解,Windows 崩溃找我,我也可以试试看,毕竟对 Windows 内核也知道一丢丢,那 Visual Studio 有问题找我就说不过去了,但又不好拒绝,就让朋友发下卡死的 dump 我看一看。 因为 VS 是窗体程序,所以在卡

    2024年02月05日
    浏览(55)
  • 记一次 .NET某设备监控自动化系统 CPU爆高分析

    先说一下题外话,一个监控别人系统运行状态的程序,结果自己出问题了,有时候想一想还是挺讽刺的,哈哈,开个玩笑,我们回到正题,前些天有位朋友找到我,说他们的系统会偶发性CPU爆高,CPU上去了就下不来了,让我帮忙看一下怎么回事,而且自己也分析过了,没找到

    2024年03月09日
    浏览(42)
  • 记一次 .NET某防伪验证系统 崩溃分析

    昨晚给训练营里面的一位朋友分析了一个程序崩溃的故障,因为看小伙子昨天在群里问了一天也没搞定,干脆自己亲自上阵吧,抓取的dump也是我极力推荐的用 procdump 注册 AEDebug 的方式,省去了很多沟通成本。 windbg有一个非常强大的点就是当你双击打开后,会自动帮你切换到

    2024年03月28日
    浏览(63)
  • 记一次 .NET 某企业采购平台 崩溃分析

    前段时间有个朋友找到我,说他们的程序有偶发崩溃的情况,让我帮忙看下怎么回事,针对这种 crash 的程序,用 AEDebug 的方式抓取一个便知,有了 dump 之后接下来就可以分析了。 既然是程序的崩溃,我们可以像看蓝屏一下看dump文件,使用 !analyze -v 命令即可。 从上面的信息

    2024年02月11日
    浏览(52)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包