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

Question

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?

Answer 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.

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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:

1. Make sure the project is in debug mode (all projects)
2. From Windows go to a Command prompt and be sure to run as administrator
3. Navigate to c:\windows\syswow64\ (or folder where gacUtil.exe is located)
4. 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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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).