问题标签 [postmortem-debugging]

pg_stat_activity为各种问题的事后分析提供非常有用的信息，尤其是与并发相关的问题，因此增加错误或使用此数据（适当过滤和相关）进行日志记录是非常宝贵的。然而，查询它需要获得一个数据库连接，而这在最需要它的那一刻可能会供不应求。

是否有某种侧通道可以在没有额外数据库连接的情况下获取该信息？

也许是一个毫无意义的愚蠢问题：

在 kubernetes 部署（或 minikube）中，当 pod 容器崩溃时，我想在那一刻分析文件系统。通过这种方式，我可以看到核心转储或任何其他有用的信息。

我知道我可以挂载一个卷或 PVC 以从主机定义的核心模式位置获取核心转储，我也可以通过 rsyslog 边车或任何其他方式获取日志，但我仍然想做“事后分析” “如果可能，请进行分析。我认为 kubernetes 应该提供（但我不知道如何，这就是我的问题的原因）一些机制来执行此取证任务，从而使我们所有人的生活变得轻松，因为在生产系统中，我们可能需要分析被杀死/退出容器。

我尝试在没有--rm选项的情况下直接使用 docker run进行游戏，但无法从检查中获得任何有用的信息以获取有用的信息或在最后一刻重新创建使容器处于活动状态的文件系统。

十分感谢！

是否有一种简单的方法来监视给定的 Windows 进程是否存在明确定义的 .NET 异常（第一次或第二次机会）并在引发该异常时运行 powershell 脚本？我真的不需要进程转储（还）。

我使用收集用户模式转储中描述的默认参数生成了一个小型转储。

转储是在系统通过right CTRL++挂起时生成的，如以下注册键中所设置SCROLL LOCK：SCROLL LOCK

因此，WinDbg 在命令之后向我显示的调用堆栈0: kd> !analyze -v是从kbdhid设备驱动程序执行的线程之一。

当我尝试切换到不同的处理器时，出现错误：

我该如何解决这个错误？

什么是“单处理器内核分类转储”？如果我用谷歌搜索，我会得到 3 或 4 个结果……不多了，也许微软的人可以在这里提供很大的帮助 :-)。

CustomDumpFlags我必须设置一些特定的值吗？请参阅MINIDUMP_TYPE 枚举。

我知道我的系统是多处理器的，WinDbg 确认了这一点：

我有一个转储文件，我想知道它的“类型”，例如根据 收集用户模式转储 用户模式转储有三个基本DumpType：0: Custom dump,, 1: Mini dump.2: Full dump

根据内核模式转储文件的种类， 内核模式转储有五种类型：完全内存转储、内核内存转储、小型内存转储、自动内存转储、活动内存转储。

我想知道当底层应用程序通过阈值时，是否有任何方法可以自动化 Windbg + Procdump 以 60 秒的间隔进行 5 次转储。

我使用以下命令对 Procdump 进行了一些自动化操作：

但是我不知道当应用程序达到 800 mo 阈值时是否有任何方法可以激活 TTD（Windbg Time Travel Debugging）15 百万。

我的目标是构建一个 .bat 文件，该文件获取 PID、阈值、每次转储之间的时间、要进行的转储数量并告诉我的脚本激活或不激活 TTD。

我有一个在 raspi 上运行的 java 工具。我 ssh 进入 raspi 并使用启动该工具

一段时间（几小时或几天）后，该过程不再运行。我的代码中有相当广泛的日志记录，但我的日志没有显示任何错误。所以问题是我如何分析情况？我想使用 -XX:OnError 方法，但最好指定什么？还有其他想法我能做什么吗？

更新：我找不到一个 hs_err_pid 文件。当我这样启动程序时，工作目录是什么？我已经扫描了启动 java 应用程序的目录，/var 和 /tmp 以及 /home/pi。

更新 2：工作目录显示为 /home/pi 没有 err pid 文件。我现在正在运行它

如果正在创建错误文件，我可以“模拟”我看到的崩溃吗？杀 -9 不能解决问题。

调查 HEAP_FAILURE_MULTIPLE_ENTRIES_CORRUPTION 类型的堆损坏转储。在windbg中打开转储后发现以下详细信息。

最后已知的有效块在 - 000000d08b093f90 之前，在 - 000000d08b0a5000 之后

Ran 命令 !heap -s -a -h 000000d084f40000 打印堆中的所有子段和块信息。输出显示地址范围 000000d08b093f90 到 000000d08b0a5000 是包含损坏地址 000000d08b09c200 的子段的一部分。

000000d08b09bca0和000000d08b09f000之间的块列表具有无效的子段地址和块大小（第 4 和第 5 列）。

在大小和子段无效的第一个块上运行 !heap -p -a 和 !heap -x 命令：000000d08b09bcc0

两者都显示不同的大小。!heap -p -a 显示大小为 0x10。为什么会有这种差异？

这是不可重现的。启用页面堆并没有帮助捕获这种损坏。如何对此类 HEAP_FAILURE_MULTIPLE_ENTRIES_CORRUPTION 堆损坏进行调查？

当我的 .NET 5/WPF 应用程序崩溃时，我想让 Windows 错误报告写出一个崩溃转储文件。我在这里找到了一篇关于它的文章：

https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps

但不幸的是，同一篇文章说

此功能不支持执行自己的自定义崩溃报告的应用程序，包括 .NET 应用程序。

这是否意味着这对 .NET 应用程序永远不起作用，或者它对自己进行崩溃报告的 .NET 应用程序不起作用？

因为我试图让我的应用程序捕获未处理的异常：

但是这些处理程序似乎都没有被调用。

这是一个悲伤的故事：

1. 我在我的机器上构建了一个可执行文件thedarkmod.x64，将调试符号移到了一个单独的thedarkmod.x64.debug文件中。
2. 用户在 gdb 下运行此可执行文件时遇到了崩溃。core.1600她使用generate-core-filegdb 命令保存了核心转储。
3. 我下载了这个核心文件并通过启动gdb ./thedarkmod.x64 core.1600.
4. 我在线程之间切换并运行bt命令，但我看到一些垃圾而不是正确的堆栈跟踪。

注意：用户有我的thedarkmod.x64.debug文件，当她bt在保存核心转储之前运行时，她会看到有意义的堆栈跟踪。

当我在核心转储上启动 gdb 时，我看到许多警告消息，例如：

• 找不到与inferior的线程库匹配的libthread_db，线程调试将无法使用
• 警告：“libXXX.so”的 .dynamic 部分不在预期的地址（错误的库或版本不匹配？）

根据这个问题，第一个警告似乎暗示除非我与libthread_db.so.1保存核心转储的机器上的版本相同，否则我在多线程程序中看不到任何有用的东西。我让用户找到这个文件并把它交给我，但它没有帮助。然后我也要求提供libpthread.so.0文件，经过一番苦苦挣扎后，set solib-search-path我设法用“启用了 libthread_db 的线程调试”替换了这个警告，但堆栈跟踪仍然是错误的。set sysrootset auto-load safe-pathset libthread-db-search-path

所以问题是：

1. 有没有办法正确检查在环境截然不同的 Linux 机器上生成的核心转储？我的意思是不同的内核、pthreads、glibc 等。有没有关于如何实现的详细说明？
2. 是否有任何类似的 gdb 命令generate-core-file includecode，它将所有代码（包括必要的 .so 库）嵌入到核心文件中，以便我可以在我的机器上打开它而无需额外的麻烦？

目前，我不得不承认 Linux 核心转储对我来说毫无用处，因为我还没有准备好为每个提交的核心转储创建一个新的 Linux 虚拟机。

更新：我设法获得了正确的堆栈跟踪。

1. “重复问题”中提供的解决方案对我不起作用。没有与 solib 相关的设置就足够了，只有set sysroot帮助。
2. 在我的特殊情况下，堆栈跟踪在freelibc 的函数内结束。Gdb 无法遍历它的调用堆栈，可能是因为它-fomit-frame-pointer像大多数库一样编译。确保libc.so.6从用户机器获得的 gdb 负载有所帮助。

这是我使用的 gdb 命令的完整列表（当然，每个命令都是使事情正常运行所必需bt的）：