29

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?

Improve this question
4
  • release of debug configuration? in release configuration some of your code can be removed by optimizer so debugging can look weird
    – Andriy Tylychko
    Commented Jan 10, 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?
    – Jesse McCulloch
    Commented Jan 10, 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
    – Flagbug
    Commented Jan 10, 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.
    – Hans Passant
    Commented Jan 10, 2011 at 17:03

12 Answers 12

Reset to default
39

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.
Improve this answer
3
  • 2
    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.
    – Peter Mortensen
    Commented Dec 14, 2011 at 15:22
  • I have now documented it in How do I disable 'Just My Code' in Visual Basic 2005 Express?.
    – Peter Mortensen
    Commented Oct 8, 2012 at 23:34
  • 1
    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)
    – Alex Marshall
    Commented Apr 28, 2014 at 21:55
4

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.

Improve this answer
4

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.

Improve this answer
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.

Improve this answer
1
  • 1
    where is build configuration, i'm on vs 1013
    – The Beast
    Commented Feb 24, 2016 at 9:01
2

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.

Improve this answer
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.
    – Flagbug
    Commented Jan 10, 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.
    – Omer Raviv
    Commented Jan 10, 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.
    – Galadrius Krunthar
    Commented Mar 28, 2013 at 0:03
2

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.

Improve this answer
1

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

Improve this answer
1

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.

Improve this answer
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.

Improve this answer
0

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

Improve this answer
-1

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

Improve this 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.

Improve this answer
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.