记一次 腾讯会议 的意外崩溃分析

一:背景

1. 讲故事

前段时间在用 腾讯会议 直播的时候,居然意外崩溃了,还好不是在训练营上课,不然又得重录了,崩完之后发现 腾讯会议 的 bugreport 组件会自动生成一个 minidump,截图如下:

记一次 腾讯会议 的意外崩溃分析

作为一个.NET高级调试的技术博主,非 .NET 的程序也得要研究研究哈???,有了这个好奇心,也有了这个 dump,接下来用 windbg 看一看吧。

二:WinDbg 分析

1. 为什么会崩溃

在 Windows 平台上不管是硬件异常还是软件异常 操作系统都会帮忙构造一个 EXCEPTION_POINTERS 结构体,这里面就包含了程序的崩溃点,错误码等各种非常有价值的信息,要想洞察这个结构体,要么在栈上提取,要么用 !analyze -v 自动化提取,这里采用后者。


0:000> !analyze -v

CONTEXT:  (.ecxr)
eax=008fdfe4 ebx=00000001 ecx=00000000 edx=2d692620 esi=3c4e1818 edi=3207f464
eip=1c5b34aa esp=008fe034 ebp=008fe094 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
meeting_dashboard_module+0x34aa:
1c5b34aa 8b01            mov     eax,dword ptr [ecx]  ds:002b:00000000=????????
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 1c5b34aa (meeting_dashboard_module+0x000034aa)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000

PROCESS_NAME:  wemeetapp.exe

READ_ADDRESS:  00000000 

ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p            0x%p                    %s

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000000

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
008fe094 7ad808f4     008fe320 00000000 ec0d8f9b meeting_dashboard_module+0x34aa
008fe214 7ad80617     008fe2f0 ec0d89ef 4ee246d8 desktop_common+0x108f4
008fe460 7ad7f4d7     776f6873 008fe400 79641fe1 desktop_common+0x10617
008fe5ec 7ad7ae62     008fe9d0 008fe76c 79bce43a desktop_common+0xf4d7
008fe5f8 79bce43a     008fe6b8 a0f1fbb4 326aed58 desktop_common+0xae62
008fe76c 7ad7de66     00000000 008fe9d0 ec0d8a63 wemeet_framework+0x2e43a
008fe7ec 7ad7deed     00000000 008fe9d0 008fe808 desktop_common+0xde66
008fe7fc 7ad7ae62     008fe9d0 008fe97c 79bce43a desktop_common+0xdee
...

从上面的 ExceptionCode: c0000005 来看,这是一个经典的访问违例,从崩溃汇编的 mov eax,dword ptr [ecx] ds:002b:00000000=???????? 来看,当前的 ecx 中存放的是 0 ,从 0 上取内容自然就是访问违例。

2. 为什么会访问违例

要想知道访问违例的原因,就需要分析一下附近的汇编代码,用 .ecxr ; k 切到异常前的崩溃上下文。


0:000> .ecxr ; k
eax=008fdfe4 ebx=00000001 ecx=00000000 edx=2d692620 esi=3c4e1818 edi=3207f464
eip=1c5b34aa esp=008fe034 ebp=008fe094 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
meeting_dashboard_module+0x34aa:
1c5b34aa 8b01            mov     eax,dword ptr [ecx]  ds:002b:00000000=????????
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr      
WARNING: Stack unwind information not available. Following frames may be wrong.
00 008fe094 7ad808f4     meeting_dashboard_module+0x34aa
01 008fe214 7ad80617     desktop_common+0x108f4
02 008fe460 7ad7f4d7     desktop_common+0x10617
03 008fe5ec 7ad7ae62     desktop_common+0xf4d7
04 008fe5f8 79bce43a     desktop_common+0xae62
05 008fe76c 7ad7de66     wemeet_framework+0x2e43a
06 008fe7ec 7ad7deed     desktop_common+0xde66
07 008fe7fc 7ad7ae62     desktop_common+0xdeed
08 008fe808 79bce43a     desktop_common+0xae62
09 008fe97c 79bc784c     wemeet_framework+0x2e43a
0a 008fe98c 79bc821f     wemeet_framework+0x2784c
0b 008fe9a0 79bdac53     wemeet_framework+0x2821f
0c 008fea1c 79bdb791     wemeet_framework+0x3ac53
...

由于没有这些 dll 的符号,windbg 为了定义代码行数,就只能用 module + 0xxxxx 作为偏移来定位。

现在我们知道 ecx=0,那为什么会是 0 呢?接下来用 ub 观察下汇编代码逻辑,截图如下:


0:000> ub 1c5b34aa L20
meeting_dashboard_module+0x3449:
1c5b3449 00c6            add     dh,al
1c5b344b 45              inc     ebp
1c5b344c b000            mov     al,0
1c5b344e e8cde2ffff      call    meeting_dashboard_module+0x1720 (1c5b1720)
1c5b3453 8d45b0          lea     eax,[ebp-50h]
1c5b3456 c645fc04        mov     byte ptr [ebp-4],4
1c5b345a 50              push    eax
1c5b345b 8bce            mov     ecx,esi
1c5b345d ff15a8cb611c    call    dword ptr [meeting_dashboard_module+0x6cba8 (1c61cba8)]
1c5b3463 8d4db0          lea     ecx,[ebp-50h]
1c5b3466 8945c8          mov     dword ptr [ebp-38h],eax
1c5b3469 c645fc00        mov     byte ptr [ebp-4],0
1c5b346d e8feebffff      call    meeting_dashboard_module+0x2070 (1c5b2070)
1c5b3472 51              push    ecx
1c5b3473 8b4d0c          mov     ecx,dword ptr [ebp+0Ch]
1c5b3476 8bd4            mov     edx,esp
1c5b3478 c7450c00000000  mov     dword ptr [ebp+0Ch],0
1c5b347f 890a            mov     dword ptr [edx],ecx
1c5b3481 8bcf            mov     ecx,edi
1c5b3483 e8d8010000      call    meeting_dashboard_module+0x3660 (1c5b3660)
1c5b3488 837dc801        cmp     dword ptr [ebp-38h],1
1c5b348c 8b4f08          mov     ecx,dword ptr [edi+8]
1c5b348f 8b01            mov     eax,dword ptr [ecx]
1c5b3491 7509            jne     meeting_dashboard_module+0x349c (1c5b349c)
1c5b3493 6a01            push    1
1c5b3495 6a01            push    1
1c5b3497 ff507c          call    dword ptr [eax+7Ch]
1c5b349a eb2b            jmp     meeting_dashboard_module+0x34c7 (1c5b34c7)
1c5b349c ff5048          call    dword ptr [eax+48h]
1c5b349f 8bc8            mov     ecx,eax
1c5b34a1 ff15ccc6611c    call    dword ptr [meeting_dashboard_module+0x6c6cc (1c61c6cc)]
1c5b34a7 8b4f08          mov     ecx,dword ptr [edi+8]
1c5b34aa 8b01            mov     eax,dword ptr [ecx]
...

从汇编代码看,当前的 ecx 是来自于地址 edi+8,edi 的值有可能会在 meeting_dashboard_module+0x6c6cc (1c61c6cc) 方法中被修改,我们一并观察下。


0:000> dp @edi+8 L2
3207f46c  ???????? ????????

0:000> u 1c61c6cc
meeting_dashboard_module+0x6c6cc:
1c61c6cc ??              ???
                ^ Memory access error in 'u 1c61c6cc'

我去,都是 ???,这表示当前的数据和机器指令都没有纳入到 dump 中,这也就是为什么 dump 小的原因。

到这里好像就没法继续分析了,天要绝人之路吗?

3. 还有希望吗

虽然被当头一棒,但总得要挣扎一下吧,突破口也只能是汇编代码了,通过仔细观察,由于倒数第五行是一个 jmp 指令,所以语句指令 1c5b349c 肯定是从别的地方飞跃过来的,翻译成 C 代码就是一个 if else 的判断,截图如下:

记一次 腾讯会议 的意外崩溃分析

既然走到了 else 的逻辑,那必然 ebp-38h 上的值肯定不是 1,那到底是多少呢?可以来查一查。

0:000> dp @ebp-38h L1
008fe05c  00000000

@ebp-38h 是谁给的呢?继续观察汇编代码,发现是 meeting_dashboard_module+0x6cba8 函数的返回值 eax 给的 ,从汇编逻辑看, 0 是一种异常状态。

4. 为什么会返回 0

返回 0 也暗示了代码在哪里报了一些错,可以用 GetLastError() 来获取可能调用 win32api 出错时设置的错误码,用 !teb 观察里面的 LastErrorValue 值。


0:000> !teb
TEB at 0078a000
    ExceptionList:        008fcf94
    StackBase:            00900000
    StackLimit:           008ee000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 0078a000
    EnvironmentPointer:   00000000
    ClientId:             00003ccc . 00004484
    Real ClientId:        00000000 . 00000000
    RpcHandle:            00000000
    Tls Storage:          40a94180
    PEB Address:          00787000
    LastErrorValue:       18
    LastStatusValue:      0
    Count Owned Locks:    0
    HardErrorMode:        0

这里的 18 是一个十进制,十六进制就是 0x12 ,那这个错误码代表什么意思呢? !error 已经不支持了,只能上 msdn 上找答案,截图如下:

记一次 腾讯会议 的意外崩溃分析

汇总一下:在腾讯会议录制期间,可能是处理什么文件抛了一个 There are no more files. 错误,在错误处理的后续逻辑中抛了崩溃。

有了这个信息之后,可以到外网搜一下 (https://windowsreport.com/there-are-no-more-files),常见的解决办法如下:

  • Solution 1 — Remove folder lock
  • Solution 2 – Repair your registry
  • Solution 3 — Run a full system scan
  • Solution 4 — Update your OS
  • Solution 5 — Remove recently installed software
  • Solution 6 — Uninstall Comodo Cleaner/ ASUS security data manager
  • Solution 7 — Boot into Safe Mode

具体是什么原因,由于缺少符号再深入分析下去得要花一些时间了,这里就到此为止吧。

三:总结

崩溃的 dump 已经第一时间提交上去了,相信腾讯会议的研发团队能够很快解决,作为一个付费会员,真心希望在下次录制的时候不要再崩了。

图片名称

原文链接:https://www.cnblogs.com/huangxincheng/p/17336640.html

本站文章如无特殊说明,均为本站原创,如若转载,请注明出处:记一次 腾讯会议 的意外崩溃分析 - Python技术站

(0)
上一篇 2023年4月22日
下一篇 2023年4月22日

相关文章

  • 【Visual Leak Detector】库的 22 个 API 使用说明

    说明 使用 VLD 内存泄漏检测工具辅助开发时整理的学习笔记。本篇主要介绍 VLD 库提供的 22 个外部接口。同系列文章目录可见 《内存泄漏检测工具》目录 目录 说明 1. 头文件简介 2. 文件 vld_def.h 简介 3. 文件 vld.h 简介 3.1 接口 VLDDisable 3.2 接口 VLDEnable 3.3 接口 VLDRestore…

    C++ 2023年4月17日
    00
  • 【Visual Leak Detector】配置项 TraceInternalFrames

    说明 使用 VLD 内存泄漏检测工具辅助开发时整理的学习笔记。本篇介绍 VLD 配置文件中配置项 TraceInternalFrames 的使用方法。同系列文章目录可见 《内存泄漏检测工具》目录 目录 说明 1. 配置文件使用说明 2. 设置是否跟踪内部堆栈的调用 2.1 测试代码 2.2 TraceInternalFrames = no 时的输出 2.3 …

    C++ 2023年4月18日
    00
  • C++/Qt网络通讯模块设计与实现(六)

    前面章节主要讲述网络通讯客户端的实现,各位小伙伴需认真阅读以及理解,理会其中的思想,有疑问的地方可及时给我私信,我都会非常认真地解答大家的疑惑。 C++/Qt网络通讯模块设计与实现(一) C++/Qt网络通讯模块设计与实现(二) C++/Qt网络通讯模块设计与实现(三) C++/Qt网络通讯模块设计与实现(四) C++/Qt网络通讯模块设计与实现(五) 这节…

    C++ 2023年4月18日
    00
  • 记一次 Windows10 内存压缩模块 崩溃分析

    一:背景 1. 讲故事 在给各位朋友免费分析 .NET程序 各种故障的同时,往往也会收到各种其他类型的dump,比如:Windows 崩溃,C++ 崩溃,Mono 崩溃,真的是啥都有,由于基础知识的相对缺乏,分析起来并不是那么的顺利,今天就聊一个 Windows 崩溃的内核dump 吧,这个 dump 是前几天有位朋友给到我的,让我帮忙看一下,有了dump之…

    C# 2023年5月2日
    00
  • C++ 测试框架 GoogleTest 初学者入门篇 乙

    *以下内容为本人的学习笔记,如需要转载,请声明原文链接 微信公众号「ENG八戒」https://mp.weixin.qq.com/s/aFeiOGO-N9O7Ab_8KJ2wxw 开发者虽然主要负责工程里的开发任务,但是每个开发完毕的功能都是需要开发者自测通过的,所以经常会听到开发者提起单元测试的话题。那么今天我就带大伙一起来看看大名鼎鼎的谷歌 C++ 测试…

    C++ 2023年4月18日
    00
  • 驱动开发:内核使用IO/DPC定时器

    本章将继续探索驱动开发中的基础部分,定时器在内核中同样很常用,在内核中定时器可以使用两种,即IO定时器,以及DPC定时器,一般来说IO定时器是DDK中提供的一种,该定时器可以为间隔为N秒做定时,但如果要实现毫秒级别间隔,微秒级别间隔,就需要用到DPC定时器,如果是秒级定时其两者基本上无任何差异,本章将简单介绍IO/DPC这两种定时器的使用技巧。 首先来看IO…

    C++ 2023年4月18日
    00
  • luogu_P1040 [NOIP2003 提高组] 加分二叉树

    P1040 [NOIP2003 提高组] 加分二叉树 – 洛谷 | 计算机科学教育新生态 (luogu.com.cn) 题意:给你一颗中序遍历为1到n的二叉树,和每个节点的val。树的值=左子树的值×右子树的值+根的val,空树值为1,求整个树最大值和这个值树的前序遍历。 题解:区间dp。dp[l][r]表示最大值,root[l][r]表示最大值的根,枚举区…

    C++ 2023年4月27日
    00
  • 【Visual Leak Detector】配置项 AggregateDuplicates

    说明 使用 VLD 内存泄漏检测工具辅助开发时整理的学习笔记。本篇介绍 VLD 配置文件中配置项 AggregateDuplicates 的使用方法。同系列文章目录可见 《内存泄漏检测工具》目录 目录 说明 1. 配置文件使用说明 2. 设置是否显示重复的泄漏块 2.1 测试代码 2.2 AggregateDuplicates = no 时的输出 2.3 A…

    C++ 2023年4月18日
    00
合作推广
合作推广
分享本页
返回顶部