标签: crash-dumps

如果我使用类似于此处描述的类/方法,如何在堆栈顶部获取调用的描述/地址？

基本上我想要一些我可以在调用我们的bug跟踪系统时使用的值.我想根据导致异常的指令的地址"唯一地"识别.

(它通常是mydll.dll的形式!1234ABDC())

编辑:

一些背景资料:

我正在创建一个minidump,通过电子邮件发送到缺陷跟踪系统(fogbugz).为了减少重复,我试图为崩溃提出一个合理的"签名".我知道FB有一个xml PI,但它需要用户登录,我们还不确定我们是否有能力让人们嗅探我们的流量并获取用户信息.电子邮件现在也很容易实现.稍后我们将使用XML API提交minidump.

我想使用MiniDumpWriteDump()API从另一个进程A.我这样做是因为转储崩溃的进程B MSDN这样说:

如果可能的话,应该从单独的进程调用MiniDumpWriteDump,而不是从被转储的目标进程中调用.

MiniDumpWriteDump()定义如下:

BOOL WINAPI MiniDumpWriteDump(
  __in  HANDLE hProcess,
  __in  DWORD ProcessId,
  __in  HANDLE hFile,
  __in  MINIDUMP_TYPE DumpType,
  __in  PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
  __in  PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
  __in  PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);

特别是,ExceptionParam的类型为PMINIDUMP_EXCEPTION_INFORMATION,其定义如下:

typedef struct _MINIDUMP_EXCEPTION_INFORMATION {
  DWORD               ThreadId;
  PEXCEPTION_POINTERS ExceptionPointers;
  BOOL                ClientPointers;
} MINIDUMP_EXCEPTION_INFORMATION, *PMINIDUMP_EXCEPTION_INFORMATION;

现在我想知道如何准备以下2个参数:

ThreadId 抛出异常的线程的标识符.

ExceptionPointers 一个指向EXCEPTION_POINTERS结构指明该异常的计算机独立描述,并在异常时的处理器的上下文.

在进程A中运行时,如何在进程B中获取错误的线程id和异常指针？

谢谢.

我想解析完整的崩溃转储(*.dmp)文件并获取专用字节数据.我知道SysInternals的VMMap可以告诉我我的私有字节,堆等是多少,但我需要的是如果我有转储,我应该能够解析它并获得Heap(托管堆)结构和数据堆.通过阅读PEB然后走过堆,我已经完成了这项工作.

我无法弄清楚的是如何读取私有字节(除了Heap,它应该是本机代码的进程数据).任何人都可以指出我正确的方向,以便我能够从崩溃转储中解析除堆之外的专用字节.

谢谢.

我目前正在研究在单声道下运行的ac#linux应用程序.虽然,我相信我已经处理了可能在我的程序中抛出的任何可能的异常,但是我应该错过任何异常,我想知道是否有一种方法,当C#应用程序崩溃时它会创建一个核心转储文件,所以我可以看到例外并通过它来尝试确定导致问题的原因,如GDB对C程序的影响.

我在我的应用程序中使用OpenSuse 12.1.

感谢您的任何帮助,您可以提供.

我正在尝试在 Visual Studio 2013 中调试转储文件 (.DMP)。我单击了“仅使用托管进行调试”操作，但无法传递此错误：

来源不可用

该模块的调试信息中缺少源信息

您可以在“反汇编”窗口中查看反汇编。要始终查看丢失源文件的反汇编，请更改“选项”对话框中的设置。

我努力了：

1. 提供符号加载路径 (.PDB)
2. 仅启用/禁用我的代码

我有一个通过任务管理器获取的进程的完整内存转储.

我可以确定当时机器上的时间吗？

我的转储文件中有一个如下所示的调用堆栈。我想在调用堆栈中找到我的代码，但找不到。分析我的转储的起点是什么？我的程序的链接选项是release/Od。

msvcr120.dll!abort() 
msvcr120.dll!terminate()
msvcp120.dll!_Call_func$catch()
msvcr120.dll!_CallSettingFrame()
msvcr120.dll!__CxxCallCatchBlock(_EXCEPTION_RECORD * pExcept=0x0000002885f9b010)
ntdll.dll!RcConsolidateFrames()
msvcp120.dll!_Call_func(void * _Data=0x00000028835d5ce0)
msvcr120.dll!_callthreadstartex()
msvcr120.dll!_threadstartex(void * ptd=0x000000288366e410)
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

我想了解crashlytics这样的工具是如何工作的？

就像,他们得到崩溃日志堆栈跟踪只是在投掷和系统崩溃前几分钟？他们访问崩溃后产生的某种崩溃转储？在Object-C中,我们有主要的.也许在运行时附加一些代码,但他们如何处理？我附上代码以查看此崩溃报告的位置？

似乎微软生产了许多调试器和调试工具,它们创造了一个关于应用哪种工具以及何时应用的迷宫选择和问题.例如,有windbg - 以及Visual Studio中内置的调试器.两者都可以访问小型转储.为什么我会选择一个而不是另一个？

沃森博士是过去默认的死后崩溃分析工具.它现在已被"问题报告和解决方案"所取代.哪个更换为服务器上的IIS异常监视器？也许所有这些都建立在"Microsoft CDB Debugger"之上,或者这可能是另一个重复的工具？另一个ADPlus是基于CDB调试器构建的.迷宫似乎无休止地继续下去.

有人可以提供所有这些工具的分类法或路线图的链接,其中的评论被弃用(Dr.Watson？)以及调试学生应该吸收的"工具方向"？我敢肯定,我在这里没有提到过许多工具和基础库.知道它们之间的依赖关系(例如使用CDB调试器的ADPlus)会很高兴.

我发现这个链接很有帮助,因为它回答了我要问的一些问题 - 尽管材料已经过时了.任何其他资源可以提供类似简单的比较/对比度减少？

我正在做一个snprintf并且遇到一个段错误.

当我装上这样的GDB的核心文件:gdb my_executable core; 并且做bt了回溯,我得到了以下:

Program terminated with signal 11, Segmentation fault.
#0  0x88207fc2 in memcpy () from /usr/lib/libc.so.6
(gdb) bt
#0  0x88207fc2 in memcpy () from /usr/lib/libc.so.6
#1  0x88205eb6 in __sfvwrite () from /usr/lib/libc.so.6
#2  0x881fbc95 in strchr () from /usr/lib/libc.so.6
#3  0xbfbe6c14 in ?? ()
#4  0xbfbe69d8 in ?? ()
#5  0x881ed91e in localeconv () from /usr/lib/libc.so.6
#6  0x881fec05 in __vfprintf () from /usr/lib/libc.so.6
#7  0x881f7d80 in snprintf () from /usr/lib/libc.so.6  
#8 …