Windows/C++:是否可以找到引发异常的代码行,并具有“异常偏移"?

Windows/C++: Is it possible to find the line of code where exception was thrown having quot;Exception Offsetquot;(Windows/C++:是否可以找到引发异常的代码行,并具有“异常偏移?)
本文介绍了Windows/C++:是否可以找到引发异常的代码行,并具有“异常偏移"?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着跟版网的小编来一起学习吧!

问题描述

我们的一位用户在我们的产品启动时遇到了异常.她从 Windows 向我们发送了以下错误消息:

One of our users having an Exception on our product startup. She has sent us the following error message from Windows:

  Problem Event Name:                        APPCRASH
  Application Name:                          program.exe
  Application Version:                       1.0.0.1
  Application Timestamp:                     4ba62004
  Fault Module Name:                         agcutils.dll
  Fault Module Version:                      1.0.0.1
  Fault Module Timestamp:                    48dbd973
  Exception Code:                            c0000005
  Exception Offset:                          000038d7
  OS Version:                                6.0.6002.2.2.0.768.2
  Locale ID:                                 1033
  Additional Information 1:                  381d
  Additional Information 2:                  fdf78cd6110fd6ff90e9fff3d6ab377d
  Additional Information 3:                  b2df
  Additional Information 4:                  a3da65b92a4f9b2faa205d199b0aa9ef

是否可以通过此信息在源代码中找到发生异常的确切位置?

Is it possible to locate the exact place in the source code where the exception has occured having this information?

Windows 上的 C++ 程序员在定位用户计算机上发生错误的位置的常用技术是什么?

What is the common technique for C++ programmers on Windows to locate the place of an error that has occured on user computer?

我们的项目使用Release配置编译,生成PDB文件.

Our project is compiled with Release configuration, PDB file is generated.

希望我的问题不要太天真.

I hope my question is not too naive.

推荐答案

是的,这是可能的.使用与您的用户运行的完全相同的二进制文件开始调试,确保加载了 DLL 并且您有一个匹配的 PDB 文件.在 Debug + Windows + Modules 中查找 DLL 基地址.添加偏移量.Debug + Windows + Disassembly 并在 Address 字段中输入计算出的地址(前缀为 0x).这向您显示了导致异常的确切机器代码指令.右键单击 + Go To Source code 查看匹配的源代码行.

Yes, that's possible. Start debugging with the exact same binaries as ran by your user, make sure the DLL is loaded and you've got a matching PDB file for it. Look in Debug + Windows + Modules for the DLL base address. Add the offset. Debug + Windows + Disassembly and enter the calculated address in the Address field (prefix with 0x). That shows you the exact machine code instruction that caused the exception. Right-click + Go To Source code to see the matching source code line.

虽然这向您展示了该语句,但这通常不足以诊断原因.0xc0000005 异常是访问冲突,它有很多可能的原因.通常你甚至没有得到任何代码,程序可能由于堆栈损坏而被遗忘.或者真正的问题位于很远的地方,一些破坏堆的指针操作.您通常还需要一个堆栈跟踪,以向您展示程序如何在爆炸语句处结束.

While that shows you the statement, this isn't typically good enough to diagnose the cause. The 0xc0000005 exception is an access violation, it has many possible causes. Often you don't even get any code, the program may have jumped into oblivion due to a corrupted stack. Or the real problem is located far away, some pointer manipulation that corrupted the heap. You also typically really need a stack trace that shows you how the program ended up at the statement that bombed.

你需要的是一个小型转储.如果她运行 Vista 或 Win7,您可以轻松地从您的用户那里获得一个.启动 TaskMgr.exe,进程选项卡,选择被轰炸的程序,同时它仍然显示崩溃对话框.右键单击它并创建转储文件.

What you need is a minidump. You can easily get one from your user if she runs Vista or Win7. Start TaskMgr.exe, Processes tab, select the bombed program while it is still displaying the crash dialog. Right-click it and Create Dump File.

为了使这一切顺利,您确实希望自动化此过程.您会在此主题的回答中找到提示.

To make this smooth, you really want to automate this procedure. You'll find hints in my answer in this thread.

这篇关于Windows/C++:是否可以找到引发异常的代码行,并具有“异常偏移"?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!

本站部分内容来源互联网,如果有图片或者内容侵犯了您的权益,请联系我们,我们会在确认后第一时间进行删除!

相关文档推荐

Prevent class inheritance in C++(防止 C++ 中的类继承)
Why should I declare a virtual destructor for an abstract class in C++?(为什么要在 C++ 中为抽象类声明虚拟析构函数?)
Why is Default constructor called in virtual inheritance?(为什么在虚拟继承中调用默认构造函数?)
C++ cast to derived class(C++ 转换为派生类)
C++ virtual function return type(C++虚函数返回类型)
Is there any real risk to deriving from the C++ STL containers?(从 C++ STL 容器派生是否有任何真正的风险?)