【问题标题】:Disable VS debugger for specific thread禁用特定线程的 VS 调试器
【发布时间】:2011-02-18 01:00:33
【问题描述】:

我正在编写一些开源软件来捕获和处理原始鼠标和键盘事件。当一个事件被捕获时,我与一个 win32 窗口进行通信,以准确地询问如何处理该事件(即传递它或使用它)。它实际上与 HIDMacros 非常相似。

最终决定是否使用事件的部分实际上在我无法控制的内存空间中运行(即 Windows 本身正在运行的东西)。这意味着,不幸的是,我几乎没有能力调试那段代码。幸运的是,这是非常简单的代码,我还没有调试它。

另一方面,我在自己的线程中运行了一个 Win32 事件循环,并处理上述代码部分发送的请求。所以上面的部分向这个窗口发送一条消息,它决定做什么,并返回一个答案。很简单。

问题是这样的。当我附加调试器时,只有 win32 窗口事件循环停止。其他代码继续运行,因为它不在我的实际内存或进程中。当用户执行类似操作时,哦,比如说,按 F10(进入下一行),我注册的键盘钩子将(1)捕捉击键,(2)调用我的 win32 窗口回答。不幸的是,调试器冻结了窗口。最终结果是:我按 F10,Visual Studio 从未收到我的击键。 Visual Studio 本身停止响应所有输入,它冻结,我必须杀死 VS 本身。

现在我已经设法通过使用超时解决了一些问题,但这确实很烦人(即非常容易察觉)而且一点也不理想。我想知道的是,是否有一种编程方式可以从调试器中排除特定线程?有没有办法让 VS 调试器不要停止执行特定线程?除此之外,有没有办法让调试器本身在暂停正常执行之前执行某个操作,并在恢复正常执行后再次执行?

此库将用于其他项目。如果人们在调试时没有突然失去使用键盘的能力,我真的很高兴,因为他们决定链接到我的库。 :) 任何帮助表示赞赏,谢谢。

【问题讨论】:

  • 如果您对代码感兴趣,可以在github找到它

标签: c++ visual-studio-2008 winapi debugging


【解决方案1】:

Hmya,您正在使用全局挂钩,非常具有破坏性。调试器无能为力,它是注入到 Visual Studio 中的 DLL 的副本,导致 SendMessageTimeout() 调用挂起。 IsDebuggerPresent() 不会有用。

一种可能的解决方法是检查 DLL 是在哪个进程中注入的。在您获得的第一个回调中使用 GetModuleFileHandle,传递 NULL。如果您看到 devenv.exe,则永远绕过所有内容。请注意,这是本地状态,而不是共享状态。

另一种方法是在第一次超时时切换模式。发生这种情况时绕过 SendMessage 调用一段时间(比如 5 分钟),这样这些超时就不再那么明显了。

【讨论】:

  • 谢谢。我也想这么多,但我认为这值得一问。我希望可能有一些#pragma 或一些奇怪的低级线程调用会告诉调试器,“别管这个线程,没什么可担心的”
【解决方案2】:

您并没有确切说明您对超时所做的事情,也没有确切说明您的过滤器进程正在做什么,但是我会为此使用 SendMessageTimeout 而不是普通的 SendMessage 并且具有相当低的超时值,然后如果 SendMessageTimeout 超时,只需继续钩子。

【讨论】:

  • 这正是我现在正在采取的方法,实际上。很高兴知道我并没有完全脱离基地:) 谢谢。
【解决方案3】:

VS 使用的调试器 api(以及几乎所有其他调试器)将始终冻结整个进程。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-10-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多