I'm trying to write a debugger.
My problem is, debuggee windows is left open even after the ExitProcess in it is called. Debugger receives EXIT_PROCESS_DEBUG_EVENT, but debuggee window is still visible and does not react to anything. It does goes away with the closing of debugger though.
What can be the cause of this?
Just as RbMm said, "faster of all you not call ContinueDebugEvent on EXIT_PROCESS_DEBUG_EVENT"
RbMm, copypaste your answer as answer if you care about reputation, I'll accept it.
Related
In my app I use a RichEdit control (RICHED20.DLL) with syntax highlighting implemented on top of it. Quite a lot of code was necessary to make this work correctly. Internally, everything is stored as RTF and reformatted on the fly. This code has been working stable for over 10 years now in lots of different environments.
However, recently one user has managed to make my app freeze. He even managed to come up with a description of steps that can be used to clearly reproduce the freeze. Thus, I was able to debug it with WinDbg and got the report that it hangs in CTxtEdit::TxSendMessage. This is what WinDbg says when I break the program as soon as it hangs and do a !analyze -hang in WinDbg:
Probably caused by : RICHED20.DLL (
riched20!CTxtEdit::TxSendMessage+132e )
So does this look like a bug in the RichEdit control? Is there anything else I could debug here? I don't really know where to look because the hang is apparently not in my app. I've already checked and made sure that neither the WndProc of my RichEdit control nor the WndProc of the top-level receive any messages during the hang. It really seems to hang in RICHED20.DLL so to me it looks like a RichEdit control bug.
Could that be the case or what else could I try to debug the issue further? I'm out of ideas here.
When I call stop on my AVAudioRecorder instance XCode stops at a breakpoint. However, no exception comes up and I don't have my own breakpoint set there. I do have an "All Exceptions" breakpoint setup.
I hit continue and the app runs fine - no message in the console.
What's going on?
It is the All Exceptions breakpoint. AV Foundation is throwing an exception and also catching it, so no harm, no foul (which is why the app can resume without a problem) - but you are set to break when that happens, so you do. When the app runs for real (independent of Xcode) no one will know; it's just Xcode and your All Exceptions breakpoint that brings it to the surface.
AV Foundation is full of places like this. I regard it as a bug, but not enough to care very much. I just turn off the breakpoint when working with AV Foundation; otherwise we'd always be stopping...
Try 'step in' at method declaration in your code. This should take you to the definition of method being called, and you can 'step over' from there. Hope this may help you.
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.
Say I'm debugging an application. It's paused in the debugger. I hit the Run button. The application being debugged gets focused (and Visual Studio loses focus).
Is there a way to prevent this behaviour?
(And, as a bit of an aside: Why does this happen? Is it Visual Studio deliberately giving that window focus? Or is it a side-effect of the way debugging works on Windows? Or something else?)
For context, see this answer. Although I imagine that, if possible, it would be useful to prevent the focus change in other debugging scenarios as well.
It because the alternative is so much worse, focusing events are a Big Deal in gui programming. A debugger must have the absolute minimum impact on the program being debugged to avoid artifacts so restoring everything the way it was before resuming execution is important. Including the focus.
It just a quick Alt+Tab to get back to the debugger.
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.