windows - Windbg 磨合需要很长时间

Question

我想捕获有时会停止响应几分钟的应用程序的堆栈跟踪。

当应用程序停止响应时，windows 桌面也停止响应鼠标点击，尽管此时其他一些已经运行的应用程序工作正常(例如 windbg 工作正常，ProcessExplorer 刷新其屏幕，但不响应鼠标事件).虽然应用程序没有响应，但它实际上占用了一个 CPU 内核的大约 80%。这就是我想要获得堆栈跟踪的原因。

行为不端的应用程序通常需要大约 2-3 分钟才能完成其奇怪的工作，或者如果按下 Ctrl+Esc，它会立即响应(当然还会打开开始菜单...)

我将 WinDbg 附加到行为不当的应用程序，当我发出 Break 命令时，直到应用程序开始再次响应时才会发生入侵。

据我所知，入侵实际上创建了一个远程线程，它很快就会调用 DbgBreakPoint。

什么可能会阻止调试器的线程执行？

编辑:首先感谢您的帮助!

我还认为这可能是由于设备驱动程序错误或在某处安装了系统范围的 Hook 引起的。

我正在考虑启用内核调试并从内核获取有问题线程的堆栈跟踪，或者启用手动蓝屏触发器以生成转储并在之后查看。

Process Explorer 和 Process Monitor 没有显示任何有趣的东西。当错误被触发时，它们也会变得不可用(更新它们的窗口但不响应鼠标或键盘)。

编辑 2:背景资料:应用程序使用 QT、OpenGL 和 DirectSound 并在 Windows 7 SP1 x64 上运行我目前怀疑图形部分有问题。

奇怪的是，如果采用系统范围的锁定(如 GDI 锁定)，这将阻止其他窗口的绘制，但事实并非如此。同一台机器上的 WinDbg 工作正常。 ProcessExplorer 更新但不接收鼠标点击，Desktop 更新但不接收鼠标点击。

我目前有一个内核调试器附加...

编辑3ETW 对调试最有用。原来Qt的主事件处理循环疯了。 PeekMessage 和 MsgWaitForMultipleObjectsEx(超时为 0)在紧密循环中被调用。这就是高 CPU 使用率的来源。看起来该应用程序当时正在生成/获取大量消息。但是要查看消息是什么并不容易(或者我不知道如何访问 ETW 中的函数参数)。使用调试器也无济于事，但 QT 事件循环中的断点让我相信 WM_TIMER 消息是罪魁祸首。

Answer 1

考虑到桌面在这段时间内也出现异常行为，听起来您的应用不一定存在异常行为，而只是加剧了其他地方的错误(例如，在设备驱动程序中或一些将自身注入(inject)其他进程的糟糕的反恶意软件代码).来自您的应用程序的堆栈跟踪可能会或可能不会很有启发性。

如果问题很容易重现，我会在应用的“中间”某处设置一个断点，看看问题是在断点之前还是之后发生。然后移动断点，直到您找到您的应用在事情变得疯狂之前执行的最后一条指令。弄清楚您的应用执行了哪些操作会触发此行为可能会提供线索，了解正在发生的事情。

另一种选择是尝试使用一些系统范围的调试工具。首先，我会在事件查看器中查看是否有可疑的错误或警告事件在机器出现故障时发布。然后我会尝试使用像 Sysinternal 的 Process Monitor 或 Process Explorer 这样的工具来更好地了解正在发生的事情。您还可以尝试使用 ETW 来捕获系统范围内发生的事件的跟踪信息，您可以在事后研究这些信息。 (ETW 可能很难使用，因此请查看 Bruce Dawson 的 UIforETW。)