Visual Studio 调试时出现极端滞后峰值

Question

When Im debugging my app in VS2012 and it crashes, the input (mouse and keyboard) starts to lag extremely, the fps drops to about 0.3 or less and I can't even move my mouse without waiting 3 seconds... The only solution is to do Shift-F5 which will end the debugging, and everythng is fine then again.

Whats more interesting, the only lagging thing is the input, the whole background works perfectly fine, text caret is blinking at normal rate and tooltips are nicely animated when mouse gets over a button.

Im compiling the project with allegro 4.2 (I have to use it, it would take too long to explain why).

I have no extensions, a pretty fast pc which should be able to handle debugging...

Im interested in any solution, it may be dirty/hackish... I can of course provide more information if needed.

Thanks for any help.

EDIT: Reading through forums I found some information about the "Auto" window or something like that (don't remember exactly and can't find it anymore), which is doing some "background tasks" and that causes lags... Do you think running it on separate core would fix that?

Answer 1

A tale of multi-second stalls when hitting a breakpoint, related to the raw input API: http://the-witness.net/news/2012/12/finding-and-fixing-a-five-second-stall/ ( archived )

It's a very long time since I last saw this sort of thing myself, but I seem to remember that the culprit in my case was DirectInput. (This makes some sense, given the tale above, as DirectInput has long been a wrapper over the raw input API.) And I think the solution was to use the emulated keyboard and mouse devices rather than the default ones, which you do this by passing in one of the emulated device GUIDs to IDirectInput8_CreateDevice . Discussed briefly here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee416845%28v=vs.85%29.aspx

(I don't remember whether cooperative and exclusivity levels made a difference - it might be worth trying changing these too.)

Answer 2

I recently experienced the following similar issues while debugging a game:

• Hit a breakpoint, halting the program for debugging.
• Pressing any key now takes around 1 second to "process". It will be buffered and sent slowly one after another to whatever window is now active.

In my case, the application installed a low level keyboard hook with SetWindowsHookEx(WH_KEYBOARD_LL, ...) . After removing this (for !NDEBUG builds only as you wish), the input lag was gone.

I suppose the hook cannot respond at all while your application is halted, and eventually the system skips it (after the ~1 second timeout). In fact, the link in the accepted answer mentions this issue, but I thought I explain the core of it right here, also because the link went dead before I fixed it.

Try to find such a hook in your application or dependencies, and check if removing it helps. Since you mentioned this happens to your mouse too, check for a (low level) mouse hook ( WH_MOUSE_LL ) aswell. The available hooks are listed on MSDN .