把长期运行后的崩溃追踪到句柄泄漏的案例

案例概要

针对一个只在连续运行约 1 个月后才突然崩溃的 Windows 应用程序，我们从梳理观测点入手，最终把调查收窄到以句柄泄漏为中心的案例。 关键不只在于原因本身，而在于决定了 应该先把哪些观测准备好。

症状

• 几天之内不会出现，只在长期运行后崩溃
• 仅凭异常的出现方式，难以判断是否是泄漏
• 只在现场发生，在开发机上需要压缩重现条件

约束

• 以月为单位等待重现并不现实
• 由于涉及相机重连和异常路径，只有正常路径的日志并不够
• 需要能够持续观测是哪种资源在增长

观测了什么

• Handle Count、Private Bytes、Thread Count 的 heartbeat
• 会话开始、重连、结束的边界日志
• create/open/register 与 close/dispose/unregister 成对出现的生命周期日志

如何排查

首先没有直接去追“长期运行崩溃”本身，而是把重现压缩到重连和 timeout 相关的失败路径上。 结果判断出，比起内存泄漏，怀疑 句柄泄漏 更为合理，从而可以把观测集中到那里。

如何改善

• 增加了监控项目，不仅能看到崩溃时刻，还能追踪增长趋势
• 整理了边界日志，便于追踪是哪个职责打开、哪个职责关闭了资源
• 把调查结果整理成便于衔接后续异常路径测试基础设施的形式

本案例关联的服务

本案例既关联排查只在长期运行后才出现的故障的 故障调查 & 根本原因分析，也关联从实现侧整理日志、重连和运维观测的 Windows 应用程序开发。

相关文章

联系我们

如果您遇到的问题与本页内容相近，欢迎附上当前状况和所需支持的形式与我们联系。