Reputation: 2103
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?
Upvotes: 29
Views: 38614
Reputation: 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.
Upvotes: -1
Reputation: 13396
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.
Upvotes: 4
Reputation: 1
Try disabling "Require source file to be exactly matched" option in tools->options->debugging->general.
Upvotes: 0
Reputation: 1
My solution was to create a new project and load all my .vb files into the new project. Solved all of my issues.
Upvotes: -1
Reputation: 1780
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.
Upvotes: 1
Reputation: 707
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.
Upvotes: 4
Reputation: 33
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:
c:\windows\syswow64\
(or folder where gacUtil.exe
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.
Upvotes: 2
Reputation: 755447
Here are a couple of reasons and workarounds for why Visual Studio will avoid stepping into a particular method.
DebuggerNonUserCode
which causes the debugger to step over the method. Upvotes: 39
Reputation: 2103
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.
Upvotes: 3
Reputation: 8946
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.
Upvotes: 0
Reputation: 11827
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.
Upvotes: 2
Reputation:
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).
Upvotes: 1