腾讯会议异常中断,腾讯会议为啥崩溃了

一：背景1. 讲故事

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

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

二：WinDbg 分析1. 为什么会崩溃

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

0:000> !analyze -vCONTEXT: (.ecxr)eax=008fdfe4 ebx=00000001 ecx=00000000 edx=2d692620 esi=3c4e1818 edi=3207f464eip=1c5b34aa esp=008fe034 ebp=008fe094 iopl=0 nv up ei pl nz ac pe nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216meeting_dashboard_module 0x34aa:1c5b34aa 8b01 mov eax,dword ptr [ecx] ds:002b:00000000=????????Resetting default scopeEXCEPTION_RECORD: (.exr -1)EXCEPTIONAddress: 1c5b34aa (meeting_dashboard_module 0x000034aa) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00000000Attempt to read from address 00000000PROCESS_NAME: wemeetapp.exeREAD_ADDRESS: 00000000 ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p 0x%p %sEXCEPTION_CODE_STR: c0000005EXCEPTION_PARAMETER1: 00000000EXCEPTION_PARAMETER2: 00000000STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong.008fe094 7ad808f4 008fe320 00000000 ec0d8f9b meeting_dashboard_module 0x34aa008fe214 7ad80617 008fe2f0 ec0d89ef 4ee246d8 desktop_common 0x108f4008fe460 7ad7f4d7 776f6873 008fe400 79641fe1 desktop_common 0x10617008fe5ec 7ad7ae62 008fe9d0 008fe76c 79bce43a desktop_common 0xf4d7008fe5f8 79bce43a 008fe6b8 a0f1fbb4 326aed58 desktop_common 0xae62008fe76c 7ad7de66 00000000 008fe9d0 ec0d8a63 wemeet_framework 0x2e43a008fe7ec 7ad7deed 00000000 008fe9d0 008fe808 desktop_common 0xde66008fe7fc 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 ; keax=008fdfe4 ebx=00000001 ecx=00000000 edx=2d692620 esi=3c4e1818 edi=3207f464eip=1c5b34aa esp=008fe034 ebp=008fe094 iopl=0 nv up ei pl nz ac pe nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010216meeting_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 0x34aa01 008fe214 7ad80617 desktop_common 0x108f402 008fe460 7ad7f4d7 desktop_common 0x1061703 008fe5ec 7ad7ae62 desktop_common 0xf4d704 008fe5f8 79bce43a desktop_common 0xae6205 008fe76c 7ad7de66 wemeet_framework 0x2e43a06 008fe7ec 7ad7deed desktop_common 0xde6607 008fe7fc 7ad7ae62 desktop_common 0xdeed08 008fe808 79bce43a desktop_common 0xae6209 008fe97c 79bc784c wemeet_framework 0x2e43a0a 008fe98c 79bc821f wemeet_framework 0x2784c0b 008fe9a0 79bdac53 wemeet_framework 0x2821f0c 008fea1c 79bdb791 wemeet_framework 0x3ac53...

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

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

0:000> ub 1c5b34aa L20meeting_dashboard_module 0x3449:1c5b3449 00c6 add dh,al1c5b344b 45 inc ebp1c5b344c b000 mov al,01c5b344e e8cde2ffff call meeting_dashboard_module 0x1720 (1c5b1720)1c5b3453 8d45b0 lea eax,[ebp-50h]1c5b3456 c645fc04 mov byte ptr [ebp-4],41c5b345a 50 push eax1c5b345b 8bce mov ecx,esi1c5b345d ff15a8cb611c call dword ptr [meeting_dashboard_module 0x6cba8 (1c61cba8)]1c5b3463 8d4db0 lea ecx,[ebp-50h]1c5b3466 8945c8 mov dword ptr [ebp-38h],eax1c5b3469 c645fc00 mov byte ptr [ebp-4],01c5b346d e8feebffff call meeting_dashboard_module 0x2070 (1c5b2070)1c5b3472 51 push ecx1c5b3473 8b4d0c mov ecx,dword ptr [ebp 0Ch]1c5b3476 8bd4 mov edx,esp1c5b3478 c7450c00000000 mov dword ptr [ebp 0Ch],01c5b347f 890a mov dword ptr [edx],ecx1c5b3481 8bcf mov ecx,edi1c5b3483 e8d8010000 call meeting_dashboard_module 0x3660 (1c5b3660)1c5b3488 837dc801 cmp dword ptr [ebp-38h],11c5b348c 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 11c5b3495 6a01 push 11c5b3497 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,eax1c5b34a1 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 L23207f46c ???????? ????????0:000> u 1c61c6ccmeeting_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 L1008fe05c 00000000

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

4. 为什么会返回 0

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

0:000> !tebTEB 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 lockSolution 2 – Repair your registrySolution 3 — Run a full system scanSolution 4 — Update your OSSolution 5 — Remove recently installed softwareSolution 6 — Uninstall Comodo Cleaner/ ASUS security data managerSolution 7 — Boot into Safe Mode

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

三：总结

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