[译]《iOS Crash Dump Analysis》- 分析性故障排除

点赞评论，感觉有用的朋友可以关注笔者公众号 iOS 成长指北，持续更新
原书为 iOS Crash Dump Analysis Book，已得作者授权，欢迎 star

本章将讨论一个解决问题的正式技巧。这个技巧是提供一个询问正确问题的框架。

有一个著名的俗语告诫我们不要过渡狂热：

“不要用大锤去砸螺母。”

大多数问题都有直接而明显的解决方法。作为工程师、开发人员和测试人员，我们对解决问题都非常熟悉。然而，本章并不涉及那些类型的问题。

还有另外一个不太知名的俗语：

“当您拿着锤子时，一切看起来都像钉子。”

锤子最适合钉钉子，通常也可以砸东西，但是对其他的可能并不有用。锤子是对某种问题的解决方案。此外，我们思考问题的方式可以由一些技巧组成。如果我们增加可用的技巧，开始以不同的方式去思考问题，其中可能有一种方式会让我们获得我们想要的答案。

如果我们的工具箱中有一把扳手和一把钢锯。我们想拆除一个已生锈螺栓固定的旧浴室配件。由于螺栓无法转动，因此可能无法使用扳手。但是，使用钢锯锯掉螺栓头可能是一个可行的次佳解决方案。 通过观察有经验的水管工人或技工，就会发现这种技巧。

在这种情况下，我们将介绍“分析故障排除”。当我们用尽所有方法并且已经尝试了一些常见手段之后，本章将帮助我们推进解决问题。

这个方法是 Kepner Tregoe 方法 的简化版本。

优先考虑自己的问题

如果我们是一个应用程序（可能只有很少的用户）的唯一开发者，当我们收到崩溃报告时，可能会感到我们正在面临着一场好奇的智力挑战。

在专业的软件工程环境中，实际情况截然不同。通常会有一个团队进行统筹处理，对于不同客户进行优先级筛选，并且针对不同的产品和产品变形，来自不同客户的崩溃报告也很多。

我们必须确定要处理的崩溃的优先级。我们将从三个方法来思考问题：严重性、紧迫性和成长性。

根据影响确定优先级

对许多开发团队来说，崩溃是最重要的“P1”级别的错误，因为客户无法再使用应用程序做任何事情。为了要判断问题的严重性，我们首先要评估问题的 影响。问题发生时，用户正在做些什么？

如果客户正在进行商品购买，那么如果不能解决问题，显然我们的收入将受到影响。

如果是在更新我们的隐私设置时发生了崩溃，则表明存在对应设置的隐私问题。根据我们产品的具体类型，这可能是一个主要问题。

在我们的应用中内置分析工具，是评估影响的一种方法。然后可以在崩溃的同时分析这些步骤，更广泛的说是客户用例。然后，可以将最多最广泛的崩溃用例确定为最需要修复的崩溃问题。第三方崩溃报告集成服务的一项优势就是它们允许记录日志并与崩溃报告一起发送到崩溃报告服务器。

以下是日志可以记录的一些好的点：

• 任何生命周期发生的时间，前台、后台、页面出现、页面消失

• 按钮点击

• 跳转

• 通知

• 弹出提醒

• 调用诸如照片选择器之类的辅助组件

根据截止日期确定优先级

为了判断错误修复的紧迫性，我们需要评估与该错误相关的 截止日期。每当 Apple 更新产品线时（例如，每年 9月 iPhone 都会迭代新机型），市面上的应用程序都会进入一个自然而然的迭代期。新的用户将会去 App Store 下载新的应用。媒体上将会有很多关于 Apple 产品功能的讨论。因此，它被标记成一个良好的市场窗口。此时，任何会导致应用商店审核失败或应用首次使用的崩溃问题都变得越来越重要。Apple 有时会引入一个新的应用类别，例如手表应用或贴纸包。在第一天就可以使用，就会具有先发优势，甚至有可能成为 Apple 发布活动的一部分。

根据趋势确定优先级

当我们看到崩溃报告数量的增长令人震惊，需要通过分析 趋势 来进行评估。我们可以查看随着时间的推移获得的崩溃报告数量，并查看是否存在峰值或上升趋势。

如果我们的应用程序由于 iOS 新版本中的功能而崩溃，那么最早遇到该问题的人就是更新了 iOS Beta 版的用户。之后，iOS 设备就会开始自动升级。有事，iOS 新版本将会以地理位置分段交错更新。我们希望这会在崩溃报告中所看到的趋势中得到反映。

如果我们在崩溃报告中看到一个峰值（先升后降），那么可能还有其他影响系统架构组件的因素。 例如，如果我们的应用程序依赖于后端服务器，该后端服务器为我们的应用程序以一种有问题的方式更新，则在修复服务器之前，我们可能会看到崩溃。

有时问题的时机可能很尴尬。例如，当要处理例如证书之类的安全凭证时，最好不要将其到期日期设置在传统假期中，例如圣诞节或农历新年，因为当它们到期时，可能没有人力来更新或者替换。

在热门假期之间发布重要的软件更新是极其不明智的做法。如果我们的产品需要来迎合假期间各种热点，那么就需要人力来处理相应的问题。

密切关注趋势，在崩溃更广泛的传播之前，我们能够得以安排工作并解决问题。不同的应用程序具有不同的风险状况。例如，对移动设备管理 API 敏感的应用程序应使用 iOS Beta 版本进行测试，因为对系统级别来说，细微的更改可能会产生巨大的影响，所以需要今早的进行测试。如果我们有一个对绘制敏感的应用程序，那么我们则应该关注新的硬件设备、硬件规格的更新，挺尸我们应该有一个整体的测试框架，该框架可以测试我们所依赖平台中的关键 API，因此可以对新的 OS 版本或硬件平台进行快速评估。

崩溃报告趋势不一定是不利的。如果仅在交旧的硬件版本上看到异常崩溃，呢么我们预计趋势会随着时间的推移而下降，因此有可能取消对此类崩溃问题的优先级。

说明问题

我们提供的崩溃信息有：崩溃报告，客户日志，分析数据等。应该总结为 OBJECT / DEFECT 风格的简短问题陈述。这通常是分担潜在大量崩溃报告的关键的第一步。这使得我们对问题有了第一手的资料，并使管理人员和其他有关方面可以了解我们在产品质量，成熟度，风险等方面的状况。

首先，我们陈述问题的对象。 那就是应用程序或产品失败了。 然后，我们指出缺陷。 这就是我们看到的“不良行为”。 它应该像“使用 Apple Share 按钮时 CameraApp Lite 发生崩溃”那样简单。 并且应该在错误管理系统中跟踪该问题。

指出问题

在分析故障排除方法中，指定问题是最重要的一步，因为我们在这里看到了我们认知上盲区，这就提示了问题，这些问题会引导我们找到解决方案。

我们写出一个有四行两列的表格，如下所示：

Item	IS	IS NOT
WHAT	Seen	Not Seen
WHERE	Seen	Not Seen
WHEN	Seen	Not Seen
EXTENT	Seen	Not Seen

对一个团队来说，分析性故障排除很有效果。通过一些领域专业人员（专家），以及来自其他领域的人员和非技术人员，我们可以组建一个优秀的故障排除团队。专家有时会忽略问基本的问题，而不太了解情况的员工可以问清楚问题，从而进一步露出问题中的隐藏假设。棘手的客户问题让人干到焦虑，所以让团队聚在一起解决问题可以缓解紧张气氛，提高士气。有时可以邀请我们的客户参加； 这通常可以加快过程，甚至提出更多的假设。

当作为一个团队进行故障排除时，我们可以使用一块白板，将其分成一个表格，如上所述。每个人都可以得到一份讲义，列出表格中每条每列要问的问题。

与本书相关的网站上有用于分析故障排除的辅助材料和讲义。

当我们自己进行故障排除时，列出所有问题并将它们填入表格是一种很好的方法。远离电脑（或代码层面），列举出要检查的项目清单是很好的，因为这样可以消除深入研究细节的直接冲动。 相反，一旦有了要跟踪的项目清单，就可以确定工作的优先级。

我们首先在 IS 列中填写详细信息。然后，我们填写 IS NOT 列。通常，我们会注意到网格中没有数据的空白区域。这是一个信号，让我们去收集更多的数据或做更多的研究。这样做的目的是使 IS 和IS NOT 列之间的相关差异尽可能小。这使我们能够得到一个可以测试的好假设，或者是可以优先被考虑测试的一些假设。

任何可能的问题解决方案都必须 完全 解释问题规范中的 IS 和 IS NOT 部分。通常，我们想到的第一个解决方案只能解释了问题规范中的部分问题。多花一点时间思考潜在的原因，或者多做一点研究，都是很好的时间投资，尤其是当尝试不同的备选解决方案很困难或者很耗时的时候。

我们将了解系统规范及其在这些约束下运行时的行为。事实上，随着新软件和硬件的发布，系统会随着时间的推移而发展。因此，我们必须重复处理主要的信息源，并进行实验来完善这种理解。这使我们能够发现良好的问题，并使我们能够提出相关假设。在提出问题，了解我们的系统，然后发现新的相关问题之间通常有一个积极的反馈循环。

如何提问

• WHAT IS

  • 什么出现了问题？

  • 出现了怎样的问题？

• WHAT IS NOT

  • 哪些（版本、设备、情况等）可能出现问题但是没有？

  • 哪些可能的故障并没有一并出来？

• WHERE IS

  • 当发现问题时，其地理位置在哪里？

  • 问题出在哪里？

• WHERE IS NOT

  • 当我们本该看到问题却没有看到，那么问题在哪里？

  • 问题可能出现在什么地方，但是并没有

• WHEN IS

  • 第一次发现问题是什么时候？

  • 什么时候问题又出现了？

  • 时间上有什么规律吗？

  • 在事物的生命周期中某个时候才首次发现问题？

• WHEN IS NOT

  • 什么时候应该可以发现问题，但并没有？

  • 什么时候问题应该复现，但并没有？

  • 在事物的生命周期中的某个时候应该可以看到问题，但并没有？

• EXTENT IS

  • 这样问题到底有多少？

  • 缺陷的程度如何？

  • 这个问题有哪些缺陷？

  • 发展的趋势是怎样？

• EXTENT IS NOT

  • 有哪些情况可能也有这个问题，但实际上没有？

  • 问题可能严重到什么程度，但实际上不是？

  • 可能存在多少缺陷，但实际上没有？

  • 问题的趋势应该是怎样，但实际上不是？

问题范例

首先，问题说明问题似乎并不常见，而且措辞笨拙。 查看一些实际示例有助于更清楚地解释事情。 这里将使用不同的假设示例来专注于特定问题，但是为了简洁起见，我们不会在任何给定示例上列举全部问题。

CameraApp What Is / Is Not 示例

思考一下这个问题：“客户按下 Apple 共享按钮时，相机应用程序崩溃”

• WHAT IS

  • What things have a problem?

    • iOS 10.1、10.2、10.3上的 1.4.5 版本的 CameraApp。

    • 在主线程中

    • 方法 isAllowedToShare()

    • Apple 的共享按钮

  • What is wrong with them?

    • 共享按钮导致应用崩溃。

• WHAT IS NOT

  • What things could have a problem but don't?

    • iOS 9.3.5 上的 1.4.4 版本的 CameraApp。

    • 后台线程从来没发生崩溃。

    • 其他功能和拍照功能正常。

    • 拍照按钮正常工作。

  • What could be wrong but is not?

    • 其他按钮可能会导致崩溃，但可以正常工作。

    • 我们没有看到任何系统弹出错误。

为了取得进展，我们需要配合并收紧IS和IS NOT答案。 我们首先看一下 IS NOT 部分，因为它通常是表格的一面，相当空泛，需要一些思想和启发才能得出与 IS 部分相关的额外 IS NOT 答案。

显而易见的事情是，应用程序版本 1.4.4 是否可以在 iOS 10.x上运行。

iOS 10.x是iOS 9.3.5的主要更新，因此其规范和对应用程序的要求将有所不同。 因此，接下来要看的是Apple文档中的 What's New 部分，从更高的角度查看iOS 10.x over 9.x的新增功能。 这将促使我们提出更为清晰的问题。

如果 10.x 要求应用程序具有某些 Info.plist 设置，则可以在上方的表格中并没有解释相机应用程序中的任何 Info.plist 差异，以及与其他已知可用的应用程序的 Info.plist 在执行共享的 iOS 10.x 和 9.x上的差异。

在此示例中，共享按钮是有问题的。 我们可以获得使用共享按钮的一些示例代码，并查看它是否在与我们的问题类似的环境中崩溃。 我们可以在独立的应用程序中测试代码，也可以将其移植到我们的 Camera App 中以查看其是否可以正常工作。

在此示例中，我们只说系统并未弹出窗口。那么控制台消息如何？ 我们可能会发现系统告诉我们系统崩溃我们的应用程序的原因。

候选解决方案将是 “iOS 10.x需要不同的 Info.plist 设置才能正常工作，否则如我们所见，系统将指定使我们的应用程序崩溃。”

iMac Where Is / Is Not 示例

思考一下这个问题：“ iMac 经常崩溃，需要不断地进行硬件维修。”

• WHERE IS

  • When the problem was noticed, where was it geographically?

    • 放置在一楼转角处靠窗的的一台 Apple iMac。

  • Where is the problem on the thing?

    • 问题出在电源，屏幕，主系统板和内存芯片上的电气故障（多次出现问题）。

• WHERE IS NOT

  • Where could the thing be when we should have seen the problem but did not?

    • 相同的 Apple iMac 放在地下室，在 IT 部门登台区域以及在 Apple 工厂进行测试时都很好。

  • Where could the problem be on the thing but isn't?

    • 问题可能出在软件中，但不是。

    • 问题可能出在USB外设上，但不是。

    • 问题可能是打印机，台灯，照明灯或空调出现电气故障，但不是。

    • 问题可能出在办公桌抽屉中的笔记本电脑上了，但事实并非如此。

在此示例中， IS NOT 列中有许多项。立刻让我们感觉像是可以因此考虑好的假设。 与此相反，在前面的示例中，WHAT IS NOT 部分中，我们在提出假设之前必须进行大量研究。

我们注意到只有iMac有问题，而打印机没有问题。那么如果我们交换打印机和iMac的位置，因为它们都是敏感的电子产品，我们可以在 IS 和 IS NOT 之间获得很好的对比。

电子设备只能在特定的特定环境条件下运行。 需要正确的电压，电流，温度，湿度，有限的电磁干扰等。 如果我们在进行现场调查时考虑到此类需求规范，则可以发现造成此特定位置问题的原因。 我们也可以尝试使用电涌保护器，也可以不使用电涌保护器，因为众所周知，电源尖峰会损坏电子设备。

数据库应用 When Is / Is Not 示例

思考一下这个问题：”应用审查期间一个数据库应用崩溃“

• WHEN IS

  • When was the problem first noticed?

    • 我们第一次发现此问题 App Store 应用审核期间。

  • When has the problem been seen again?

    • 第二次是我们将该应用提交审核。

  • Is there any pattern in the timing?

    • 启动应用后，问题发生的时间相同。

  • When in the lifecycle of the thing was the problem first noticed?

    • 问题始终在应用启动过程中。

• WHEN IS NOT

  • When could the problem have been noticed but wasn't?

    • 开发人员在开发环境中从未见过该问题。

  • When could it have been seen again but wasn't?

    • 随后启动该应用程序也运行的很好。

  • When else in the lifecycle of the thing could the problem be seen but wasn't?

    • 在应用程序中按更新按钮或更改目标数据库连接字符串时，未发现问题。

显然，这是一个应用程序启动问题。 这个例子强调了有时候一个领域的问题会触发另一个领域的问题和研究。 对于 WHAT IS / IS NOT 部分来说，环境的干净程度以及启动环境的配置状态是显而易见的问题。

在 WHEN is NOT 部分发现了一条线索。可以设置和重新配置数据库连接字符串。可能是一个空连接字符串，或者缺少设置，或者没有触发第一次使用的设置代码。也许调试版本的代码会跳过第一次使用的工作流来加速功能开发，但是这些功能在用于应用商店审查的应用程序的发布部署中并不存在。

游戏应用 Extent Is / Is Not 示例

思考一下这个问题：”在游戏的不同级别（关卡或者等级），AlienGame 应用都会出现性能问题/崩溃“

• EXTENT IS

  • How many things have the problem?

    • 500个安装了该应用不同设备，总共有2000个。

  • What is the extent of the defect?

    • 有时很严重； 崩溃了。有时很温和；掉帧了。

    • 有时帧率始终保持良好状态。

  • How many defects are on the thing?

    • 5 种不同类型的游戏渲染线程最终会崩溃（在不同情况下）。

  • What is the trend?

    • 随着我们的安装量的增长，崩溃数量略有下降的趋势。

• EXTENT IS NOT

  • How many things could have the problem but don't?

    • 所有已安装或未安装的设备都有这个问题，但是目前我们看到的是25%。

  • What could be the extent of the problem but isn't?

    • 我们从来没有看到帧率下降然后提高。

    • 我们从来没有见过好的安装程序能够解决崩溃问题或掉帧问题。

  • How many defects could be present but aren't?

    • 我们从没看过主线程崩溃。

    • 在 6 种类型的渲染线程中，有一种是特殊的，因为它从未在崩溃或帧率下降过程中出现过。

  • What could the trend be but isn't?

    • 趋势可能由崩溃变得越来越普遍（超过25％），但没有。

    • 趋势可能是崩溃仅在某些日子发生，但事实并非如此。

这个例子很难理解。 我们需要了解应用程序的架构才能提出好的问题。 一些线索出现了。 渲染线程有6种类型，其中一种很好。 另外，主线程很好。 我们需要探索线程之间的相关差异。

当我们遇到的问题并不总是发生时，一种策略是考虑可以采取什么措施使问题变得更糟，从而更频繁地发生。 然后，当我们有一个候选解决方案时，我们可以设置一个置信度阈值（没有看到失败的迭代次数），并在使问题更有可能出现的特殊环境中针对这个阈值测试修复。

另一个线索是 25％ 的用户设备有问题。 如果问题是由于使用不同的硬件而导致的，因此硬件功能各不相同，那么我们可以看到大约有25％ 的用户使用 iPad 而不是 iPhone。 但是，严格说来这 25％ 的问题并没有明确告诉我们，环境中的其他因素可能会影响应用程序的行为。也许在安装过程中，服务器是在托管游戏后端的四台服务器中以循环方式选择的。 此外，在开发过程中，使用的服务器也许是与我们的客户使用的生产服务器不同的特殊开发服务器。 同样，IS NOT 部分提供了有关在哪里寻找潜在解决方案的最有启发性的线索。

如果我们不进行分析性故障排除，则在此示例中，第一个本能将是检查内存泄漏，内存压力，硬件限制等。这种分析很容易会花费一周的工程时间。 虽然此类问题有可能导致丢帧而无法完全解释我们所看到的缺陷模式； 他们不会解释为什么恰好有25％的用户遇到了这个问题。

2018 MacBook Pro T2 的问题

本节描述了 2018 款 MacBook Pro 电脑崩溃的问题 叙述来自受影响用户的讨论组发布和媒体报道

问题描述： 2018 MacBook Pro 计算机在休眠期间因 Bridge OS 错误而崩溃。

• WHAT IS

  • What things have a problem?

    • MacBook Pro Mid 2018 (13-inch, 15-inch)

    • iMac Pro

    • iBridge2,1

    • iBridge2,3

    • 连接了 USB 外接设备的配置实例

    • 没有外接 USB 设备的配置实例，从休眠中唤醒

    • 没有外接USB 设备而是连接电源适配器的配置实例，从休眠中唤醒

    • 具有旧版内核扩展的配置实例（xbox控制器）

    • 删除了xboxcontroller的配置实例（较少崩溃）

    • macOS High Sierra 10.13.6，带有补充更新，来自抹除磁盘和全新安装

    • 休眠期间发生崩溃

    • panic: ANS2 Recoverable Panic - assert failed

    • panic: macOS watchdog detected

    • panic: x86 global reset detected

    • panic: x86 CPU CATERR detected

    • 具有 DiskUtility->First Aid crypto_val 错误的实例

    • 具有抹除磁盘以消除 crypto_val 错误的实例

    • 使用相同的客户配置但是完全替换了 MacBook Pro 硬件

    • 在 2018 MacBook Pro 中禁用了 Power Nap

    • 不触摸触控栏仍存在休眠/唤醒问题

  • What is wrong with them?

    • 系统在Bridge OS 出问题后重新启动

    • 电脑发烫

    • 磁盘检查失败

    • 外接设备被虚假唤醒

• WHAT IS NOT

  • What things could have a problem but don't?

    • MacBook Pro Mid 2017 models or older MacBook Pros

    • iBridge1,1

    • MacBook Pro booted in Safe Mode

    • iPad, iPhone, Apple Watch

  • What could be wrong but is not?

    • 在电脑运行时从未出现问题

    • 在引导过程中从来没有问题

    • 当用户关闭系统后，从未出现问题

• WHERE IS

  • When the problem was noticed, where was it geographically?

    • 在客户处

    • 在书桌上和手提电脑包中

  • Where is the problem on the thing?

    • 在T2芯片（源自watchOS）中的BridgeOS操作系统软件

• WHERE IS NOT

  • Where could the thing be when we should have seen the problem but did not?

    • Apple 硬件验证工具（大概-只有Apple知道）

  • Where could the problem be on the thing but isn't?

    • 在主 CPU 或主板上

    • 在引导加载程序上

    • 在多媒体芯片和网络芯片上（它们都有自己的操作系统）

• WHEN IS

  • When was the problem first noticed?

    • 大约30分钟的休眠后，然后唤醒计算机

  • When has the problem been seen again?

    • 随机，大概一天一次或一周五次

  • Is there any pattern in the timing?

    • 至少在运行 30 分钟后，进入休眠状态

  • When in the lifecycle of the thing was the problem first noticed?

    • 客户购买并安装软件后

    • 重新安装后

    • 重新抹除磁盘并安装后

• WHEN IS NOT

  • When could the problem have been noticed but wasn't?

    • 在 Apple 的组装和验证机构（大概-只有Apple知道）

  • When could it have been seen again but wasn't?

    • 退回设备的退货部门（大概-只有Apple知道）

  • When else in the lifecycle of the thing could the problem be seen but wasn't?

    • 主动使用计算机期间从未休眠

• EXTENT IS

  • How many things have the problem?

    • 通过间接测量，在 iMac Pro 服务退货中，在 103 个中有 4个发现此问题

  • What is the extent of the defect?

    • 内核问题，看起来是一种内核问题，可能有三种

  • How many defects are on the thing?

    • 单实例内核紧急故障

  • What is the trend?

    • 在未来的随机休眠期后再次重复，有时不使用外围设备时复现的频率较低

• EXTENT IS NOT

  • How many things could have the problem but don't?

    • 有一个引导加载程序，主操作系统和其他电子部件，它们从未出现问题

  • What could be the extent of the problem but isn't?

    • 故障崩溃后可能会持续发生故障，但这没有看到。

    • 每台机器可能会出现一次故障，但又会再次出现故障

  • How many defects could be present but aren't?

    • 可能是警告或信息性消息，但我们只发现故障

  • What could the trend be but isn't?

    • 每个客户的问题都是随机发生的，但从未增加或减少

故障分析

以上信息类似于我们在困难问题中经常看到的信息。 WHAT IS 列中有很多数据。

首要的主要结论是问题必须出在 iMac Pro 和 MacBook Pro 中使用的较新的 T2 芯片。 缺陷的模式和实际的故障（在 T2 芯片上运行的Bridge OS 中）清楚地表明了这一点。

第二点是失败的数量很少。与 MacBook Pro 相比，iMac Pro 是小批量计算机，因此该问题很可能在 iMac Pro 生产过程中曾出现过，但这并不是由于它发生故障的可能性很小。

我们看到问题永远不会在启动，有序关闭或频繁使用期间发生。 这很有趣，因为在硬件验证期间，通常会对计算机进行压力测试以解决问题。 它们通常不会处于睡眠状态以查看它们是否仍执行唤醒功能。 因此，可能存在测试策略问题。

对于客户来说，替换硬件后仍然存在相同的问题。 这是一个有用的信息，因为它表明了缺陷的稳定性。 随着时间的流逝，Apple 将收集已知有问题的计算机，因此可以进行验证的有缺陷的计算机数量将大大改善。

上述数据集的主要缺陷是没有 pmset日志。 这是提供详细的睡眠/唤醒行为日志。

潜在的关键数据点是使用安全模式启动的客户从未发现此问题。 那么关于 Bridge OS 的行为，安全模式启动有什么特别之处吗？

看来30分钟是睡眠时间的关键指标。那么 30 分钟时可能会有一个阈值，也许要进入深度休眠而不是浅休眠。

理解该问题的一种策略是使其更频繁地发生。 例如，通过手段有可能使计算机非常快速地进入深度休眠状态。 这就会使问题在 30 秒后出现，而不是在 30 分钟的休眠后随机出现。

如果可以使问题更加频繁，则可以编写自动系统测试。 然后，对 Bridge OS 的任何修复都将具有强大的测试组件来对其进行验证。

我们没有 Bridge OS 的源代码。所以辨别所看到的三个崩溃之间的差异将很有趣。 例如，有时有一个案例陈述包含 20 种可能的故障，而仅输入一个。这揭示了有关问题规范中 WHERE IS NOT 的信息。

我们没有故障机器的寄存器信息。 当发生底层问题时，处理器文档将使系统架构师可以准确地查找故障的种类（超时，奇偶校验错误等）。在我们的问题规范中，我们需要更精确地确定问题所在 WHERE。 BridgeOS 可能只是一个金丝雀，告诉我们其他地方的问题。 一些客户已收到完整的硬件更换，但仍然看到问题。 则表明是软件问题。

英特尔已经描述了其架构的更新，该更新中可以发送 CATERR 信号而不是 IERR 或 MCERR。因此，规范的更新可能意味着系统软件不再兼容，因此 Bridge OS 需要更新。

一种方法是遵循英特尔调试指南。它有很多好的建议。 当BridgeOS遇到问题时，应进行更新寄存器以打印出相关的诊断。

感谢你阅读本文！