问题标签 [postmortem-debugging]

我在一个文件夹中编译了我的应用程序的调试版本。现在有所有的dll，pdb和带有pdb的exe。我现在已经使用 Taskmanager 从这条路径开始创建了我正在运行的应用程序的 MiniDump。现在，我可以在 Visual Studio 2010 中打开这个 dmp 文件。但是当我尝试调试时，会出现一条消息，即找不到符号。我已将符号 (pdb) 的路径添加到 Visual Studio 中的符号路径中 - 但没有成功。我还尝试在模块的 ContextMenu 上加载符号。它正在那里搜索MyApp.pdb，我选择了正确的 pdb。但我得到了消息A matching symbol file was not found in this folder。

我可以做些什么来使用 Visual Studio 2010 对我的 MiniDump 进行事后调试（这样它就会找到我的符号）？

我们有一种情况，我们希望能够创建一个 zip 文件，其中包含尽可能多的关于当前正在运行的 Java 程序（可能正在下降）的信息，以便进行事后取证分析。我们目前部署到 Java 5，但 Java 6 的特性也很有趣。

到目前为止，我想到了：

• 以编程方式生成的线程转储。这似乎在 Java 6 中工作得更好。
• 最近 X 分钟记录的日志事件。我们目前使用 logback 或 java.util.logging。
• 一些序列化的对象。
• 外部环境 - 所有系统属性。

JVM 信息还有什么用处？

是否有可能以通用方式遍历调用堆栈并查看参数？（或者这是否需要 JVMTI 或等效项）。它是一个 IBM JVM，所以我们不能使用 jvisualvm 和 Attach API。

我正在尝试从在 x64 机器上运行的进程调试 32 位进程转储。我在 x64 笔记本电脑上运行 x86 版本的 windbg。我已经遵循了这里的建议，但我仍然得到这个：

据我所知，mscordacwks_x86_x86_4.0.30319.237.dll已成功加载，但我仍然收到错误消息。我错过了什么？

加载 sosex 后，出现以下错误。有任何想法吗？挂起转储来自 32 位机器，我的是 64 位的。我需要安装一些东西吗？

re 分析核心文件时，我的 gdb 7.0 输出几个警告：

我不确定它是否相关，但我无法获得回溯：

操作系统架构是 SUN Solaris 10 SPARC。

问题：

1. 这些警告的原因/原因是什么？
2. 为什么我无法检索回溯？
3. 如何解决这些问题？

我有 WinDBG 6.12.0002.633 x86，我正在使用它来查看来自 Windows Mobile 6 ARMV4I 应用程序的事后 kdmp。

当我去分析调用堆栈时，我得到了很多未知数。在分析中，我可以在 *FAULTING_IP* 部分看到故障出在tcpstk模块中。（我也有符号。但是，在 *STACK_TEXT* 部分中，tcpstk地址仅显示为地址，没有符号。

此外，在 *MODULE_NAME* 部分，我得到另一个未知数，即使它只是说故障模块在 tcpstk 中。

该!analyze -v命令的结果是：

如果我切换到kp命令，我突然可以看到调用堆栈的那部分

为什么该!analyze -v命令不能显示完全解码的调用堆栈？为什么它显示出如此多的未知数？

我正在使用 WinDBG 6.12.0002.633 X86。

我遇到了命令行调试器 CDB 的问题，它没有显示与 WinDBG 的kandkL命令相同的结果。

在 WinDBG 中，该k命令正确显示调用堆栈的代码行，其中kL命令正确剥离该信息并仅显示偏移量。

在 CDB 中， 和 的结果k是kL相同的：

我该怎么做才能让 CDBk像 WinDBG 一样显示命令的代码行？

我有一个由在 Windows Mobile 6.5 ARMV4I 上运行的 C# .NET CF 3.5 应用程序生成的事后 kdmp，我想在 WinDBG X86 6.12.0002.633 中进行分析。

我能够获得非托管的调用堆栈，但这并不能告诉我更多信息，而不仅仅是我在 .net 应用程序中。

在大窗口中，我可以使用 SOS 执行!clrstack，但 CF 不加载 mscorwks.dll。

我需要做什么来分析紧凑框架生成的转储文件？

谢谢，保罗

地图文件如下所示：

崩溃信息如下所示：

我试图在下一次崩溃时获取堆栈转储，但在我看来，这是我们击败堆栈然后返回的情况，这使我们最终执行数据。

不过我并不完全确定，因为我读过一些这样的文章：Under the Hood Article似乎表明这是一个导入方法名称的区域

导入库为导入的 API 提供的数据保存在几个名称都以 .idata 开头的部分中（例如，.idata$4、.idata$5 和 .idata$6）。.idata$5 部分包含一个 DWORD，当可执行文件加载时，它包含导入函数的地址。.idata$6 部分（如果存在）包含导入函数的名称。当将可执行文件加载到内存中时，Win32 加载程序使用此字符串有效地调用导入函数的 GetProcAddress。

没有堆栈回溯，我有点卡住了。我是否以错误的方式看待这次崩溃？

我的应用程序崩溃了，我无法调试，因为我们的一位合作伙伴认为使用真正可怕的“CodeMeter”来加密他们的 DLL 是合适的。CodeMeter 许可阻止所有尝试调试包含 CodeMeter 加密 DLL 的应用程序，甚至似乎导致从未处理的异常过滤器调用的 MiniDumpWriteDump 失败（此技术在没有加载此 DLL 的情况下有效）。只有在将加密的 DLL 加载到进程中时才会发生崩溃。

我正在疯狂地尝试调试它并确定是否是加密的 DLL 崩溃了，如果是，我如何向我们的合作伙伴提供足够的诊断信息来解决这个问题。

有什么建议——也许我可以从未处理的异常过滤器中调用一些手动堆栈和模块遍历代码？

CodeMeter 是否具有构建设置，允许我们的合作伙伴生成仍然加密和许可但不会如此积极地破坏调试的构建？

只是为了以防万一有任何疑问，我不是试图破解许可，只是诊断这次崩溃。