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 concludes. If I Set breakpoints on every line inside the method being tested I will end up at a random one, not the next one on the following line. I have cleaned and rebuilt the solution after a clean system restart. The behavior persists. Has anyone else experienced this and come to a conclusion.

This test only used the main execution thread (no additional threads are being created)

Answer 1

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 2

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 3

Even in a Debug build, compiler optimizations could explain this behaviour. Under project properties, "Build", verify that the checkbox 'optimize code' is turned off. I have seen this turned on by default after upgrading certain projects from .Net 1.1.

Answer 4

F10 is Step Over, F5 is continue to next breakpoint, F11 is Step Into, which executes the next line of code then waits. That is what you are probably looking for.

Answer 5

This behaviour also happens when you have multiple threads running.

Answer 6

There was a post VS2008 SP1 hotfix released that solves a number of debugging problems. The KB article is here, the hotfix download is here.

Answer 7

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 8

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 9

Go into Project->Properties and uncheck "Optimize Code"

This is the case if you see code such as DataSet ds = new DataSet(); gets hit on the debugger but code like string Test = "Test"; gets skipped.