Visual Studio 2010 debugger steps over methods and doesn't stop at breakpoints

Asked 10/1, 2011 at 16:39 Answered 3/4, 2017 at 18:47

Solved visual-studio-2010 debugging

My Visual Studio 2010 debugger sometimes has a very strange behaviour...

Sometimes it doesn't stop at breakpoints, but when it stops, and I want to step into a method, the debugger just steps over it. Also the breakpoints in those over-stepped methods are ignored.

When this strange behaviour occurs, it also does not break on exceptions but simply ignores them.

I've tried to rebuild my project, reset the Visual Studio settings and disabled debugger settings like "Break only in my code", but nothing has worked.

How do I solve this problem?

Residual answered 10/1, 2011 at 16:39 Comment(4)

release of debug configuration? in release configuration some of your code can be removed by optimizer so debugging can look weird – Delative 10/1, 2011 at 16:41

Does this happen in one kind of debugging session, or is it random. For example, if you are trying to debug a running service by attaching to process, or are you just trying to run code in the debugger? – Atwitter 10/1, 2011 at 16:41

@robin hood The configuration is set to debug @Jesse McCulloch I'm just running the code in the debugger, but there it happens random – Residual 10/1, 2011 at 16:44

This was a problem in VS2008 SP1 as well. There was a hotfix for that, but not all of the fixes where checked back into the trunk. Service Pack 1 is coming soon, now in beta. You could try it now, avoid doing so on a production machine though. – Margarethe 10/1, 2011 at 17:3

I've found the solution of the problem and it is really simple:

In my solution's build configuration, the "Build" check-box of the project where the methods are, that get over-stepped, was not checked. I checked it, and now everything works.

Residual answered 11/1, 2011 at 7:18 Comment(1)

where is build configuration, i'm on vs 1013 – Yadirayaeger 24/2, 2016 at 9:1

Here are a couple of reasons and workarounds for why Visual Studio will avoid stepping into a particular method.

Just My Code is enabled. In certain circumstances the "Just My Code" setting will prevent you from stepping into a method / property. To avoid this you can disable "Just My Code" in the debugger options page (Tools -> Options -> Debugger -> Uncheck "Just My Code")
Symbols are not loaded for the target method. If the target method is a part of another DLL it's possible that symbols are not loaded for that DLL and hence Visual Studio will not be able to step into it by default. To force the symbols to load, open up the Modules view (Debugger -> Windows -> Modules), navigate to the DLL containing the method, right click and load symbols.
The method is explicitly marked with a debugger attribute such as DebuggerNonUserCode which causes the debugger to step over the method.
The method is actually a property or operator and you have "Step Over Properties and Operators" setting enabled (this is the default). This can be disabled via the debugger options dialog.

Prescribe answered 10/1, 2011 at 16:52 Comment(3)

In Visual Basic Express 2005 (don't ask), "Tools -> Options -> Debugger -> 'Just My Code'" does not seem to be available. One solution is to change "1" to "0" in file "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\VBExpress\Profiles\VBExpress.vssettings" at line containing "JustMyCode" and import the file into Visual Basic Express 2005. Details are in Josh Dannemann's comment to How to Disable “Just My Code” in Visual Studio 2005 and possibly on Stack Overflow somewhere. – Stupefaction 14/12, 2011 at 15:22

I have now documented it in How do I disable 'Just My Code' in Visual Basic 2005 Express?. – Stupefaction 8/10, 2012 at 23:34

Another possibility to add to your list is the DebuggerStepThrough attribute which is frequently added by generators to generated code (e.g. XML generated code) – Emplane 28/4, 2014 at 21:55

In my case it was "Step Over Properties and Operators" in Tools -> Options -> Debugger. Just had to uncheck that and after that everything was fine, I could step into.

Fungistat answered 29/6, 2012 at 15:26 Comment(0)

Another source of confusion is iterator methods that use the yield return operator because they are rewritten by the C# compiler in such a way that stepping into them (F11) is kind of a "no-op".

You must wait for the iteration to occur to break into the method's code.

Stochastic answered 15/4, 2016 at 9:5 Comment(0)

I've found the solution of the problem and it is really simple:

In my solution's build configuration, the "Build" check-box of the project where the methods are, that get over-stepped, was not checked. I checked it, and now everything works.

Residual answered 11/1, 2011 at 7:18 Comment(1)

where is build configuration, i'm on vs 1013 – Yadirayaeger 24/2, 2016 at 9:1

The most important thing to check is whether when trying to put a new breakpoint inside the method it refuses to step into, if the breakpoint is filled red liked the others, or half filled or has a special "look". If it does, hover over the breakpoint you created to find out why it isn't working.

If the breakpoint looks normal but still you can't seem to step into the method, try clearing the shadow copy cache: http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx

Another thing to try is to make sure that you are indeed using the DLL you've just rebuilt by adding a MessageBox.Show (or something similar) to the method you can't seem to stop at, and make sure you get the box.

Ravenravening answered 10/1, 2011 at 16:47 Comment(3)

I've tried you suggestion with the message box and indeed, no message box appeared when I ran the program. Now I will try to find out, why the method isn't called properly. – Residual 10/1, 2011 at 17:17

As Jared suggested, the best way to spy on these issues is by using the Modules window (Debugger -> Windows -> Modules) to check the DLL that is loaded is indeed the one you just build - verify this by looking at the DLL's date last modified. Something that works great for me when having these type of issues, is to use Everything (voidtools.com , free tool that's a must for programmers) to search for the DLL name, and sort by Date Modified. You're likely to find both the path of the DLL where it was just rebuilt, and the path of the stale copy of the DLL your app is loading. – Ravenravening 10/1, 2011 at 19:16

Debugger -> Windows -> Modules worked for me -- my DLLs were ending up in a weird place due to recent changes to their projects by other team and some older versions of DLLs were being picked up. – Est 28/3, 2013 at 0:3

I struggled with this for a while. None of the answers given worked for me. I finally got it to work by doing the following:

Make sure the project is in debug mode (all projects)
From Windows go to a Command prompt and be sure to run as administrator
Navigate to c:\windows\syswow64\ (or folder where gacUtil.exe is located)
Run the following command (substitute path below to where your debug output version of the DLL is located.

gacutil /i "C:\Users\John\Documents\Visual Studio 2008\Projects\Project1\Project1\bin\Debug\MyAppDLL.dll"

You should get "Assembly successfully added to the cache"

Now run your project and you should be able to step into the DLL code.

Harrietharriett answered 2/3, 2012 at 16:1 Comment(0)

WAG here, but I'd say you've referenced another project in your solution by BROWSING to a dll (project/bin/debug/mydll.dll) rather than by adding a "Project Reference." If you have multiple projects in your solution, remove ALL references to each project. Then, in the Add Reference dialog, hit the "add project reference" tab and select the project you wish to reference.

Project references are always updated on a new build. But if you, say, browse to bin/release and add a reference to a dll in that directory, when you switch to debug mode and add code and try to debug it, the old release version of the dll is loaded into the appdomain and VS won't be able to hit any breakpoints (you'll notice the breakpoints are empty circles and the tooltip will say something about the code not being loaded).

Monahan answered 10/1, 2011 at 16:45 Comment(0)

I have just found another reason for the problem, and a fix. I am creating a Windows Forms application using C++ in Visual Studio 2010. I am using the FreeType library and some code which depends on it and for various reasons this code has to be compiled with 'No Common Language Runtime Support' selected (Properties -> Configuration Properties -> General). I was not able to get breakpoints to be hit in this non-CLR code.

The fix is that the main app must be compiled with 'Common Language Runtime Support (/clr)', NOT 'Pure MSIL Common Language Runtime Support) (/clr:pure)'. That immediately solved the problem. I can now debug into, and hit breakpoints in, the non-CLR code, including the FreeType C code.

Vetchling answered 15/8, 2012 at 11:37 Comment(0)

I have experienced the same recently. Not sure what I did exactly though. Try to physically clean up your solution, i.e. delete all bin directories from all projects of the solution. That usually helps to solve a lot of problems.

Rosenkranz answered 10/1, 2011 at 16:52 Comment(0)

Try disabling "Require source file to be exactly matched" option in tools->options->debugging->general.

Sherrellsherrer answered 29/12, 2015 at 19:37 Comment(0)

-1

My solution was to create a new project and load all my .vb files into the new project. Solved all of my issues.

Sophistic answered 26/2, 2013 at 18:20 Comment(0)

-1

My problem was simple. I have multiple projects in the solution and I just need to set the project I am working with as Set As Startup Project.

Belton answered 3/4, 2017 at 18:47 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags