Visual Studio调试器跳过断点

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

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 .

---

UPDATE: the hotfix download location was retired, I don't know of an alternative download location. Please edit this post if you find one.

Answer 2

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 3

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: ie 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 (ie Hit count or condition)

ps 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 4

当您运行多个线程时，也会发生此行为。

Answer 5

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 6

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 7

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

Answer 10

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.

Answer 11

My unit tests were testing under x86. Changing them to x64 worked.

Menu

Test -> Test Settings -> Default Processor Architecture -> x64 .

Answer 12

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 13

I just encountered the same issues and went through all the suggestions above with no luck. Come to find out at some point in the past someone had changed the method signature to be "private" when it must be "static" or "public". As soon as I changed the test method's signature back to "public", the break points started working again.