15

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)

My Other Me
  • 5,007
  • 6
  • 41
  • 48
  • 2
    Do you experience this only when debugging from the unit test? Did you also try running the same code from a console application? Which test framework are you using? – jeroenh Jan 25 '10 at 11:42
  • Debug build? Optimization off? Right symbol files? Could another thread be executing inside the same function? Stack corruption? Is there modal UI up (especially an assertion failure) that might be pumping messages in another thread? – Adrian McCarthy Jan 26 '10 at 23:57
  • @jeroenh: I have had some weirdnesses in the project under non-unit-testing conditions. It is service code, and the debug build is a console application. I am using the Visual Studio built-in unit testing-framework. – My Other Me Jan 27 '10 at 07:58
  • @Adrian: Debug build is confirmed. Optimizations off is confirmed. How can I confirm Symbol files? Within the unit testing framework there is only one thread within the function. How can I check for Stack Corruption? There is no UI, it is only a console application at present for debugging. – My Other Me Jan 27 '10 at 08:00
  • Did you check if the test results folder is cleared too. To run a service as a console app, you could do two things: 1) Change the project type to console and 2) in the main method check if Environment.IsInteractive (or something like that) and call ServiceBase.Run accordingly... – Charles Prakash Dasari Jan 31 '10 at 21:50
  • Related posts - [Skip current line in debugger](https://stackoverflow.com/q/31474563/465053) & [How to force debugger to skip a piece of code?](https://stackoverflow.com/q/15023996/465053) – RBT Feb 13 '21 at 14:12

13 Answers13

27

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
10

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 ;^)

Toad
  • 15,593
  • 16
  • 82
  • 128
  • Build is Debug Build. I have switched between release and debug and cleaned & rebuilt in between. All bin folders have been cleared. How would I check which exe will be run. – My Other Me Jan 08 '10 at 09:24
  • project->project properties->debug tab... But If you have never changed/used this it will definitely not be changed to another exe. – Toad Jan 08 '10 at 09:33
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).

sinek
  • 2,458
  • 3
  • 33
  • 55
  • #3 was the one that solved my problem. Also, does not hit curly braces - it's the little things... – Jon Peterson Mar 01 '13 at 17:08
  • Just to correct my previous comment - it doesn't break when you try to break on an open curly brace for an empty test. – Jon Peterson Mar 01 '13 at 17:26
  • Regarding #3: if your project's Advanced Compiler Settings -> "Generate Debug Info" is set to pdb-only, the breakpoint will be moved off of the variable declaration and put at relevant spot in your code after that point for you when debugging. If it is set to "Full" or "None" then the breakpoint will not be moved and so you will never hit it. – Frinavale Apr 25 '13 at 14:06
  • Debugger.Break() got Visual Studio 2013 to step into my test method. However, as soon as I hit the ShimsContext.Create() statement, VS started looking for ObjectCloneHelper.cs - I have no idea what that file is or where it's supposed to come from... – Zarepheth Jun 08 '15 at 21:40
3

This behaviour also happens when you have multiple threads running.

Michael Baldry
  • 792
  • 5
  • 19
2

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.

jeroenh
  • 26,362
  • 10
  • 73
  • 104
  • The solution is a bunch of 3.5 projects. I have gone over all of them and confirmed that optimizations are off. Some of the projects include a few 1.1 assemblies for legacy support. Would the build type of the legacy components impact my solution? – My Other Me Jan 27 '10 at 07:54
2

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.

Mike Schenk
  • 1,512
  • 9
  • 21
0

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.

Rohit.Net
  • 23
  • 5
0

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?

Jacob
  • 77,566
  • 24
  • 149
  • 228
0

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.

Patrick
  • 1
0

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.

Ben Osborne
  • 1,412
  • 13
  • 20
0

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

Menu

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

ΩmegaMan
  • 29,542
  • 12
  • 100
  • 122
-1

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.

Arlen Beiler
  • 15,336
  • 34
  • 92
  • 135
-1

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.

Jeff
  • 77
  • 7