When I'm debugging in Visual Studio, I set a breakpoint where I want to start and press F5. When I continue pressing F11 to do a step by step process of how the program runs, when I get to a standard library function e.g std::cout the runs through all the steps in .
Is there anyway I can stop this and allow it to just be more localized? I've had a play with the settings but not stumbled across a way to do it.
I'm completely new to programming so I apologize if this is a simple fix.
Many Thanks
There are two other stepping commands that will likely be helpful to you:
Step Over (F10) - Steps over a function without going into it.
Step Out (Shift + F11) - Steps out of the current function.
Related
I'm using Visual Studio and would like to use the keyboard to go to the previous/next breakpoint. I had a look at Options|Environment|Keyboard but found no such command.
Is there a way to do it?
For people wanting to see each breakpoint, that ended up here. (Like me)
Try Debug -> Windows -> Breakpoints.
You can jump to breakpoints during debugging of application. Here is a list of shortcut keys that might help you.
Create or remove breakpoint on the current line: F9
Execute code one statement at a time, following execution into function calls (Step Into): F11
Execute the next line of code but not follow execution through any function calls (Step Over): F10
Execute the remaining lines of a function in which the current execution point lies (Step Out): SHIFT + F11
Restart a debugging session : CTRL + SHIFT + F5
Resume execution of your code from the current statement to the selected statement (Run to Cursor): CTRL + F10
Run the application (or jump to next breakpoint): F5
Use 'Run To Cursor' (CTRL+F10). The debugger will execute your application up to where your cursor is and break. For more details visit: How to skip over code in the Visual Studio Debugger
If you want to just want to navigate and not use debugger, I use an extension called Bookmarks by Alessandro Fragnani. It's super useful when you have to navigate forward and backwards through long lines of code on a page and even faster if you setup shortcut keys.
Here is how to Configure
I've configured mine shortcut key Manually
Is it possible to set a starting point for the debugger so that every debugging session
will start immediately from that point (instead of starting from the beginning of the code)?
Or to express it differently:
Isn't it possible to somehow store everything until the breakpoint so that next time the debugger could just instantly resume to that specific breakpoint (instead of starting from the beginning of the code and pausing at the breakpoint)?. Is there any debugger that can do this?
I am using Microsoft Visual Studio Express 2012.
Thank you.
Use a Debugger in visual studio.
In your code, click on the line number, you will see a dot on the line.
When you run the program, it will 'pause' at the line you specify, you can then walk through your program line by line from there
You can use a breakpoint at a line that you want to inspect.
You have a description how to do it here.
You could attach a debugger to a running process, but i'm afraid that it will be on a random place of execution. You could make a wait for a key or button press in your code and attach to your program before continuing.
No. It would have to run the code up to the point you want to get all the variables etc in the right state. If you just set a breakpoint where you're interested from and hit F5 it should get there quickly enough.
If it doesn't get there quickly enough, jot down the variables used and make some unit tests round the troublesome functions instead. That will skip the 10 minutes.
Anyone else having issues with using F11 to step into code?
Until about an hour ago, I was able to perfectly step through code in both C# and C++ projects with ease, but now I suddenly have to press F11 at least 10 times before it will goto the next line. It's not even an issue of lag, as pressing and waiting has no result, it literally has to be hit 10 times every time I want to step into code. The same applies to the button on the GUI.
It started after playing with the Immediate and Command Window's (which are really useful by the way), I didn't use any commands that dealt with stepping into code, just commands for starting and stopping debugging.
Could I have accidentally enabled a "Make debugging retarded" option?
Googled everywhere for a solution, seems everyones had F11 problems but nothing like this, so any help is greatly appreciated
I am getting difficulty debugging my custom IIS module written in C++, using VS 2010. The problem is that IIS worker process (w3wp.exe) starts too quickly and there is no way to catch it at the beginning in VS "attach to process" dialog. Is there a good skill to do this? Thanks.
You can add a Debugger Breakpoint in your code . I use this all the time to catch things that are too fast to catch manually.
FYi in .net you use System.Diagnostics.Debugger.Break() to achieve the same effect.
It causes the windows system debugger to be activated.
A trick that I have sometimes used is to introduce an artificial infinite loop at the entry point of my code, I then set a breakpoint in this loop and simply move the next instruction to be out of the loop when the breakpoint is hit - job done!
In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.
It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?
EDIT : I've managed to reproduce my problem with the following code :
static void Main(string[] args)
{
XElement e = new XElement("root");
Test(e, 0);
}
static void Test(XElement parentElement, int i)
{
if (i < 1000)
{
XElement element = new XElement("element");
parentElement.Add(element);
Test(element, ++i);
}
}
You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.
But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.
I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.
If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.
I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.
I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.
Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.
I have no idea how that would cause your program to continue after that point however.
Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.
Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.
I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.
Please download the fix from this link
http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912
I know this is an old thread but this occurred when debugging an Excel add-in in my case.
Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.
Once I removed that watch, it debugged just fine again.