Disable VS debugger for specific thread

I'm writing some open source software to capture and process raw mouse and keyboard events. When an event is captured, I communicate with a win32 window to ask precisely what to do with the event (i.e. pass it along or consume it). It's actually quite similar to HIDMacros.

The section which ulti开发者_如何学Gomately decides whether or not to consume an event actually runs in a memory space that I DO NOT control (i.e. something that Windows itself is running). Which means, unfortunately, I have almost no ability to debug that section of code. Fortunately it is very simple code and I haven't had to debug it yet.

On the other side of things, I've got a Win32 event loop running in its own thread, and handles the requests sent by the aforementioned section of code. So the above section sends this window a message, it decides what to do, and returns an answer. Simple enough.

THE PROBLEM is this. When I attach a debugger, only the win32 window event loop is stopped. The other code keeps right on running since it's not in my actual memory or process. And when the user does something like, oh say, press F10 (to step to the next line), the keyboard hook that I've registered will (1) catch the keystroke, and (2) call off to my win32 window for an answer. Unfortunately the window is frozen by the debugger. The end result is: I press F10, and visual studio never receives my keystroke. Visual studio itself stops responding to all input, it freezes, and I have to kill VS itself.

Now I've managed to work around the problem SOMEWHAT by using timeouts, but it's really annoying (i.e. very perceptible) and not at all ideal. What I'd like to know is, is there a programmatic way to exclude a particular thread from the debugger? Is there a way to ask the VS debugger NOT to stop the execution of a particular thread? Barring that, is there any way to make the debugger itself execute a certain action before suspending normal execution, and again after resuming normal execution?

This library will be used in other projects. I'd really like it if people didn't suddenly lose the ability to use their keyboard while debugging JUST because they decided to link against MY library. :) Any help is appreciated, thanks.

Hmya, you are using global hooks, very disruptive. Nothing you can do with the debugger, it is the copy of the DLL that got injected into Visual Studio that is making the SendMessageTimeout() call that hangs. IsDebuggerPresent() is not going to be useful.

One possible workaround is to check in which process the DLL got injected. Use GetModuleFileHandle, passing NULL, on the first callback you get. If you see devenv.exe then bypass everything forever. Beware that this is local state, not shared.

Another approach is to switch mode on the first timeout you get. Bypass the SendMessage call for a while (say 5 minutes) when that happens so that these timeouts are not so noticeable anymore.

You're not saying exactly what you did with timeout, and you're not saying exactly what your filter process is doing, but I would use SendMessageTimeout rather than plain SendMessage for this and with a fairly low timeout value, and then just continue on in the hook if SendMessageTimeout times out.

the debugger api that VS uses (and virtually every other debugger) will always freeze the whole process.