问题标签 [postmortem-debugging]

minidump 文件中的 MiscInfoStream 包含进程创建时间。我想知道崩溃前该进程运行了多长时间。minidump 文件是否在任何地方都包含异常时间戳？

此转储文件上的 WinDbg 显示以下内容，这意味着它在某处...

（DumpChk 显示相同的信息，在流列表的末尾）

请注意，今天是 3 月 15 日，所以这几乎可以肯定是崩溃的时间戳。我想要一种编程方式来检索该值和“Process Uptime”值。

我找到了MINIDUMP_MISC_INFO_3包含一些时区信息的结构，但它似乎不包含异常时间。

一些转储文件似乎有一个 ThreadInfoListStream，其中包含进程中每个线程的时间戳，但这不包含在我看到的小型转储中。

请注意，我不想解决我的问题的任何问题 - 我正在考虑事情发生的概率，因此想知道一些事情：

如果您删除对象并使用 gcc 作为编译器，究竟会发生什么？

上周我正在调查一次崩溃，其中竞争条件导致对象的双重删除。

调用对象的虚析构函数时发生崩溃，因为指向虚函数表的指针已经被覆盖。

虚函数指针是否被第一次删除覆盖？

如果不是，那么第二次删除是否安全，只要同时没有进行新的内存分配？

我想知道为什么我之前没有识别出我遇到的问题，唯一的解释是虚拟函数表在第一次删除期间被立即覆盖，或者第二次删除没有崩溃。

（第一个意味着如果“比赛”发生，崩溃总是发生在同一个位置 - 第二个，当比赛发生时通常什么都不会发生 - 并且只有在第三个线程覆盖删除对象时才会发生问题。 )

编辑/更新：

我做了一个测试，以下代码因段错误（gcc 4.4、i686 和 amd64）而崩溃：

如果我从 dtor 中删除“虚拟”，程序会被 glibc 中止，因为它检测到双重释放。对于“虚拟”，在对析构函数进行间接函数调用时会发生崩溃，因为指向虚拟函数表的指针无效。

在 amd64 和 i686 上，指针都指向一个有效的内存区域（堆），但是那里的值是无效的（一个计数器？它非常低，例如 0x11 或 0x21）所以编译器时的“调用”（或“jmp”做了返回优化）跳转到无效区域。

程序接收信号 SIGSEGV，

分段故障。0x0000000000000021

在 ？？() (gdb)

#0 0x0000000000000021 在?? ()

#1 0x000000000040083e 在 main ()

所以在上面提到的条件下，指向虚函数表的指针总是被第一次删除覆盖，所以如果类有虚析构函数，下一次删除将跳转到必杀技。

我们习惯于针对内存中的 HSQLDB 数据库运行 grails 集成测试，但在故障点，由于数据丢失，很难进行调查。我们迁移到对物理数据库（postgres）运行测试，当测试通过时一切都很好。在任何时候，如果测试失败，我们希望将数据提交到数据库中，以便事后分析测试失败的原因。

总而言之，只要测试通过，我们希望测试以回滚模式运行，这样一个测试不会影响另一个测试，并且在测试第一次失败时，在该点提交数据并停止。

我们花费了大量时间调查集成测试失败，并且想知道我们是否可以在 grails 中选择在第一次集成测试失败时停止，并将数据保存在数据库中以供调查。我搜索了一下，没有找到任何合适的指针。如果您遵循任何其他实践来解决集成测试问题并且值得分享，请告诉我们。

假设，在调试会话中，我有一个地址不幸指向一些垃圾。我想检查它周围的记忆，看看附近有什么。正如预期的那样，出现以下错误：

所以，问题是：有没有办法读取一系列地址，其中一些是无效的？

（更准确地说，我怎么知道在上面的例子$t5+n中是一个有效的地址0 < n <= 64？）

我在看一个崩溃转储。有些变量在windbg 中看起来完全可见，而其他变量只是说“内存访问错误”。这是什么原因造成的？为什么有些变量具有有意义的值而其他变量只是列出？

似乎所有问题都与以下指针有关。我敢肯定，虽然这些指针中有许多未初始化，但它们中的绝大多数应该指向有效的地方。基于这次崩溃的性质（一个简单的 null ptr 取消引用），我相当肯定整个过程并没有出去吃午饭。

你通常如何解决这个问题？想象一下，一个线程在 Computer1 上的 libc 代码（这是一个系统共享库）内崩溃，然后生成一个 coredump。但是将在其上分析此 coredump 的 Computer2 可能具有不同版本的 libc。

所以：

1. 在远程计算机上拥有相同的共享库有多重要？gdb 会在 Computer2 上没有完全相同版本的 libc 的情况下正确重建堆栈跟踪吗？

2. 为 libc 提供正确的调试符号有多重要？gdb 会在 Computer2 上没有完全相同的调试符号的情况下正确重建堆栈跟踪吗？

3. 对于共享系统库，避免这种调试符号不匹配问题的“正确”方法是什么？对我来说，似乎没有单一的解决方案可以优雅地解决这个问题？也许有人可以分享他的经验？

我正在尝试追踪 Windows 中 C++ 应用程序中的内存泄漏，并且我有一个包含大量泄漏对象的应用程序的内存转储。我正在使用 Windbg 通过执行以下操作来追踪它们：

这显示了以下内容：

所以我可以看到堆 003d0000 包含泄漏对象，所以我使用：

这表明：

所以我有一个 98 字节大小的对象泄漏，我可以追踪该对象的内容：

由此可见：

这就是我对 Windbg 的了解用完的地方，我可以看到堆上的对象是类的，MyObject但是我如何找出这个对象是在哪里创建的呢？

任何帮助将不胜感激！

谢谢，J

我在服务器上运行了一个 WCF 服务，偶尔（每月 1-2 次）它会抛出一个 COMException，并显示信息性消息“未知错误 (0x8005008)”。当我用谷歌搜索这个特定的错误时，我只得到了关于在 IIS 中创建虚拟目录时出现问题的线程。源代码与在 IIS 中创建虚拟目录无关。

当我捕获异常以在 WinDBG 中进行进一步分析时，我进行了内存转储。切换到正确的线程后，我执行了 !CLRStack 命令：

我的结论是代码调用时它失败了 System.DirectoryServices.PropertyCollection.get_Item(System.String) 时它会失败。

所以在发出 !CLRStack -a 之后，我得到了这个结果：

我的第一个问题是为什么它在属性名上没有显示任何数据？我对 Windbg 有点陌生。但是我在 = 0x0000000001dcef78 上执行了一个转储对象：

因此，当源代码想要从 Active Directory（用于持久层）获取个人处方代码时，它会失败。回顾堆栈，它是在发出 Copy 方法时。 DirectoryServiceLib.LdapProvider.DirectoryPost.Copy（DirectoryServiceLib.LdapProvider.DirectoryPost）

所以查看源代码：

此代码正在 OU=limbo 中查找具有相同 UserId 的另一篇文章，如果找到，则将属性复制到新文章中。在这种情况下，它确实会失败，并显示个人处方代码。我查看了 OU=Limbo 下的 Active Directory，并且帖子存在于其中，属性personalprescriptioncode=31243。

问题 1：为什么它没有显示某些 PARAMETERS 和 LOCALS 的数据？是不是在创建 memorydump 之前清理过的 GC。

问题2：我还能做些什么来解决这个问题吗？

我第一次使用 DebugDiag，我在 Windows 7 x64 上使用它。我为 (x86) myprogram.exe 创建了一个崩溃规则，它保证会崩溃，因为我故意将它编码为以“未知异常 (0xc0000417)”崩溃。

我将 Windows “启动和恢复”配置为捕获 mini-dumps。有用。我已调整注册表项以捕获自定义 mini-dumps。有用。是的，结果我得到了两个不同的转储文件。我没关系。

但是，如果我理解正确，DebugDiag 应该在触发崩溃规则时简单地“跳起来”，但当崩溃发生时，DebugDiag 什么也不做。DebugDiag 仅在我手动将 dmp 文件显式加载到其中时才提供分析。我需要做什么才能使规则自动触发？

我有一个捕获异常的 .Net 应用程序转储，我正在使用 windbg 进行分析，并对其中一种方法的 String 参数的值感兴趣。我已经隔离了 String 对象。我的windbg工作是：

m_stringLength 成员变量表示字符串长度为 179 个字符，但检查字符串似乎只有 32 个字符长。查看此字符串的内存似乎是 NULL 终止的。在 NULL 终止字符之后还有更多字符。这可能是重用内存或字符串损坏，但路径看起来正确显示。抛出的异常是“路径中的非法字符”，但此路径中没有非法字符。所以这个异常的调用栈是：

System.IO.Path.CheckInvalidPathChars 方法是使用在 m_stringLength 中找到的长度来处理字符串，还是考虑到字符串本身的 NULL 终止？如果你能发现我没有发现的东西，我也愿意接受这样一个事实。