I have not been able to track down why random actions in Visual studio 2010 will cause the keyboard and/or mouse to start performing different actions than anticipated or more often than not, stop responding to certain actions.
I never loose complete control, but I could return to VS from another screen and any of the following could occur:
Clicking on text with the mouse, acts like I have the shift key down and tries to highlight entire areas
arrow keys will no longer move the cursor
Delete, backspace or enter will stop responding
I am not sure that it is always after returning from running an application/debug, but that is definitely a majority of the times that I encounter the issue. Most of the time I have to completely shutdown VS and restart to get keyboard functionality back. Most of the time, other functions still work such as typing.
I should note, that I always check another application that those keys are responding as they are expected to verify it is only in VS that the problem is occurring.
Any thoughts?
I have occasionally, and for along time, seen "sticky" modifier keys (Ctrl, Alt, Shift) in VS, especially after quitting a debug session. For me it's usually the Ctrl key which turns Shift-F5 (stop debugging) into Ctrl-Shift-F5 (restart debugging). That's a bit frustrating.
The best fix I know is: when you notice this behavior, give each of the modifier keys a press to "un-stick" them, which sounds like what you're doing when you "check another application."
Related
When I am debugging in Microsoft Visual Studio 2017 my "Registers" window shows no data available. What can I do to fix this?
As Sneftel stated, you cannot inspect data in the debugger unless you break the execution of the process. During execution, things would be changing far too quickly for any data display to be meaningful.
You can use the "Pause" button in the toolbar to break execution, and then you will see everything in the debugger: the current source line, the contents of registers, your "watch" variables, the full contents of memory in the "Memory" window, etc.
You can also set a breakpoint on a particular line of code, and then execution will break once that point is reached.
Once paused, you can then single-step through your program's code. This means that one line of code (the very next one) will be executed, and then the program will break again so that you can see everything in the debugger. This is an excellent troubleshooting technique—one that you should be well-acquainted with. In fact, I recommend that you single-step through every line of code that you write, just to make sure that it works correctly. You can also modify the contents of registers and variables (or, really, any location in memory) while you are single-stepping, giving yourself a way to test potential bug fixes or even introduce bugs (e.g., invalid input) to see how your code handles them. The default keyboard shortcut for single-step is F11.
You'll find more information about using the debugger, and the available keyboard shortcuts, here on MSDN. As you can see, that article confirms my answer:
Most debugger features, such as viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only while the debugger is paused (also called break mode). When the debugger is paused, your app state is suspended while functions, variables, and objects remain in memory. While in break mode, you can examine the elements' positions and states to look for violations or bugs.
(Edit-and-continue is not available in assembly projects. You will need to stop execution and rebuild if you want to make changes to your code.)
For those with the "No data available" message, you can right click in the Registers window and choose what you want to see (UC, MMX, SSE, etc). It seems like by default there's nothing selected in Visual Studio 2019. At least, on mine there was nothing selected.
So I have this weird problem where I press keys subconsciously sometimes. F10 (step over) and F11 (step into) are two that I keep pressing... or if I meant to hit F12, sometimes I hit F11 accidently...
Anyway, this is a major annoyance since it starts a build, which takes a while, I immediately start spamming CTRL + BREAK to break the build, but it only rarely works; it seems that it just freezes or maybe there is only a short window of time where it does work? Then if the build succeeds, my configuration is set up to do a deploy as well, and often, VS just locks and I have to end the process with Task Manager and restart VS.
So just wondering if there is any possibility to only allow F10, F11 to work when pressed if I am debugging, where I actually need it (I use attach to process so F5/F10/F11 are useless shortcuts when not debugging)?
Thanks.
You can assign F10 to the following C# command for Visual Commander:
if (DTE.Mode == vsIDEMode.vsIDEModeDebug)
DTE.ExecuteCommand("Debug.StepOver");
It will call StepOver only when you are in the Debug mode. For F11 use Debug.StepInto.
I had the same problem - kept randomly hitting F11 instead of F12. I ended up re-assigning F10 and F11 to something innocuous (like Find Next / Previous) and then re-assigned StepOver / StepInto to Ctrl-' and ctrl-; respectively (these are the same shortcut keys used by the Chrome debugger).
Perhaps a bit extreme, but it works for me. I now have a new problem though where I occasionally invoke Find Next when debugging :) On balance the new problem is less annoying.
If I hit F12 while my application runs under Visual Studio in debug mode, the WM_KEYDOWN never reaches my event loop, but it immediately triggers a breakpoint. Is it possible to disable this feature, or reassign it to another, less conflicting hotkey (e.g. CTRL+F12)? I figure the must be a registry key, but I can't find it...
Any help is greatly appreciated!
F12 is a reserved key for the debugger and its kernel-based https://msdn.microsoft.com/en-us/library/windows/desktop/ms646309.aspx
But you can change the registry entry
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug] UserDebuggerHotKey=dword:00000000
to something else like 0x13 (Pause)
got this from http://conemu.github.io/en/GlobalHotKeys.html
You can disable it from Tools->options->Keyboard
It's easy to reassign a value like that to whatever you want.
1) Go to Tools/Options and click on Keyboard (under environment). Then find the command associated with F12. Which one depends on which mapping scheme you use, so I can't tell you the one to find.)
Then change it to whatever you want.
Too bad I can't add comments...
When I type in F12 (for Press shortcut keys), I get Edit.GoToDefinition. If I remove that assignment and then try again, it shows how it is used with Page Inspector.
If you enter F12 and nothing shows, then you can assume that VS is not using F12 and something else is.
You can just try assigning F12 to something and see if that is called instead - then at least you will have some idea of if VS is controlling it or something external to VS is.
Remember that you could also have some application that has remapped F12 so that when you press it, your application is getting a signal that some other key or key combination has been pressed (happened to me once.)
When i am debugging my program and an error occur, the debug session ends, but the program remains in memory. Using the activity manager of Windows to close it does not work. I need to close Visual Studio in order to kill the process.
Why is this happening?
When during debugging a program error occurs, the program usually does not "end". Instead, the debugger (VS2010) pauses execution, allowing you to inspect the code resulting in the error. Depending on the language used (e.g. C#) and the way you compiled your program, you may even be able to edit the program on the fly, move the execution cursor back a bit and continue the program from there.
If the Debug toolbar is visible (in my case it shows up automatically whenever I'm debugging), you should see a couple of "playback" buttons, allowing you to start/continue, pause, stop your program etc. If you stop your program, it will be gone from the task manager too.
As I mentioned in a comment on your question, you can also use the Debug menu to accomplish these tasks.
I like how you can capture breakpoints as Intellitrace events. Breakpoints are easy to add/enable/disable, and can be added/removed at runtime (as opposed to say Console events).
However, of course breakpoints stop the flow of execution, and I have to press F5 F5 F5 F5 F5 F5 constantly while I debug the running application. I'd love to be able to capture breakpoint events in intellitrace and just let the code execute without actually breaking on the breakpoints.
I've also used Console statements as captured intellitrace events, but breakpoints are much easier to add (F9 as opposed to pasting a Console.WriteLine("...") everywhere), and I can add and disable new breakpoints at runtime, whereas if I want to add or remove a Console based event at runtime, I have to stop the program, add/delete, and restart.
Are there any good ways to capture intellitrace events in this way?
I think this is what you are looking for:
http://geekswithblogs.net/sdorman/archive/2009/02/14/visual-studio-2008-debugging-tricks-ndash-advanced-breakpoints.aspx
Basically, you can use an advanced breakpoint to do a number of different things. In your case, you would probably want to use the tracepoint that simply gives a hit count. In other cases, you might want to specify that the breakpoint only occurs after a certain number of hits (maybe you want to be sure a loop isn't infinite).
Visual Studio has a ton of great features inside of the breakpoint option. I'm sure that even if the above option didn't solve your problem that there is still something that is included in the above article that will solve your problem.