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?
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.)
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 a timeout, which length can be configured in milliseconds under HKEY_CURRENT_USER\Control Panel\Desktop\LowLevelHooksTimeout:DWORD as mentioned here. 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.
Related
I recently played a game called "Quake Champions" from Steam. Against a player I know for a fact is a cheater, my left mouse button stopped to work whenever he was in a close-radius.
I am sure it is a cheat because my mouse works just fine on other computers.
I heard of DLL injection and cheaters using such methods. I am afraid somehow my mouse and maybe keyboard are being monitored remotely.
What can I do to find out, and also solve the issue ?
I tried re-installing display drivers, full game and deleted all files, mouse driver and app (mouse is Razer Basilisk Essential), I tried anti-malware softwares, etc.
Now even outside of the game the mouse seems to skip clicks at times, especially when I hold and drag (continuous fire in the game...).
I documented myself a bit and heard of hooks. I would ideally like to figure out which process (visible or not in task manager) hooks or interacts with both my keyboard and mouse, it would probably be a great way to figure out if I am in trouble or not.
Formatting the computer in full IS an option, but one I would prefer to avoid as I have costly licenses that I may lose, due to a limited number of activations...
Any help appreciated.
Further info:
Razer Central/Synapse -> Keyboard: Razer Cynosa Chroma ; Mouse: Razer Basilisk Essential
Further anxiety:
Shortly after this event happened, I received an alert from my Facebook saying somebody tried to log in... It was not me. It may be a coincidence, it may not. Fortunately my Facebook password is strong enough. But this is further reasons to be anxious on my end...
I have a script that I'm trying to debug, but the debugger immediately closes itself when it hits an error and dismisses the error message. I could manually open the log and wait for it to load every time I hit a stop, but that wastes a lot of time when it could just pop up on my screen. I figure it has to be an easy fix and I probably did something stupid, but one gets pretty tired of Google's shit when you've read blog headlines such as "THE 6 DEADLY SINS OF GOOGLE APPS SCRIPT ADD-ON DEVELOPMENT" for the 50th time in as many search queries. Anyways, rant over.
When I hit debug, the debugger will run, a white tray pops up at the bottom of my screen and stays empty. When it hits an error, it will flash the error message across the top of the window and immediately close/dismiss that error as well the tray that popped up. The tray looks like the one in the image below, except completely empty.
Has anyone else had this issue and know why it might be happening? Also, can anyone tell me if there is a Matlab-style workspace explorer that displays each user-defined variable and what kind of data it holds? I would find that extremely helpful in debugging. That, and a live in-window console/log.
This is a known issue. Star(on the top left) the issue to let Google know that you're affected and for the issue to be prioritised. Some of the features you requested is already in development
New IDE features Monaco for cutting edge code editing, streaming logs, reliable debugging and Material design. Seamless integration into the G Suite Developer Hub lets users design, develop, deploy and manage their projects all in one place.
In the meantime, You can use clasp in your local IDE.
Related question:
V8 engine no longer breaks on errors
I've just encountered a really bizarre scenario and can't find any info on this elsewhere. When Xcode breaks at my breakpoints, all keyboard entry for the whole system is unresponsive. I can switch to another app but no key strokes are recorded. Xcode itself is unresponsive to keyboard input.
Anybody else seen this?
I'm running 10.10.1 and Xcode 6.1.
Based on the comments above it would seem that this issue has to do with behind the scenes details of Powerbox. To explain further: my app is sandboxed and calls NSOpenPanel. When breaking (Xcode breakpoint) in the completion block of NSOpenPanel I experience system-wide keyboard input loss.
Keyboard entry behaves normally in breakpoints outside of the call to NSOpenPanel. After working past this area of code I observed that my subsequent operations (queued in the background from the completion bock) often finish before the NSOpenPanel is completely torn down (disappears from the screen). My assumption is that until NSOpenPanel is removed from the screen (and maybe further after), Powerbox won't release control of the keyboard.
Much of this is assumption since I don't have the actual Powerbox code and can't step into it but it seems to fit.
I worked around my debugging issues by utilizing print statements and stepping through code with the variable inspector open. Mouse input continues to function so you can right-click (if you have a two-button mouse) on the variable and print its description at least.
Thanks for the help Ken.
UPDATE
I am now delaying execution of any of my post-NSOpenPanel actions using dispatch_after. On my system a delay of 1 second is doing the trick. I really don't like adding arbitrary delays but this seems to work.
I am using BitBlt heavily in my project. I create a number of threads and in each thread I capture the screen by BitBlt. It works great and as expected for now except the following problem.
The problem happens when the user clicks on a running program or for example already opened explorer on the taskbar. You know when you click on the running program on the taskbar, it either minimizes or appears on the screen. The issue that I am talking about happens just in this transition. At that moment, something like an interrupt, all threads stop capturing the screen for a fraction of a second and then they continue capturing. The same thing happen when you move down or up the thing on the volume control window. Could you please shed some light why this is happening and how I can prevent this happening?
Thanks.
Jay
It could be a scheduling issue. When you activate an app, it gets a small, momentary boost in its priority (so that it can seem responsive in the UI). This boost might last about as long as the animation and momentarily pre-empt your screen capture threads.
It's also possible that the desktop manager is serializing stuff, and your bitblts are simply stalled until the animation is over. Even if you've turned Aero off, I believe the desktop window manager may still be in compositing mode, which has the effect Hans Passant was describing in the comments.
If you're trying to make a video from the screen, I think it's going to be impossible to rely on GDI. I strongly suggest reading about the Desktop Window Manager. For example, this caveat directly applies to what you're trying to do:
Avoid reading from or writing to a display DC. Although supported by DWM, we do not recommend it because of decreased performance.
When you use GDI to try to read the screen, DWM has to stop what it's doing, possibly render a fresh copy of the desktop to video memory, and to copy data from video memory back to system memory. It's possible that the DWM treats these as lower-priority requests than an animation in progress, so by the time it responds to the BitBlt, the animation is over.
This question suggests that DirectShow with a screen capture filter might be the way to go.
My Visiual studio hangs all of a sudden when debugging the windows application. It's takes while to repond and but it's closing my application. I keep getting this issue everytime in every debugging session.
Please help to fix this problem.
Your application also stops responding right? If so, I presume that your application is giving VS problems. Presumably because some operation is tying up the main thread. When that is tied up no other events can be processed (button clicks, screen redrawing, close buttons, etc). That could be caused by an infinitive loop, or perhaps Disk IO or waiting for a network connection or a database query result, or a deadlock.
My suggestion would be to do some type of logging so you can identify where the problem is at. For instance, put a breakpoint at the top and bottom of major functions. After you break at the top one, hit play. If you don't hit the bottom one you know that the problem is somewhere in that area.
Or, do some sort of logging like putting Console.WriteLn("Entering MyFunction()") at various places in the code.
Once you know where the problem is at, you can fix it.