When my program is paused in Visual Studios 2010 during debugging, like from reaching a break point and me doing a manual step through, the program window becomes impossible to view.
It is a GUI window not a console window, which I run simultaneously with my program and am still able to view. The window seems to be open it's just that when I click its icon on the taskbar it doesn't come to the front of all the other windows. When I minimize all the windows in front of it, I see the outline of the window but it is either blacked out or showing the remnants of previously expanded windows.
I've noticed this with using Visual Studio's before (various versions of it), and after trying other IDE's that didn't have this behavior I notice it more. It would be really helpful to view the program's change's as I step through the program. Anyone know how I can do this?
I searched a long while and couldn't find a single reference to this matter.
The reason the window doesn't display is that the window paint message won't be processed if the main thread has been paused. Which other IDEs let you do this? I haven't come across any native code debuggers that do this on Windows.
If you are stepping through code that is run by the main thread, then the main thread can't simultaniously poll the message pump, which is needed for the GUI to work.
If you debug a different thread, the GUI will work while you are debugging.
Related
this has been bugging me for quite a while now.
I'm using two monitors and usually have the main window of Visual Studio open on the primary monitor and things like the solution explorer, call stack, error list, output etc. on the second monitor in two separate windows which I split vertically by using the [Win] + [Left | Right] shortcut.
In another environment, this works fine (VS 2013, different machine). Of course, the window positions etc. are different between debug and regular view, but that's not really an issue.
Whenever I start debugging, the solution explorer window moves towards the right on the second monitor. This might even affect the other window (which contains the Call Stack, Output etc.).
After a few debug sessions, the window will be barely visible any more because it has moved so far towards the right...
This is even worse when I have multiple solutions open because then the solution explorer window that I see is actually the one from the instance in the background...
Has anyone else experienced this? Any ideas how to fix this?
P.S.: I'm working on a windows server via a RDP session, maybe that contributes to the problem.
The following worked for me.
Under the Windows menu, save the desired layout with "Save Window Layout". I named mine "Debug". This might have something to do with the old layout names.
Stop debug mode if your in it, and apply that layout with "Apply Window Layout".
Start debug mode.
My un-docked windows flash as if they are resizing, yet stay where I had them in the saved layout.
Is there a facility in Visual Studio, when debugging a desktop app, to remember where the mouse was when I hit a break point so that i may use it in Visual Studio while stepping through code, and then snap it back to that spot when I resume execution? This would help in mouseover events and other position-sensitive workflows.
If there's not something built in, would it be possible to do this with a Visual Studio plugin? Or is there a way to install a hook such that the debugger sends my application an event or interrupt that it could use to save that state on break and restore it on resume?
Thank you.
There's nothing built in to the VS debugger to do this. It's more than mouse position, there are likely subtle state changes (like focus and activation) that would be difficult to save and restore reliably.
A quick and dirty thing to do is to add some OutputDebugString messages to the code in question to give you clues as to what's going on internally without actually breaking the execution. VS will show the messages in the Output window.
The only way to come anywhere close to what you're after is to use remote debugging. You can remote debug your code running inside a virtual machine so that you don't actually need a separate physical machine.
I find myself working with GUI code where the GUI program needs input focus and remain the topmost window, but whenever I'm debugging with VS stepping-through with F5/F10/F11 requires that VS has focus.
Is it possible to have VS intercept the F-keys whilst the debugee has focus? If VS doesn't have this functionality I imagine it should be possible to write a simple program or VS add-in that has a keyboard book and commands the debugger accordingly - has anyone developed such a program?
I'm working with a GUI test automation framework that sends mouse-clicks and other events by moving the cursor. When the debugee program is out of focus any click on its surface brings the main window forward but does not activate any controls, but the automation framework assumes that its focus of the application will never be interrupted. So if I set a breakpoint before a click that is meant to open the File menu then the click that is sent will only restore the debugee's focus and not open the File menu (if that makes sense).
I've done some searching but couldn't find anything immediately.
Why do you need to maintain focus? Have you specific hooks in the GotFocus/LostFocus?
I've had problems before with the Paint event being called as soon as F5 was hit causing the debugger to show again and therefore requiring another repaint. I got around these simply by arranging my windows so they didn't overlap. I'm pretty sure the LostFocus/GotFocus pair also don't fire when the windows are arranged this way too.
TL;DR - How does the Spy++ tool really construct its process list?
Stage
We have an MFC desktop application (running on Windows XP) that is hanging in that it doesn't react to any user input anymore. It is redrawn when switching to it via alt-tab however. (It does receive WM_SETFOCUS, WM_ACTIVATE, etc. It apparently does not receive any mouse or keyboard messages.)
Since the app is hanging in some limbo, we pulled a few process dumps, but these were of little help so far. Enter:
Spy++
We used Spy++ to find the information I gave above about the window messages this application seems to be processing. We did this by Opening the Windows View and selecting our application Window and in the Messages properties selected Windows of same process and Messages to View : Select All.
However we first tried to view all messages of this process by opening the Processes View of Spy++ and our application is not shown in this process list. Cross checking on another PC where the app is running normally, the process is also normally shown in the processes list of Spy++.
Can anything about the misbehaving app be inferred from the fact that the process is not shown in Spy++'s Process View, but the main window of the app is shown in the Windows View. Why would a process with a main window that is visible not be shown in Spy++'s Processes View?
The process is listed in Task Manager and in the Attach Process Window of Visual Studio 2005. So these tools apparently use a different method to list processes than Spy++ ... ?
The system where the app is currently hanging is a Windows XP SP2 system and we've used the Spy++ Utility that comes with Visual Studio 2005.
The behavior does recur occasionally, but only after the App has been running for several days!
Running Vista or later? Your process is probably elevated and Spy++ is not. Newer versions of Spy++ require elevation. So, try elevating Spy++ explicitly and see if that helps.
Yes, of course things can be inferred from this. Don't take anything I say too seriously in this context, I'd have to go look at the code. But I believe that Spy goes off and looks at the EnumProcesses API. (http://msdn.microsoft.com/en-us/library/ms682629.aspx)
So, if your process isn't showing up there... hrm.
But, what is different between the system where it's working and the one where it's not?
Spy++ requires the following two values in the registry to be disabled (0) to display the processes/threads list AT ALL:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
HKLM\System\CurrentControlSet\Services\PerfProc\Performance
Disable Performance Counters -> either 0 or not present
Was going insane trying to find out why it refused to display them. It's some kind of bad joke - this debugger requires itself a debugger to get it working! Not that WinDBG would display any meaningful info, MS doesn't even provide a symbol file on their symbol server, pfft.
Anyway, maybe it doesn't display processes that have their performance counters disabled, because I think, this can be set on individual basis, at least for services, like:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
Disable Performance Counters
So it's basically always a value of the "Performance" subkey. All this stuff is undocumented, it makes use of advapi32.dll functions like "PerfRegQueryValue" and "PerfRegQueryInfoKey"... don't ask me.
I use Visual Studio 2008. I haven't seen this behavior before and, as far as I know, I didn't change anything in the options.
When I press Start debugging all the possibly windows (watch 1 - 4), data sources, properties, registers (to be honest I have not even ever seen these windows before) appear in front of the code window and stay there after I stop the debugger.
Anyone has an idea what could be causing this ? (I am using CodeRush and Refactor for quite a while now)
When I close and restart visual studio all the windows are where they should be.
PS: Previously I have seen normal switching from normal to debug mode and back with some repositioning changes. That is the way it used to work. Now it is not. It has suddenly gone mad and when going to the debug mode it sometimes shows all possible IDE windows and sometimes not. When it does it no longer returns to the previous state. I cannot find this in the options anywhere.
Visual Studio remembers 2 sets of window layouts, normal mode and debugging mode. My solution is to arrange my normal windows exactly like I want them, then start debugging an application and once again arrange all of the windows the way I want, usually making it as similar to my normal layout as possible, then stopping the debugger and doing a File Exit so that VS saves my settings.
After doing that, it recalls my 2 different layouts each time.
I'm experiencing the same thing - whenever the debugger is running, switching focus back to the IDE immediately caused the debug panel to expand.
I ended up just pinning the debug panel so that it always appears when debugging, and just changing its height as needed.
To add to palehorse, another tip is Full Screen mode.