28、软件调试中的错误报告与分析工具-优快云博客

本文链接：https://blog.youkuaiyun.com/ipfs8storage/article/details/156044170

软件调试中的错误报告与分析工具

1. Windows Error Reporting 与 Corporate Error Reporting

1.1 Windows Error Reporting 概述

Windows Error Reporting（WER）是一项强大的服务，它能让开发者监控应用程序在实际环境中的运行状况。当用户遇到与响应关联的故障时，会看到特定的对话框。若用户点击“更多信息”链接，将被引导至包含故障响应及解决问题相关信息的网页，例如 http://www.advancedwindowsdebugging.com 。

1.2 Corporate Error Reporting 背景与原理

部分独立软件供应商（ISV）因错误信息可能包含敏感数据，不愿将其发送给微软。为满足这一需求，微软推出了 Corporate Error Reporting（CER）。CER 允许 ISV 在公司范围内启用错误报告，并指示每台机器将信息发送到文件共享，而非微软。之后可定期查询文件共享，以发现可能出现的问题。

1.3 设置 Corporate Error Reporting

1.3.1 前提条件

需使用 Windows XP 专业版或更高版本，因为 Windows 家庭版没有组策略（Group Policy，GP）功能。GP 是 Windows 中用于在 Active Directory 环境下对计算机和用户进行集中管理的技术，CER 是其管理功能的一部分。

1.3.2 设置步骤

打开组策略编辑工具：点击“开始” - “运行”，输入“gpedit.msc”，打开 GP 微软管理控制台（MMC）插件。
访问 CER 设置：在左侧导航窗格中，通过“本地计算机策略” - “计算机配置” - “管理模板” - “系统” - “错误报告”访问 CER 设置。
配置显示错误通知选项：该选项可控制遇到错误的用户是否看到 UI，若启用，用户可访问错误信息；若“配置错误报告”也开启，用户还能发送错误报告。
配置错误报告设置：这是 CER 配置的主要部分，具体选项如下：
- 启用、禁用或不配置错误报告。
- 若启用，可配置以下选项：
  - “不显示任何微软提供的‘更多信息’网站链接”：禁用错误 UI 中的微软链接。
  - “不收集其他文件”：不收集错误报告中的额外信息文件。
  - “不收集其他机器数据”：不收集错误报告中的额外机器数据。
  - “强制应用程序错误的队列模式”：用户无法立即发送错误报告，所有报告将排队，待管理员登录时选择发送。
  - “公司文件路径”：输入用于 CER 的 UNC 路径，所有错误报告将存储在此，确保报告错误的机器有写入权限。
  - “用以下内容替换‘微软’一词”：自定义错误对话框，将“微软”替换为其他内容。
高级错误报告设置：
- “默认应用程序报告”：控制哪些应用程序参与错误报告。
- “始终报告错误的应用程序列表”：指定始终参与错误报告的应用程序。
- “从不报告错误的应用程序列表”：指定从不参与错误报告的应用程序。
- “报告操作系统错误”：控制操作系统组件是否参与错误报告。
- “报告意外关机事件”：控制意外关机事件是否参与错误报告。

1.4 使用 Corporate Error Reporting 报告错误

1.4.1 示例应用

使用“awdscenario1.exe”应用，路径为“C:\AWDBIN\WinXP.x86.chk\awdscenario1.exe”。当出现 Dr. Watson 错误 UI 时，点击“发送”按钮，错误报告将存储在配置 CER 时指定的路径，如“C:\AWD\Chapter13\CER”。

1.4.2 文件组织

CER 在错误报告文件夹下组织文件，首次生成错误报告时会创建两个主要文件夹：
1. “Cabs”：包含实际错误信息，如转储文件和相关错误信息。
2. “Counts”：包含每个故障的命中计数，文件为文本文件，包含两个计数，分别表示为此故障收集的 Cabs 数量和该特定故障的命中记录数量。

每个文件夹下会创建嵌套文件夹层次结构，唯一标识特定故障，依据以下属性：
- 映像名称
- 映像版本
- 模块名称
- 模块版本
- 偏移量

1.4.3 解压文件

每个故障的 Cab 目录的叶子文件夹中有一个压缩的 cab 文件，解压后得到三个文件：
1. 小型转储文件：表示故障发生时进程的状态。
2. “Version.txt”：包含进程运行的操作系统版本。
3. 应用程序兼容性文件：一个 XML 文件，包含失败进程的属性列表。

1.5 调试示例

提取示例运行生成的 CAB 文件中的文件，并使用调试器附加到转储文件（使用 -z 开关）。以下是调试会话的部分示例：

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(f0f0f0f0.6fc): Access violation - code c0000005 (first/second chance not available)
eax=007b0000 ebx=0006ddec ecx=00001000 edx=7c90eb94 esi=00000000 edi=7ffdd000
eip=7c90eb94 esp=0006ddc4 ebp=0006de60 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
Unable to load image D:\WINDOWS\system32\ntdll.dll, Win32 error 2
*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
ntdll+0xeb94:
7c90eb94 c3              ret
0:000> .ecxr
eax=00000000 ebx=7ffdd000 ecx=77c418bf edx=77c61b78 esi=01c709ef edi=a32cec54
eip=0100127e esp=0006ff1c ebp=0006ff44 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
awdscenario1!wmain+0xbe:
0100127e c60000          mov     byte ptr [eax],0           ds:0023:00000000=??
0:000> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  Args to Child
0006ff44 01001495 00000001 00263798 00264160 awdscenario1!wmain+0xbe
0006ffc0 7c816d4f a32cec54 01c709ef 7ffdd000 awdscenario1!wmainCRTStartup+0x12f
0006fff0 00000000 01001366 00000000 00000000 kernel32!BaseProcessStart+0x23
0:000> u awdscenario1!wmain+0xbe
awdscenario1!wmain+0xbe:
0100127e c60000          mov     byte ptr [eax],0
01001281 eb0e            jmp     awdscenario1!wmain+0xd1 (01001291)
01001283 68a4100001      push    offset awdscenario1!`string’ (010010a4)
01001288 ff1544100001    call    dword ptr [awdscenario1!_imp__printf (01001044)]
0100128e 83c404          add     esp,4
01001291 688c100001      push    offset awdscenario1!`string’ (0100108c)
01001296 ff1544100001    call    dword ptr [awdscenario1!_imp__printf (01001044)]
0100129c 83c404          add     esp,4

1.6 总结

CER 是一种强大的机制，可通过组策略启用，使公司能够将所有错误报告保留在本地进行进一步分析，也可根据配置将选定的错误报告发送给微软。

2. 调试诊断工具

2.1 工具概述

调试诊断工具（Debug Diagnostic Tool，DebugDiag）最初用于分析和调试 Internet Information Server（IIS）的问题，如崩溃、挂起和内存泄漏。它功能强大，具有易于使用的 UI、出色的分析能力（通过分析脚本）和可扩展性模型，支持大型对象模型，便于开发自定义分析脚本。

2.2 工具组件

DebugDiag 由四个主要组件组成：
1. 服务（Service）：调试器服务进程（dbgsvc.exe）是核心，负责控制被调试的进程、性能监控、启用内存泄漏检测等。
2. 主机（Host）：调试器主机（dbghost.exe）是调试引擎，支持通过自动化脚本进行实时调试和事后调试。
3. 用户界面（User Interface）：DebugDiag 工具的 UI。
4. 泄漏跟踪器（Leak tracker）：负责跟踪内存泄漏，以 DLL（leaktrack.dll）形式实现，注入被监控进程以跟踪内存分配及其关联的调用栈。

2.3 使用场景（规则）

DebugDiag 有三种主要使用场景（规则）：
1. 崩溃（Crash）：分析进程崩溃。
2. 挂起（Hang）：分析挂起的 IIS 进程。
3. 泄漏（Leaks）：分析泄漏的资源，如内存和/或句柄。

2.4 工具获取与安装

可从以下位置获取 2006 年 1 月版本的工具：http://www.microsoft.com/downloads/details.aspx?familyid=9BFA49BC-376B-4A54-95AA-73C9156706E7&displaylang=en 。安装简单，除非要选择特定工具，否则典型安装即可。可通过“开始” - “所有程序” - “IIS 诊断” - “调试诊断工具” - “调试诊断工具 1.0”启动。

2.5 分析内存或句柄泄漏

2.5.1 示例应用

使用“09BasicMLeak.exe”应用，源代码路径为“C:\AWD\Chapter9\BasicMLeak\Client”，二进制文件路径为“C:\AWDBIN\WinXP.x86.chk\09BasicMLeak.exe”。命令行参数为“09BasicMLeak.exe /t:50 /i:2000 /s:0”，表示应用程序以 50 个线程运行，每个线程 2000 次迭代，迭代间无睡眠时间。运行该应用时，会发现内存消耗上升且不下降。

2.5.2 配置 DebugDiag

重启应用程序，当出现“Press any key to start stress application”时，启动 DebugDiag。
在向导中，选择“内存和句柄泄漏”单选按钮，点击“下一步”。
选择要分析的进程“09BasicMLeak.exe”，点击“下一步”。
配置内存和句柄泄漏跟踪选项：
- 预热时间（Warm-Up Time）：默认内存跟踪在规则激活后立即开始，可取消复选框并在编辑字段中指定开始时间。
- 跟踪时间（Tracking Time）：默认跟踪时间为 60 分钟。
- 自动创建崩溃规则（Auto-Create Crash Rule）：若选中，进程意外退出时创建转储文件。
- 自动卸载（Auto-Unload）：若选中，内存跟踪完成后自动卸载 leaktrack.dll。
保留默认值，点击“下一步”。
为新规则命名为“Stress”，保留转储文件位置为默认值，点击“完成”保存并激活规则。

2.5.3 分析结果

运行示例应用并让其终止后，回到 DebugDiag 主窗口，点击“分析”按钮，在浏览器中查看内存跟踪结果。报告分为两个主要部分：
1. 分析摘要（Analysis Summary）：包含分析过程中发现的问题摘要表，显示所有未完成的分配信息，包括每个分配的大小和负责分配的模块，并给出解决问题的建议。例如，“09BasicMLeak.exe”导致约 980KB 的内存泄漏，“GetSID”函数可能是分配源；“ntdll.dll”有 446 字节的未完成分配，通常系统 DLL 的此类分配不构成内存泄漏。
2. 分析细节（Analysis Details）：包含多个子部分，详细说明特定的内存相关信息：
- 若进程退出时请求了转储文件，第一部分包含转储文件信息摘要。
- 虚拟内存分析（Virtual Memory Analysis）：包含被分析进程的虚拟内存活动信息，如虚拟内存细节、加载的模块和线程。
- 堆分析（Heap Analysis）：包含堆使用的顶级概述和每个堆的详细统计信息。
- 泄漏分析（Leak Analysis）：包含 DebugDiag 执行的泄漏分析结果，显示内存活动的顶级概述和按模块细分的各个堆活动。例如，“09BasicMLeak.exe”是最大的分配模块，有 36000 次分配，总内存 984.38KB；“GetSID”函数负责最大的分配计数和分配大小，进行了 36000 次 28 字节的分配。

2.6 编写自定义分析脚本

2.6.1 脚本元数据

每个脚本以元数据部分开头，告知分析引擎脚本使用的语言、类别和描述，示例如下：

<%@ Language = VBScript %>
<%@ Category = Sample analysis script %>
<%@ Description = Example of a custom analysis script %>
<% script code goes here %>

2.6.2 示例脚本

以下脚本用于输出转储文件中所有锁定的关键部分：

Set DataFiles = Manager.DataFiles
For each DataFile in DataFiles
    Manager.Write “<B>Analyzing dump file “ & DataFile & “</B><BR>”
    Set Debugger = Manager.GetDebugger(DataFile)
    Set CritSecInfo = Debugger.CritSecInfo
    CritSecCount = CritSecInfo.Count
    if CritSecCount = 0 Then
        Manager.Write “No locked critical sections found<BR>”
    else
        For i = 0 to CritSecCount-1
            Set DbgCritSec = CritSecInfo.Item(i)
            Manager.Write “The owner of critsec: “ & DbgCritSec.Address & “ is thread: “
            & DbgCritSec.OwnerThreadID & “<BR>”
        Next
    End If
    Set Debugger = Nothing
Next

该脚本首先获取用户选择的所有转储文件，然后为每个转储文件获取调试器对象，进而获取关键部分信息对象。通过该对象的 Count 属性获取锁定关键部分的数量，若数量为 0 则输出未找到锁定关键部分的信息，否则遍历每个锁定关键部分，输出其地址和所属线程 ID。

综上所述，这些工具和技术为软件调试提供了强大的支持，帮助开发者更高效地解决软件问题。无论是通过 CER 收集和管理错误信息，还是使用 DebugDiag 分析各种软件故障，都能大大提高调试效率和准确性。

3. 工具使用流程总结与对比

3.1 工具使用流程总结

为了更清晰地展示 Windows Error Reporting（WER）、Corporate Error Reporting（CER）和调试诊断工具（DebugDiag）的使用流程，下面以 mermaid 流程图的形式呈现：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始]):::startend --> B{选择工具}:::decision
    B -->|WER| C(应用运行出现故障):::process
    C --> D(用户看到故障对话框):::process
    D --> E{点击更多信息?}:::decision
    E -->|是| F(跳转到响应网页):::process
    E -->|否| G(结束):::process
    B -->|CER| H(配置组策略):::process
    H --> I(应用运行出现故障):::process
    I --> J(错误报告存储到指定路径):::process
    J --> K(分析错误报告):::process
    K --> L(结束):::process
    B -->|DebugDiag| M(启动工具):::process
    M --> N{选择规则}:::decision
    N -->|内存和句柄泄漏| O(选择要分析的进程):::process
    O --> P(配置跟踪选项):::process
    P --> Q(运行应用):::process
    Q --> R(分析结果):::process
    R --> S(结束):::process
    N -->|崩溃| T(分析进程崩溃):::process
    T --> U(结束):::process
    N -->|挂起| V(分析挂起的 IIS 进程):::process
    V --> W(结束):::process

3.2 工具对比

工具名称	适用场景	主要功能	优势	局限性
Windows Error Reporting（WER）	监控应用在实际环境中的运行状况，获取错误信息并提供响应	收集错误信息，用户可获取问题解决信息	能实时获取用户反馈，便于及时响应问题	部分 ISV 因数据敏感问题不愿使用
Corporate Error Reporting（CER）	企业内部收集和管理错误报告	允许企业将错误信息存储在本地文件共享，可进行详细分析	保护企业敏感数据，便于企业内部管理	需要配置组策略，对非专业人员有一定难度
调试诊断工具（DebugDiag）	分析进程崩溃、挂起和内存泄漏等问题	自动化分析，提供详细报告，支持自定义脚本	功能强大，易于使用，可扩展性强	对于复杂问题可能需要编写自定义脚本

4. 实际应用案例分析

4.1 CER 在金融企业的应用

某金融企业开发了一款银行应用程序，包含大量客户账户的敏感信息。为了避免错误信息泄露，企业采用了 CER 进行错误报告管理。

配置过程 ：企业 IT 部门使用组策略在所有公司机器上启用 CER。通过“开始” - “运行”，输入“gpedit.msc”打开组策略编辑工具，在“本地计算机策略” - “计算机配置” - “管理模板” - “系统” - “错误报告”中进行详细配置。在“配置错误报告”设置中，勾选“不收集其他文件”和“不收集其他机器数据”，以减少敏感信息的收集；同时指定公司内部的文件共享路径作为错误报告存储位置。
问题发现与解决 ：一段时间后，通过定期查询文件共享，发现某一版本的应用程序频繁出现错误。分析错误报告中的小型转储文件，定位到代码中一个数据处理模块的逻辑错误。开发团队迅速修复问题，并通过应用更新将修复后的版本推送给客户，有效解决了客户遇到的问题。

4.2 DebugDiag 在 Web 应用开发中的应用

一家互联网公司开发了一款 Web 应用程序，在运行过程中出现了内存泄漏问题。开发团队使用 DebugDiag 进行分析。

配置与分析过程 ：启动 DebugDiag，在向导中选择“内存和句柄泄漏”规则，选择要分析的 Web 应用程序进程。配置跟踪选项，设置跟踪时间为 120 分钟，以更全面地监测内存变化。运行应用程序，让其模拟实际用户操作。应用程序运行结束后，点击“分析”按钮，查看分析结果。
问题定位与修复 ：分析摘要显示，某个特定的模块导致了大量的内存泄漏。进一步查看分析细节，发现是该模块中的一个函数在处理数据时没有正确释放内存。开发团队对该函数进行了修改，重新测试后，内存泄漏问题得到解决。

5. 总结与展望

5.1 总结

本文介绍了 Windows Error Reporting（WER）、Corporate Error Reporting（CER）和调试诊断工具（DebugDiag）在软件调试中的应用。WER 为开发者提供了监控应用在实际环境中运行状况的能力，方便及时获取用户反馈并提供响应；CER 解决了企业对敏感数据保护的需求，允许企业将错误报告保留在本地进行分析；DebugDiag 则以其强大的自动化分析能力和可扩展性，帮助开发者快速定位和解决各种软件故障。