0

根据标题，当我支持的这个程序崩溃时，我找不到任何转储文件。

该应用程序的日志清楚地提到了它的 SIGSEGV 异常，但我已经搜索了整个硬盘驱动器，并且在任何地方都找不到 .dmp 文件。

该程序的开发人员已经在其他地方看到了类似的问题，但到目前为止还无法解释为什么会发生这种情况——我们现在有点卡住了。

应用程序日志的最后一部分内容如下：

Received signal SIGSEGV, segmentation violation.
OurApplication::sigHandler 11.
Removing signal handlers.
OurApplication::signalCatched.
OurApplication::sigHandler: exiting application.
Removing signal handlers.

我对此的有限理解是，我们应用程序的信号处理程序可能正在“中和”抛出的 SIGSEGV 异常。因此没有生成核心转储......我确实向开发人员提出了这个想法，但他们似乎从未真正调查过这是否可能是原因。他们在柜台提出的理论是，他们认为没有生成 dmp 的原因是因为程序可能在非常接近的地方崩溃了两次。

所以我现在的问题是：

  • 是否有任何 Windows7 参数可以控制 .dmp 文件的创建？
  • 是否有任何要求/标志需要编译到程序中，以便它（或 Windows）在崩溃时创建核心转储文件？
  • 我 99% 确定它必须是负责创建核心文件的 windows，因为程序本身在崩溃时会死/终止，对吗？
  • 是否有任何其他我应该注意的事情，或检查，或我可以收集然后向我们的开发人员展示的“证据”？

提前谢谢了

4

2 回答 2

1

是否有任何 Windows7 参数可以控制 .dmp 文件的创建？

有一些参数可以控制故障转储的创建：请参阅MSDN on Collecting user-mode dumps。

是否有任何要求/标志需要编译到程序中，以便它（或 Windows）在崩溃时创建核心转储文件？

您不需要为之前的答案编译任何内容。但是，由于未处理的异常，程序需要终止，这意味着您需要让异常冒泡而不被未处理的异常处理程序处理。

我有 99% 的把握肯定是 Windows 负责创建核心文件，因为程序本身在崩溃时会死/终止，对吗？

如上所述，Windows 可以处理这个问题，让 Windows 处理崩溃是个好主意。想象一下，您的程序由于内存泄漏而损坏。部分内存已被覆盖。在这种情况下，您的未处理异常处理程序可能会被销毁。但是，Windows 仍然可以完全控制该进程，可以暂停它并从外部（而不是从内部）创建转储。

是否有任何其他我应该注意的事情，或检查，或我可以收集然后向我们的开发人员展示的“证据”？

好吧，由于上述原因，建议让 Windows 创建转储。然后他们也不需要实现配置设置（您不希望始终创建故障转储文件，对吗？）。您不需要为文件实施限制数量。您不需要检查磁盘空间等。

您可以建议阅读 Windows Internals 6 书籍。

于 2014-02-11T09:03:47.140 回答
1

考虑以编程方式创建您自己的小型转储文件。应该有大量的代码来展示如何做到这一点。你可以在这里试试：

https://stackoverflow.com/search?q=minidump

这样，您就无需依赖 Dr. Watson 或任何其他设置来创建转储文件。相反，您将调用 DBGHELP.DLL 中的函数来创建转储文件。

于 2014-02-10T22:48:32.467 回答