Visual Studio Debugger skips over breakpoints

Question

My Visual Studio 2008 IDE is behaving in a very bizarre fashion while debugging a unit test: I have a breakpoint and when I hit it and then try to step with F10 the test con

Answer 1

Are you putting your breakpoints inside code that is part of a generated class?

I have experienced this problem on the client site of a service reference. The generated classes are partial classes with the

    [System.Diagnostics.DebuggerStepThroughAttribute()]

attribute applied. Even when my breakpoint was in a different file, but still part of the attributed class, the breakpoint would be skipped.

I removed that attribute from the generated Reference.cs file and the debugger worked as I expected.

Of course, this isn't a permanent solution because if the Reference.cs file gets regenerated, the attribute comes back.

Answer 2

This may be as simple as a case of the testing framework not loading the same assembly that you're currently working on. I've had this happen in rare cases in NUnit, which works off a copy of your assembly under test; occasionally, it stopped copying over the most recent version. Are your breakpoints decorated with a "symbols have not been loaded" indicator?

Answer 3

May be it is too late to reply, I got same issue in VS2012 to fix that please check if menu Test>TestSettings> "LocalTestRun.TestRunConfig" is checked, if it is checked uncheck it and it will stop skipping the code lines. May be same for Vs2008 also work.

Answer 4

I had similar issues on VS 2003. It turned out that I was using wrong symbols so they could not be bind to correct source.

Make sure in a following:

1. That you're using the Debug build (or that any kind of Optimization is turned off)
2. That build output path is OK ( that "Project Properties\Linker\Output File" match to the exe you're debugging)
3. That you don't place breakpoints on variable declarations: i.e. if you place a break point on "int some_variable;", you will never hit it but instead you'll hit the first place after it where you defining\initialize something or calling some methods
4. You can't step-into with F10 (executes next statement) but with F11 (executes next statement and follows execution into method calls)
5. Make sure you don't have any filters on breakpoints (i.e. Hit count or condition)

p.s. try placing the DebugBreak(); function in both methods (unless this code is executed inside some loop so this might be frustrating). This should cause terminating your process when execution reach any of these functions (so you can continue with debugging from that particular place).

Answer 5

This behaviour happens if you debug the release build (since lines are optimized away).

It also happened to me in the past if by accident I'm debugging an older exe somewhere else (as set by the project config), instead of the most recently build one ;^)

Answer 6

I ran into this in Visual Studio Community 2013. The behavior appears to be by design. When running tests, execution will not stop on breakpoints. When you want execution to stop on breakpoints, selects TEST --> Debug rather than TEST --> Run.