Windbg闯入需要很长时间

时间:2017-01-31 22:41:58

标签: windows debugging windbg

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

当应用程序停止响应时,Windows桌面也停止响应鼠标点击,虽然其他一些已在运行的应用程序正常工作(例如windbg工作正常,ProcessExplorer刷新其屏幕,但不响应鼠标事件)。 虽然应用程序没有响应,但它实际上占用了一个CPU内核的80%左右。这就是为什么我想得到一个堆栈跟踪。

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

我将WinDbg附加到行为不当的应用程序上,当我发出Break命令时,在应用程序再次开始响应之前不会发生入侵。

根据我的理解,闯入实际上创建了一个远程线程,很快就会调用DbgBreakPoint

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

修改: 首先感谢你的帮助!

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

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

Process Explorer和Process Monitor没有发现任何有趣的内容。当触发错误时,它们也会变得无法使用(更新窗口但不响应鼠标或键盘)。

EDIT2 : 背景资料: 应用程序使用QT,OpenGL和DirectSound,并在Windows 7 SP1 x64上运行 我目前怀疑图形部分有什么东西。

奇怪的是,如果采用系统范围的锁定(如GDI Lock),这将阻止其他Windows的绘制,但这不会发生。 WinDbg在同一台机器上工作正常。 ProcessExplorer更新但没有接收鼠标点击,桌面更新但没有鼠标点击。

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

EDIT3 ETW对调试最有用。事实证明,Qt的主要事件处理循环变得疯狂。 PeekMessage和MsgWaitForMultipleObjectsEx(0超时)在紧密循环中被调用。这就是高CPU使用率的来源。 看起来App正在生成/获取当时的大量消息。但要查看消息是什么(或者我不知道如何访问ETW中的函数参数)并不容易。使用调试器也没什么用,但是,在QT的事件循环中有一个断点让我相信WM_TIMER消息是罪魁祸首。

2 个答案:

答案 0 :(得分:2)

鉴于桌面在这段时间内行为不端,听起来你的应用程序不一定是行为不端,而只是加剧了其他地方的错误(例如,在设备驱动程序或一些已经注入其他进程的恶意反恶意软件代码中) )。来自您的应用程序的堆栈跟踪可能会或可能不会显示。

如果问题很容易重现,我会在应用程序的“中间”某处设置一个断点,看看问题是在之前还是之后发生。然后移动断点,直到找到应用程序执行的最后一条指令,然后才会发生变化。弄清楚你的应用程序所做的事情会触发这种行为,这可能会给出正在发生的事情的线索。

另一个选择是尝试使用一些系统范围的调试工具。首先,我会在事件查看器中达到峰值,以查看在机器出现故障的时刻附近是否发布了可疑错误或警告事件。然后我会尝试像Sysinternal的Process Monitor或Process Explorer这样的工具来更好地了解正在发生的事情。您也可以尝试使用ETW捕获系统上正在发生的事情的跟踪,您可以在事后研究。 (ETW可能很难使用,所以请查看Bruce Dawson的UIforETW。)

答案 1 :(得分:1)

使用ETW查找原因。安装Windows Performance Toolkit(Win10 v1511 SDK的一部分:https://go.microsoft.com/fwlink/p/?LinkID=698771,这是Win7中的最新版本),运行WPRUI.exe,选择CPU Usage并单击Start。< / p>

抓住挂起后,点击Save。等到WPRUI完成后,在WPA中打开ETL setup and load debug symbols in WPA

拖动&amp;将CPU Usage (Precise)图表拖放到“分析”窗格,然后查找WAIT (µs) max,以便您的流程看到long hang and expand the stack to see where it happens.