Windbg 磨合需要很长时间
Windbg break-in takes very long time
我想捕获有时会停止响应几分钟的应用程序的堆栈跟踪。
当应用程序停止响应时，windows 桌面也停止响应鼠标点击，虽然其他一些已经 运行 的应用程序当时工作正常（例如 windbg 工作正常，ProcessExplorer 刷新它的屏幕，但不响应鼠标事件）。
虽然该应用程序没有响应，但它实际上占用了一个 CPU 核心的大约 80%。这就是为什么我想要一个堆栈跟踪。
行为不端的应用程序通常需要大约 2-3 分钟才能完成其奇怪的工作，或者如果按下 Ctrl+Esc，它会立即响应（当然还会打开开始菜单...）
我将 WinDbg 附加到行为不当的应用程序，当我发出 Break 命令时，直到应用程序开始再次响应才发生入侵。
据我了解，入侵实际上创建了一个远程线程，该线程很快调用 DbgBreakPoint。
什么可能阻止调试器的线程执行？
编辑：
首先感谢您的帮助！
我还认为这可能是由于错误的设备驱动程序或在某处安装了系统范围的挂钩的东西引起的。
我正在考虑启用内核调试并从内核获取有问题线程的堆栈跟踪，或者启用手动蓝屏触发器以生成转储并在之后查看。
Process Explorer 和 Process Monitor 没有显示任何有趣的东西。当错误被触发时，它们也会变得不可用（更新它们的 windows 但不响应鼠标或键盘）。
EDIT2：
背景资料：
应用程序使用 QT、OpenGL 和 DirectSound 并在 Windows 7 SP1 x64 上运行
我目前怀疑图形部分有问题。
奇怪的是，如果采用系统范围的锁（如 GDI 锁），这将阻止其他 Windows 的绘制，但这并没有发生。同一台机器上的 WinDbg 工作正常。 ProcessExplorer 更新但不接收鼠标点击，桌面更新但不接收鼠标点击。
我目前有一个内核调试器附加...
EDIT3
ETW 对调试最有用。原来Qt的主事件处理循环疯了。 PeekMessage 和 MsgWaitForMultipleObjectsEx（超时为 0）在紧密循环中被调用。这就是 CPU 高使用率的来源。
看起来该应用当时有 generating/getting 条消息。但是要查看消息是什么并不容易（或者我不知道如何访问 ETW 中的函数参数）。使用调试器也无济于事，但是 QT 事件循环中的断点让我相信 WM_TIMER 消息是罪魁祸首。
考虑到桌面在此期间也出现异常，听起来您的应用不一定异常，而只是加剧了其他地方的错误（例如，在设备驱动程序中或注入的一些糟糕的 anti-malware 代码中本身进入其他进程）。来自您的应用程序的堆栈跟踪可能会或可能不会很有启发性。
如果问题很容易重现，我会在应用程序 "middle" 的某处设置一个断点，看看问题是在此之前还是之后发生。然后移动断点，直到您找到您的应用在事情变得疯狂之前执行的最后一条指令。弄清楚您的应用会触发此行为的行为可能会为您提供线索。
另一种选择是尝试使用一些 system-wide 调试工具。首先，我会在事件查看器中查看是否有可疑的错误或警告事件在机器出现故障时发布。然后我会尝试使用像 Sysinternal 的 Process Monitor 或 Process Explorer 这样的工具来更好地了解正在发生的事情。您也可以尝试使用 ETW 来捕获系统上发生的事情的 system-wide 痕迹，您可以事后研究。 （ETW 可能很难使用，因此请查看 Bruce Dawson 的 UIforETW。）
使用ETW查找原因。安装 Windows Performance Toolkit（Win10 v1511 SDK 的一部分：https://go.microsoft.com/fwlink/p/?LinkID=698771 这是在 Win7 中运行的最后一个版本），运行 WPRUI.exe，select CPU Usage 然后点击 Start.
捕获挂起后，单击 Save。等到WPRUI结束，打开WPA中的ETL，setup and load debug symbols in WPA.
拖放 CPU Usage (Precise) 图表以分析窗格并为您的流程查找 WAIT (µs) max 以查看 long hang and expand the stack to see where it happens.
我想捕获有时会停止响应几分钟的应用程序的堆栈跟踪。
当应用程序停止响应时，windows 桌面也停止响应鼠标点击，虽然其他一些已经 运行 的应用程序当时工作正常（例如 windbg 工作正常，ProcessExplorer 刷新它的屏幕，但不响应鼠标事件）。 虽然该应用程序没有响应，但它实际上占用了一个 CPU 核心的大约 80%。这就是为什么我想要一个堆栈跟踪。
行为不端的应用程序通常需要大约 2-3 分钟才能完成其奇怪的工作，或者如果按下 Ctrl+Esc，它会立即响应（当然还会打开开始菜单...）
我将 WinDbg 附加到行为不当的应用程序，当我发出 Break 命令时，直到应用程序开始再次响应才发生入侵。
据我了解，入侵实际上创建了一个远程线程，该线程很快调用 DbgBreakPoint。
什么可能阻止调试器的线程执行？
编辑： 首先感谢您的帮助！
我还认为这可能是由于错误的设备驱动程序或在某处安装了系统范围的挂钩的东西引起的。
我正在考虑启用内核调试并从内核获取有问题线程的堆栈跟踪，或者启用手动蓝屏触发器以生成转储并在之后查看。
Process Explorer 和 Process Monitor 没有显示任何有趣的东西。当错误被触发时，它们也会变得不可用（更新它们的 windows 但不响应鼠标或键盘）。
EDIT2： 背景资料： 应用程序使用 QT、OpenGL 和 DirectSound 并在 Windows 7 SP1 x64 上运行 我目前怀疑图形部分有问题。
奇怪的是，如果采用系统范围的锁（如 GDI 锁），这将阻止其他 Windows 的绘制，但这并没有发生。同一台机器上的 WinDbg 工作正常。 ProcessExplorer 更新但不接收鼠标点击，桌面更新但不接收鼠标点击。
我目前有一个内核调试器附加...
EDIT3 ETW 对调试最有用。原来Qt的主事件处理循环疯了。 PeekMessage 和 MsgWaitForMultipleObjectsEx（超时为 0）在紧密循环中被调用。这就是 CPU 高使用率的来源。 看起来该应用当时有 generating/getting 条消息。但是要查看消息是什么并不容易（或者我不知道如何访问 ETW 中的函数参数）。使用调试器也无济于事，但是 QT 事件循环中的断点让我相信 WM_TIMER 消息是罪魁祸首。
考虑到桌面在此期间也出现异常，听起来您的应用不一定异常，而只是加剧了其他地方的错误（例如，在设备驱动程序中或注入的一些糟糕的 anti-malware 代码中本身进入其他进程）。来自您的应用程序的堆栈跟踪可能会或可能不会很有启发性。
如果问题很容易重现，我会在应用程序 "middle" 的某处设置一个断点，看看问题是在此之前还是之后发生。然后移动断点，直到您找到您的应用在事情变得疯狂之前执行的最后一条指令。弄清楚您的应用会触发此行为的行为可能会为您提供线索。
另一种选择是尝试使用一些 system-wide 调试工具。首先，我会在事件查看器中查看是否有可疑的错误或警告事件在机器出现故障时发布。然后我会尝试使用像 Sysinternal 的 Process Monitor 或 Process Explorer 这样的工具来更好地了解正在发生的事情。您也可以尝试使用 ETW 来捕获系统上发生的事情的 system-wide 痕迹，您可以事后研究。 （ETW 可能很难使用，因此请查看 Bruce Dawson 的 UIforETW。）
使用ETW查找原因。安装 Windows Performance Toolkit（Win10 v1511 SDK 的一部分：https://go.microsoft.com/fwlink/p/?LinkID=698771 这是在 Win7 中运行的最后一个版本），运行 WPRUI.exe，select CPU Usage 然后点击 Start.
捕获挂起后，单击 Save。等到WPRUI结束，打开WPA中的ETL，setup and load debug symbols in WPA.
拖放 CPU Usage (Precise) 图表以分析窗格并为您的流程查找 WAIT (µs) max 以查看 long hang and expand the stack to see where it happens.