Link to home
Start Free TrialLog in
Avatar of userTester
userTesterFlag for United States of America

asked on

C++ debug in Visual Studio

I am using Visual Studio 2013 and coding in C++.

When in debug mode, stepping through the code, usually I see my code, and then some other code, probably part of the C++ library or something.

Problem is that I only wish to step through the code I created, since stepping through the other code is a waste of my time at this stage.

Is there a way to have VS step over the entire other code so I can focus on my code?

In simple terms, in VS, how do I step through my code only?
Avatar of HooKooDooKu

F10 - Step Over Subroutines
F11 - Step Thru Subroutines
Avatar of userTester


I usually use F11 to step through my code, but it is not always obvious when to use F10.

I need to know if there is a settings option or "trick" that will allow me to step through my own code only.
You just have to know what is your code and what is NOT your code... the IDE doesn't really have a way of knowing the difference.

About the only type of thing that comes to mind is that if you don't have access to the source code, the IDE can't step thru it.  But in those cases, if you press F11 to enter a subroutine that the IDE can't access the source code, you get an error message (and perhaps an opportunity to step thru the machine code).

But at a minimum, you have to know what functions are yours and only use F11 on those.
All the code I see is mine, but with some of my code it suddenly starts stepping through some C++ template code, or something else.
At this stage, it's really annoying, since it happens when the step though hits cout, vectors, for loops, and more. There has to be a way to skip "this other" code.
Avatar of phoffric

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
You can actually enforce that, but it's quite tedious. Basically you'd switch to a release build and then manually add debugging info to your project and disabble optimizations. See ("How to: Debug a Release Build").
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@pepr: Thanks for the Ctrl+F10 trick. I have put so many unnecessary breakpoints to step over long loops or other functions.
I guess there's no easy solution for this one?
Thanks, you provided a few tricks, thanks.
>> I guess there's no easy solution for this one?
I think your conclusion in closing this issue is correct. Although you closed this question, I thought I'd add this in for future reference. While working In gdb, I found that it is easy to skip over functions or files:

I figured that MSDN might have some equivalent. What I found in the MSDN Blogs is a clunky counter-part in VIsual Studio that requires Windows Registry changes (potentially dangerous if you make a careless error), and according to one MSDN Blog article, you need admin privileges. The approaches in these blogs are not documented in MSDN. The information is provided in one case by a MS Program Manager.

Here is an excerpt from one blog:

To avoid stepping into any templates in the Visual Studio debugger, you can add a rule to the StepOver registry by following these steps:
1.Open the Registry Editor (regedit.exe)
2.Navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\NativeDE\StepOver registry key
3.Under the StepOver registry key, create a new String value (REG_SZ) with the following information
Name:            8-OMINO: C++ class and function templates
Data:            \anything:[\<\>]\anything:=NoStepInto
Here is a longer blog with additional details. Although the article was written in 2004, it has been updated to Visual Studio 2012, and the author points out that everything has changed, so be careful to see whether more things have changed in Visual Studio 2013.

Here is one example:
Windows Registry Editor Version 5.00
It is odd that Microsoft requires a registry change that affects every developer rather than allowing each developer to have a simple command to customize to their own needs. Wish I could help you more, but I re-installed VS 2010 after 2012 did not work, and then I learned that a basic editing command in VS 2013 produced non-pretty print results, so I never installed that one.
Hey Modalot. Interesting to see if you delete phoffric's answer who provides exactly the same solution as myself but siting different sources
I get it. Period.
How about that: If you have allowed citing sites like SO, or codeproject I would be happily provide a link. However, as soon as you see it on your site you remove it straight away. BTW, I have not claimed the article I have "plagiarized" is mine. In fact I asked the author to google it on the codeproject site (very easily found there) and check out other useful tips. I felt just uncomfortable writing it "in my own words - though it isn't that difficult" without any reference. FYI, the author of that article is a MVP.
OK, next time I see a reference to a codeproject, I will provide a link. Will see how long the post survives.
@userTester: Sorry about this. I know you do not deserve this. There is just no way to reply on the "Member Comments" the moderators send you in a way of "private messages". I still struggle to find a reply button there
Hi chaau,

I read your comments with some interest, so let me tell you about my story. I once gave a blind link recently and was notified about the EE TOS. And I see that you also have heard about competitive sites. This question was closed with a work-around to the problem, at least to reduce the burden of stepping into undesired standard library functions.

Now, I am currently in a Linux environment, and because in one VM I didn't have access to a nice GUI debugger (I use ddd and cgdb, and tried today with gdb -tui, which was awful), I started learning gdb in more depth.

When I stumbled across that "step over" gdb link that I posted, I remembered this question, and said, if gdb has a simple command, maybe MS has one. I was wrong. MS likes to keep things hard it appears. I searched for an authoritative source (in this case a MS Program Manager) and while still unhappy with the solution because it requires admin privileges and changing the registry that affects all users on the machine (so the article says), I posted it in case the author wanted to take the risk of modifying the registry.

And I pointed out that still there were no guarantees because the author is interested in VS 2013, and the latest info I could dig up was for VS 2012. And VS 2012 "step over" solution was significantly different from earlier versions. So, unless another MS employee comes up with a new registry solution, the post I provided is not guaranteed to work for VS 2013. (One assumption I made about the author is that he would know to back up his registry and create a restore point just in case; but maybe I should have mentioned that for others EE users asking this same question.)

I had to spend a decent amount of time to dig up the authoritative insider sources, and I guess Netminder realized that and allowed my post to remain. I was curious about this issue when I saw the gdb equivalent, and so I just wanted to share my findings.

If I had VS 2013 installed, and came across whatever competitive sites were giving out answers, then I would have definitely confirmed the solution on my own workstation, and maybe even write my own little article about my own usage of this technique. And then I would provide an EE link to that article. (Or, if too busy, I would just write up a post of what I accomplished to help others.) In the end, from my own tests, I would become more expert in this question.

BTW, even in the MSDN blogs, there were so-called experts who were offering the same advice as provided here. Why MS would keep their approach undocumented? I can only make two guesses. They are too embarrassed to publish it (change the registry!!); and/or it gives them a competitive edge in application development in not having to step through complex templated functions.