如何治理 Electron 版本淘宝直播应用崩溃？

原创

于 2022-11-28 16:20:20 发布 · 3.1k 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#electron #前端 #windows #javascript #ecmascript

本文详细阐述了Electron框架下客户端应用崩溃的产生机制、Crashpad捕获上报、监控工具使用以及崩溃分析方法，包括雨燕平台与Visual Studio/WinDbgPreview的实战教程。

经过几个月的努力，基于Electron框架开发的新版淘宝直播推流软件终于上线了。随之而来的就是线上用户反馈的各种问题，其中最影响用户体验的当属应用崩溃问题了。当应用程序出现未 catch 的异常时就会发生崩溃，本文介绍了客户端应用崩溃的处理流程。

背景

主播前期花了很长时间精心策划了一场直播，在淘宝直播推流软件开播。当开播时间到来时，倒计时 3、2、1 后开始直播，一切都非常顺利。

但没想到刚直播了一会，突然弹出一个 “系统崩溃提醒” 弹框，提示应用崩溃了：

主播立马按照提示输入钉钉号提交崩溃信息，并且加入钉钉群反馈应用崩溃问题。作为技术小二的我发现显示一切正常，怎么在主播端运行就遇到崩溃问题了，一定是使用方法不对。

但首要关头得赶紧解决问题，并且以后要保证应用的稳定性。作为前端工程师的我尝试开始学习如何分析和解决应用崩溃问题。

在此之前，让我们先来了解下前端处理 js error 异常的整体流程：首先 js error 异常是如何产生的，其次要如何捕获上报 js error 异常，接着如何监控并分析 js error 异常堆栈，最后是如何运用 sourcemap 来定位到具体是哪个函数的哪一行代码引起的 error，以此来解决该异常问题。

了解完前端处理异常的流程后，我们接下来开始了解客户端应用程序处理崩溃异常的流程，下文均以 Windows 平台讲述内容。

应用崩溃是如何产生的

我们先来看下 Windows 系统的整体架构图，主要分为内核模式和用户模式。像常见的内核程序、设备驱动程序等运行在内核模式，而像系统服务进程、用户应用程序如淘宝直播主播工作台等运行在用户模式。

淘宝直播主播工作台地址：https://market.m.taobao.com/app/mtb/live-portal/download/index.html

当 Windows 系统或应用程序调用 CreateProcess 函数启动主线程或 CreateThread 启动线程时，线程函数会在如下代码中运行（下面的代码引自《Windows 核心编程》第 25 章未处理异常和 C++ 异常）：

// 主线程启动函数
// CreateProcess 启动线程函数
VOID BaseProcessStart(PPROCESS_START_ROUTINE pfnSatrtAddr)
{
    __try {
        ExitThread((pfnSatrtAddr)());
  }
    __except(UnHandledExceptionFilter(GetExceptionInformation())) {
        ExitProcess(GetExceptionCode());
    }
}


// CreateThread 启动线程函数
VOID BaseThreadStart(PTHREAD_START_ROUTINE pfnSatrtAddr, PVOID pvParam)
{
    __try {
        ExitThread((pfnSatrtAddr)());
  }
    __except(UnHandledExceptionFilter(GetExceptionInformation())) {
        ExitProcess(GetExceptionCode());
    }
}

从上面的代码可以看出，当线程运行中出现未捕获异常时，会调用 UnHandledExceptionFilter 函数来过滤异常信息，然后调用 ExitProcess 函数退出进程的运行。也就是说，当线程中出现未 catch 的异常（类比前端 js error 未 catch）时，比如主播在使用绿幕大屏添加超大尺寸图片时应用程序 memcpy 失败但未 catch 异常导致崩溃、系统内核异常导致蓝屏现象，系统 / 程序就会崩溃并生成 dump 文件来帮忙寻找异常原因。

那 dump 文件究竟是什么呢？Windows 平台 dump 文件分为两大类：内核模式 dump 和用户模式 dump。内核模式 dump 是操作系统创建的崩溃转储，最经典的就是系统蓝屏时会自动创建内核模式的 dump。用户模式 dump 进一步可以分为 fulldump 和minidump。fulldump 包含了某个进程完整的地址空间数据，以及许多用于调试的堆栈、寄存器等信息。毫无疑问，这样的 fulldump 对于事后调试非常有价值，但由于文件太大（几G字节）使得通过请求发送给开发者非常困难。而 minidump 则有许多类型，按照最常用的配置只包括了最必要的信息，用于恢复故障进程的所有线程的调用堆栈，以及查看故障时刻局部变量的值。这样的 minidump 文件通常很小（只有几K ~ 几M字节），通过请求发送给开发者非常容易。