一个关于如何定位程序崩溃处的想法

clever101
博客专家认证
2019-02-11 03:24:55
这里的程序崩溃不是指在开发环境下崩溃,而是一般是在开发环境下运行正常,而在实际上生产环境下崩溃,甚至有更诡异的是在实际生产环境中也不是全部机器崩溃,而是在特定的一台或几台机器上崩溃。由于在实际生产环境中缺乏调试环境,往往很难调试这种崩溃。因此定位这类崩溃成了一个老大难问题。

我查看了网上的一些资料,解决方案就是在崩溃时生产转储文件,然后用windbg或google breakpad进行定位。这个解决方案有一些严重弊端:一是需要将转储文件拷贝出来,要知道在国内一些保密单位(比如军队),文件是很难拷贝出来的;二是崩溃难以重现,因为如前文所述崩溃有时在特定的机器上出现的,很多时候缺乏相应的测试数据也很难重现崩溃(有时因为保密原因测试数据是基本不可能拷贝出来的)。

为此我设想了一个办法:设计一种只保存崩溃代码对应的obj文件名和代码行号的转储文件。比如release版本崩溃了,开发人员提供一个可以生成转储文件的release版本来替换原来的版本,然后操作人员在实际生产环境中重现崩溃生成转储文件,转储文件不用拷贝出来,直接用开发人员提供的转储文件查看工具打开转储文件来查看崩溃代码是哪个obj和对应的行号,查到后把结果告诉开发人员,这样开发人员找到对应行号的cpp文件就大致知道导致崩溃的原因了。

现在的问题是我的设想理论上是否可行呢,就是转储文件能否只保存崩溃代码对应的obj文件名和代码行号。
...全文
616 21 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
21 条回复
切换为时间正序
请发表友善的回复…
发表回复
_船长_ 2019-03-07
  • 打赏
  • 举报
回复
引用 9 楼 宁可十年不将军,不可一日不拱卒 的回复:
[quote=引用 17 楼 _船长_ 的回复:]
[quote=引用 16 楼 宁可十年不将军,不可一日不拱卒 的回复:]
[quote=引用 15 楼 _船长_ 的回复:]
想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来


要调试也得在实际生产现场调试,不然在开发环境很难重现。开发人员经常去用户现场不现实,一般的技术支持人员也不会使用WinDbg配合PDB进行调试。这就是一个大问题。[/quote]

从客户电脑上将DUMP文件拷贝出来,如果客户不允许,那就需要跟客户协商了,能够做政府项目,都有关系,让领导去协调,不然就是神仙也没办法查找崩溃原因[/quote]

DUMP文件或许可以拷贝出来,但是测试数据没法拷贝出来啊,因为测试数据涉及到国家机密的,有关系也就是让你干这个项目,不是让你把数据拷贝走的,泄露机密这个责任没人可以承担得起。没有相关数据在开发环境下就没法调试运行。还有更诡异的错误是你把相应的测试数据拷贝出来,在生产环境下就是崩溃,在开发环境下就是不崩溃,这个估计跟系统环境有关系,这种情况怎么办。[/quote]

我觉得你好像没有搞清楚DUMP文件是干啥用的,稍微说一下,dump文件保存的是当软件运行崩溃时的信息,通过dump文件中的信息,配合WinDbg和软件发布时对应的PDB符号文件,就可以对dump文件进行错误分析,据此,确认崩溃原因,跟你说的需要测试数据没有半毛钱关系。
clever101 2019-03-07
  • 打赏
  • 举报
回复
引用 17 楼 _船长_ 的回复:
[quote=引用 16 楼 宁可十年不将军,不可一日不拱卒 的回复:] [quote=引用 15 楼 _船长_ 的回复:] 想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来
要调试也得在实际生产现场调试,不然在开发环境很难重现。开发人员经常去用户现场不现实,一般的技术支持人员也不会使用WinDbg配合PDB进行调试。这就是一个大问题。[/quote] 从客户电脑上将DUMP文件拷贝出来,如果客户不允许,那就需要跟客户协商了,能够做政府项目,都有关系,让领导去协调,不然就是神仙也没办法查找崩溃原因[/quote] DUMP文件或许可以拷贝出来,但是测试数据没法拷贝出来啊,因为测试数据涉及到国家机密的,有关系也就是让你干这个项目,不是让你把数据拷贝走的,泄露机密这个责任没人可以承担得起。没有相关数据在开发环境下就没法调试运行。还有更诡异的错误是你把相应的测试数据拷贝出来,在生产环境下就是崩溃,在开发环境下就是不崩溃,这个估计跟系统环境有关系,这种情况怎么办。
_船长_ 2019-03-07
  • 打赏
  • 举报
回复
引用 16 楼 宁可十年不将军,不可一日不拱卒 的回复:
[quote=引用 15 楼 _船长_ 的回复:]
想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来


要调试也得在实际生产现场调试,不然在开发环境很难重现。开发人员经常去用户现场不现实,一般的技术支持人员也不会使用WinDbg配合PDB进行调试。这就是一个大问题。[/quote]

从客户电脑上将DUMP文件拷贝出来,如果客户不允许,那就需要跟客户协商了,能够做政府项目,都有关系,让领导去协调,不然就是神仙也没办法查找崩溃原因
_船长_ 2019-03-07
  • 打赏
  • 举报
回复
引用 21 楼 宁可十年不将军,不可一日不拱卒 的回复:
[quote=引用 19 楼 _船长_ 的回复:]
[quote=引用 9 楼 宁可十年不将军,不可一日不拱卒 的回复:]
[quote=引用 17 楼 _船长_ 的回复:]
[quote=引用 16 楼 宁可十年不将军,不可一日不拱卒 的回复:]
[quote=引用 15 楼 _船长_ 的回复:]
想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来


要调试也得在实际生产现场调试,不然在开发环境很难重现。开发人员经常去用户现场不现实,一般的技术支持人员也不会使用WinDbg配合PDB进行调试。这就是一个大问题。[/quote]

从客户电脑上将DUMP文件拷贝出来,如果客户不允许,那就需要跟客户协商了,能够做政府项目,都有关系,让领导去协调,不然就是神仙也没办法查找崩溃原因[/quote]

DUMP文件或许可以拷贝出来,但是测试数据没法拷贝出来啊,因为测试数据涉及到国家机密的,有关系也就是让你干这个项目,不是让你把数据拷贝走的,泄露机密这个责任没人可以承担得起。没有相关数据在开发环境下就没法调试运行。还有更诡异的错误是你把相应的测试数据拷贝出来,在生产环境下就是崩溃,在开发环境下就是不崩溃,这个估计跟系统环境有关系,这种情况怎么办。[/quote]

我觉得你好像没有搞清楚DUMP文件是干啥用的,稍微说一下,dump文件保存的是当软件运行崩溃时的信息,通过dump文件中的信息,配合WinDbg和软件发布时对应的PDB符号文件,就可以对dump文件进行错误分析,据此,确认崩溃原因,跟你说的需要测试数据没有半毛钱关系。[/quote]

还有照你的意思是每次软件发布的对应版本的pdb文件和源码文件都得保存好。[/quote]

对的,PDB符号要和发布的软件一一对应,关于WinDbg如何调式DUMP,就需要自己查资料了,祝好运
clever101 2019-03-07
  • 打赏
  • 举报
回复
引用 19 楼 _船长_ 的回复:
[quote=引用 9 楼 宁可十年不将军,不可一日不拱卒 的回复:] [quote=引用 17 楼 _船长_ 的回复:] [quote=引用 16 楼 宁可十年不将军,不可一日不拱卒 的回复:] [quote=引用 15 楼 _船长_ 的回复:] 想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来
要调试也得在实际生产现场调试,不然在开发环境很难重现。开发人员经常去用户现场不现实,一般的技术支持人员也不会使用WinDbg配合PDB进行调试。这就是一个大问题。[/quote] 从客户电脑上将DUMP文件拷贝出来,如果客户不允许,那就需要跟客户协商了,能够做政府项目,都有关系,让领导去协调,不然就是神仙也没办法查找崩溃原因[/quote] DUMP文件或许可以拷贝出来,但是测试数据没法拷贝出来啊,因为测试数据涉及到国家机密的,有关系也就是让你干这个项目,不是让你把数据拷贝走的,泄露机密这个责任没人可以承担得起。没有相关数据在开发环境下就没法调试运行。还有更诡异的错误是你把相应的测试数据拷贝出来,在生产环境下就是崩溃,在开发环境下就是不崩溃,这个估计跟系统环境有关系,这种情况怎么办。[/quote] 我觉得你好像没有搞清楚DUMP文件是干啥用的,稍微说一下,dump文件保存的是当软件运行崩溃时的信息,通过dump文件中的信息,配合WinDbg和软件发布时对应的PDB符号文件,就可以对dump文件进行错误分析,据此,确认崩溃原因,跟你说的需要测试数据没有半毛钱关系。[/quote] 还有照你的意思是每次软件发布的对应版本的pdb文件和源码文件都得保存好。
clever101 2019-03-07
  • 打赏
  • 举报
回复
引用 19 楼 _船长_ 的回复:
[quote=引用 9 楼 宁可十年不将军,不可一日不拱卒 的回复:] [quote=引用 17 楼 _船长_ 的回复:] [quote=引用 16 楼 宁可十年不将军,不可一日不拱卒 的回复:] [quote=引用 15 楼 _船长_ 的回复:] 想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来
要调试也得在实际生产现场调试,不然在开发环境很难重现。开发人员经常去用户现场不现实,一般的技术支持人员也不会使用WinDbg配合PDB进行调试。这就是一个大问题。[/quote] 从客户电脑上将DUMP文件拷贝出来,如果客户不允许,那就需要跟客户协商了,能够做政府项目,都有关系,让领导去协调,不然就是神仙也没办法查找崩溃原因[/quote] DUMP文件或许可以拷贝出来,但是测试数据没法拷贝出来啊,因为测试数据涉及到国家机密的,有关系也就是让你干这个项目,不是让你把数据拷贝走的,泄露机密这个责任没人可以承担得起。没有相关数据在开发环境下就没法调试运行。还有更诡异的错误是你把相应的测试数据拷贝出来,在生产环境下就是崩溃,在开发环境下就是不崩溃,这个估计跟系统环境有关系,这种情况怎么办。[/quote] 我觉得你好像没有搞清楚DUMP文件是干啥用的,稍微说一下,dump文件保存的是当软件运行崩溃时的信息,通过dump文件中的信息,配合WinDbg和软件发布时对应的PDB符号文件,就可以对dump文件进行错误分析,据此,确认崩溃原因,跟你说的需要测试数据没有半毛钱关系。[/quote] 那你说的错误分析能定位到具体出错的代码行吗?就像vs调试windows程序一样。
clever101 2019-03-06
  • 打赏
  • 举报
回复
引用 15 楼 _船长_ 的回复:
想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来
要调试也得在实际生产现场调试,不然在开发环境很难重现。开发人员经常去用户现场不现实,一般的技术支持人员也不会使用WinDbg配合PDB进行调试。这就是一个大问题。
_船长_ 2019-03-06
  • 打赏
  • 举报
回复
想法太天真了,王道就是崩溃时生成dump文件,使用WinDbg配合PDB进行调试,有坛友说写log,顶多能定位到哪个函数调用时出问题,但具体崩溃原因,无法通过log分析出来
clever101 2019-03-06
  • 打赏
  • 举报
回复
现在比较可行的办法是是在实际生产环境中收集可以定位代码行的信息。
marslycan 2019-03-05
  • 打赏
  • 举报
回复
Mark 与楼主相同情形,前场条件不允许装调试环境,往往很多BUG都是实际生产出现,根据人员口头反馈回来崩溃路径有时候就是复现不出来,头疼~
clever101 2019-02-20
  • 打赏
  • 举报
回复
引用 10 楼 szMac2019 的回复:
如果是程序崩溃,代码肯定有大的瑕疵,完全可以在开发办公室进行大数据模拟测试出来的。 只有逻辑性处理的bug,才会存在设计和测试均未考虑到的情况。
兄弟,你太看得起测试的作用了。限于开发人员的开发水平,限于缺乏大量的测试数据,程序在开发办公室暴露的只会是一部分的问题。只有在实际生产环境中才会充分暴露问题的,而且系统还得运行相当长的时间。
szMac2019 2019-02-19
  • 打赏
  • 举报
回复
如果是程序崩溃,代码肯定有大的瑕疵,完全可以在开发办公室进行大数据模拟测试出来的。
只有逻辑性处理的bug,才会存在设计和测试均未考虑到的情况。
clever101 2019-02-18
  • 打赏
  • 举报
回复
引用 8 楼 sevancheng 的回复:
[quote=引用 7 楼 宁可十年不将军,不可一日不拱卒 的回复:] [quote=引用 6 楼 sevancheng 的回复:] 写dump文件,再调试就行了吧
你说的调试是在开发环境下还是实际生产环境中呢?[/quote] 发布时候带上exe和dll的pdb文件,运行时候出错就会写dump文件,再把dump文件拷到开发环境,指定代码路径就可以调[/quote] 这个得说明一下,要重现bug,除了要有exe程序,还得有测试数据。但是测试数据用户是不会允许你拷贝出来的。还有就是有些bug只在用户的实际生产环境中崩溃,不在开发机器上崩溃。
sevancheng 2019-02-18
  • 打赏
  • 举报
回复
引用 7 楼 宁可十年不将军,不可一日不拱卒 的回复:
[quote=引用 6 楼 sevancheng 的回复:]
写dump文件,再调试就行了吧


你说的调试是在开发环境下还是实际生产环境中呢?[/quote]

发布时候带上exe和dll的pdb文件,运行时候出错就会写dump文件,再把dump文件拷到开发环境,指定代码路径就可以调
clever101 2019-02-15
  • 打赏
  • 举报
回复
引用 6 楼 sevancheng 的回复:
写dump文件,再调试就行了吧
你说的调试是在开发环境下还是实际生产环境中呢?
sevancheng 2019-02-15
  • 打赏
  • 举报
回复
写dump文件,再调试就行了吧
clever101 2019-02-13
  • 打赏
  • 举报
回复
引用 4 楼 Eleven 的回复:
打log是一个不错的方式~
log不现实。log只是你预判崩溃有可能崩溃的地方,实际上往往程序在你意想不到的地方崩溃。
Eleven 2019-02-13
  • 打赏
  • 举报
回复
打log是一个不错的方式~
clever101 2019-02-11
  • 打赏
  • 举报
回复
引用 1 楼 zgl7903 的回复:
一般的是保留调试符号文件.pdb, 在调试环境下结合调用堆栈和源码可以定位到代码 VC6 的MSDN的例子下有 DRWATSON 源码, 可以参考下
还有很多时候只有在生产环境才能重现bug,不能重现的话肯定定位不了崩溃的地方。
clever101 2019-02-11
  • 打赏
  • 举报
回复
引用 1 楼 zgl7903 的回复:
一般的是保留调试符号文件.pdb, 在调试环境下结合调用堆栈和源码可以定位到代码 VC6 的MSDN的例子下有 DRWATSON 源码, 可以参考下
大侠,在调试环境下定位肯定不现实。在实际生产单位装个开发环境很麻烦的。
加载更多回复(1)

16,548

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • AIGC Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧