问题标签 [postmortem-debugging]

我使用 Visual Studio 2013 for Visual Basic，我正在努力调试我的多线程程序。

我正在使用 BackgroundWorker，它的工作方式似乎与我认为的不同。

我不明白为什么我的程序在只处理了 ArrayList 中名为arFileName.

BackgroundWorker1.DoWork 过程中的For Each语句无法遍历arFileName以下代码中的整个内容：

我有一个用户的核心转储。主程序通过dlopen. 该进程在插件模块中中止。用户提供了一个回溯，其中包括插件的文件名，以及它中止的函数。

我需要查看数据，例如传递给函数的参数。我如何告诉 gdb 插件的加载位置，以便它可以弄清楚如何显示源和数据？

我有以下情况：

我将内核调试器 (Windbg) 附加到运行Windows 10 64bit的 Hyper-V 机器上。我要调试的进程是一个32 位用户模式进程，它有时会挂起机器（它与微过滤器通信），因此我不能使用用户模式调试器或远程调试器。

现在我有一个符号服务器，我知道我要调查的进程和线程，我该如何：

1. 仅查看此线程的调用堆栈
2. 为我的模块加载符号

奖励问题：出于某种原因，我的程序有很多实例。除了“活动”之外，其余的在 Process Explorer 中不可见，没有线程和 0 句柄计数。什么可能导致这种情况？

我尝试过的事情：

这个线程是我要调查的线程。它具有很高的处理器使用率，如粗体所示：用户时间：17 分钟。但是堆栈没有帮助。然后我做了：

这个地址 0x819613ca 是什么？如何提取它所属的模块？或者提取一个有意义的调用堆栈？我现在如何进一步进行调查？

在 Windows 下开发和部署应用程序时，开发人员可以选择将编译器生成的 .pdb 文件存储在本地，作为每次构建的一部分，并让他的程序调用MiniDumpWriteDump以响应崩溃以生成 .dmp 文件稍后可以将其发送回开发人员。然后，开发人员可以将收到的 .dmp 与适当的 .pdb 文件和可执行文件进行匹配，并使用它对崩溃进行事后调试（即查看堆栈跟踪等）。

设置和管理起来很痛苦，但优点是它允许开发人员从他发布的程序中剥离所有调试信息，但仍然能够调试现场发生的崩溃。这允许程序的安装大小要小得多，并且可能使程序不太容易受到逆向工程的影响。

我的问题是，MacOS/X 是否有类似 .pdb 的机制？我在 MacOS/X 上看到的唯一选择是要么“剥离”你的可执行文件（产生一个小的可执行文件，但如果它崩溃，调试信息就很少），或者不（产生一个提供非常有用的崩溃报告，当它崩溃时，但比它需要的要大得多）。

我正在尝试从artoolkit.org的SDK 构建ARToolKit ，但是我遇到了一些问题。应用程序 simpleOSG 是一个包含的示例应用程序，它是从源代码构建的。但是，当它运行时，它会崩溃。调试时，它会在以下位置中断：

并给出以下输出：

任何帮助将不胜感激。

谢谢你，杰克

Windows 10，VS 2013，ARToolKit 5.3.2

尝试在 VS 2017 中打开故障转储时出现“文件太大而无法打开”错误。以下是我的盒子规格：

• 操作系统：Win 2012 R2 64Bit
• VS Enterprise 2017。它是一个干净的安装，安装时没有选择任何选项。
• 转储文件由 .Net 4.5 Web 应用程序中的“procdump64 -ma -e 231532”命令创建。故障转储文件大小约为 9GB。

如果有人能就这个问题给我建议，我真的很感激。

我得到了一个复杂的故障转储：一个（32 位）程序 (C++) 是用 Visual Studio 6 编写的，并在 64 位机器上执行。所以，我得到了一个 64 位的故障转储。可悲的是，我无法访问 VS 6（而且我认为 VS6 不能处理 64 位）。VS 2015 无法打开这个故障转储（32 位调试器无法调试 64 位..），所以我用 WinDBG（和我自己的 dmp 文件查看器 :) 进行了尝试。

查看堆栈仅显示系统地址 (0x7..)。

例如。：

在 ThreadInfoListStream 或

有什么问题/我错在哪里？我该怎么做才能看到整个堆栈？是否有任何帮助/指导如何自行展开堆栈（我能够加载/读取 pdb，我可以访问转储中保存的内存，我已经对 TEB 的主要部分进行了未编码，. ..)。

谢谢

我在 Linux x64 上有一个核心转储。在某些时候 SIGSEGV 发生了，不幸的是应用程序处理了这个信号（但最终还是失败了）。所以核心转储不直接包含原始 SIGSEGV 的帧。

我能够确定失败指令的 SP 和 IP（以及其他寄存器）。基本上我有完整的 ucontext 结构。

有没有办法使用 GDB/LLDB 而不是在线程上显示堆栈只是从已知的 SP/IP 展开回溯？

我试图实现一些事后调试器，意味着只捕获程序未处理的异常，所以我设置了未处理的异常过滤器（并确保没有人在我之后设置它）但我有一些情况（例如在mshtml.dll），访问冲突发生但没有未处理的异常过滤器调用，并且事后调试器（例如windbg）弹出事后调试器如何捕获它？

并且 AddVectoredExceptionHandler 不是一个好主意，因为它甚至被 seh 处理并继续调用。

我们公司向客户提供了一套dll，并且不时需要修复一些完全罕见的未知异常或崩溃，我们无法在我们的机器上重现。现在我在考虑是否应该使用简单的堆栈跟踪，或者使用 MiniDumpWriteDump 转储更详细的信息？

我担心小型转储可能存在一个问题：当我们没有在创建转储时加载的所有可执行文件/dll 时，我不确定它是否提供任何有用的信息。因为显然客户从他们自己的 dll/exe 调用我们的 DLL 的 API，他们不会给我们他们自己的二进制文件的可执行文件/调试符号/源。我知道在 Linux 下与核心转储类似的情况下，我们将无法从核心转储（https://sourceware.org/ml/archer/2008-q4/msg00119.html）中获得任何有用的信息。

因此，我对 minidumps 的最小目标是可靠地从我们的 DLL 实现堆栈跟踪，而无需调用我们的 dll 的可执行文件/dll。实现局部和全局变量的状态会很棒。

所以问题是：如果我没有调用我的 dll 的可执行文件/dll，小型转储是否对我有用？