Debugger highlights wrong line, steps over code without executing it RRS feed

  • General discussion

  • I stumbled across some rather odd behaviour in the debugger this morning, and it took me a while to realize just exactly what was happening.  I've tried to distill the problem down to a compact test case:

    int somefunction(int x, int y)
      if (x == y)
          x++; // or whatever, doesn't matter
        catch (SomeCustomExceptionClass &)
          return x;

      return x;

    // calling code:

    If I put a breakpoint on the line "if (x == y)", I can verify that x does NOT equal y, so I would expect the contents of the if block to be skipped entirely.  However, hitting F10 to step will cause the debugger to highlight the "return x" line inside the catch block inside the if block, which makes no sense at all - it appears as though we have not only entered the if block (which shouldn't have happened because the condition was palpably false), but also skipped over the contents of the try block and jumped directly into the catch block.  However, it gets even stranger - hitting F10 again at that point will highlight the "x--" line after the if block, and from that point on everything is back to normal.  The "return x" line, despite having been highlighted by the debugger, is never executed.

    Unfortunately, my test case exhibits slightly different behaviour from the description above (which was observed in a much larger section of code within our application).  In my test case, the debugger will properly skip the if block and correctly highlight the "x--" line as it should, but hitting F10 to step over that line will cause the debugger to highlight the same line again.  Hitting F10 once more will cause execution to continue as normal, and the "x--" line, despite having been highlighted twice, is only actually executed once.

    I don't really have a question here, I'm just posting this observation in case anyone else runs into something similar (and also so I can vent a little - I lost an hour this morning to this problem, believing that my code was perhaps corrupting something in memory and executing the wrong stuff). 

    Friday, October 13, 2006 7:45 PM

All replies

  • Scorbett,

    Are you debugging optimized (i.e. retail) code? This behavior is normal if you are (as a result of optmization, the compiler can remove lines, reorder lines etc...) Debugging from the dissassembly window can give you a much better picture while debugging optimized code.

    Hope that helps

    Jackson Davis (msft)

    This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, October 23, 2006 6:10 PM
  • Thanks Jackson,


    I was having this same issue and real problems finding a solution but this was indeed the case, as one of my libraries was being optimized and creating a real headache for debugging. 





    Wednesday, July 18, 2007 10:38 AM
  • Also having similar problems. Seemed to start when we turned on the /clr switch as we are starting to look at making use of managed extensions and port to using windows forms. We are using Visual Studio 2005, C++ code and MFC. We also see problems evaluating symbols in watch windows, expecially static variables and enum values. This all seemed to work nicely before turning /clr on - in fact better than it ever has (have been using visual studio since version 4 Smile ). We also see the 'jumping to all the return points' problem, as if we were debugging release mode code. We are definitely debugging debug mode code and it works fine if the only change to the compiler settings is the /clr switch being turned off.

    As a workaround - since we are mostly not using managed code - we can compile the native code with /clr off for the minute in debug builds, but I guess the idea is to compile as much code as possible to managed to reduce the amount of translation from one to the other. Since the Boost libraries seem to force things to compile native currently anyway, we might as well - but that's another rant for another day!

    Friday, July 20, 2007 10:33 AM

  • Hi,
    I have just encountered a similar issue on Win XP SP2, MSVS 2005 Version 8.0.50727.762 (SP.050727-7600). As this is happening in Debug build, and I seem to use no external libraries, and I have checked that optimizations are disabled (/Od), I have difficulties discerning where optimization mentioned in earlier posts might be happening.

    The code that should reproduce the situation is below - when debugging in source code, the debugger skips the body of the first if-statment, but enters the body of the second if-statement, and then moves onto "b = true;". Debugging in disassembly seems to confirm that entering the body of the second if-statement actually does not happen.

    #include <msclr/lock.h>

    int main()
       int^ a = gcnew int(5);
       bool b = false;
       char* c = new char;
       c[0] = 'c';
       delete c; c = NULL;
       if (b)
           return 0;
       msclr::lock guard(a);
       if (b)
           return 0;
       b = true;
       return 1;

    Debugger type is set to "Mixed".
    All compile command line options are:
    /Od /D "WIN32" /D "_DEBUG" /D "_UNICODE" /D "UNICODE" /FD /EHa /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /nologo /c /Zi /clr /TP /errorReport:prompt /FU "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU "c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.XML.dll"

    Tuesday, February 16, 2010 10:50 AM
  • I've noticed similar behaviour if someone accidentally marks the debug build of the project for optimisation. I've posted an article about the issue and how to resolve it here:

    Hope this helps!

    Joel's SharePoint Architect Blog

    Thursday, October 14, 2010 7:41 PM
  • Had the same problem with the exact same configuration.

    The issue was due to incoherent end of lines. Converting the files with debug problems into a coherent format solved it.

    Get EditPad and convert the file into Windows format.

    Tuesday, July 12, 2011 8:47 AM
  • Hi !

    I had exactly the same problem until I've figured out root cause of this - and it was the same - inconsistent line endings. Most interesting idea is that i have copied code sample from internet, and visual studio pasted inconsistent line ends to source code. So I see this as a visual studio editor bug (All visual studio's are applicable to this bug - vs2010, vs2013, vs2015).

    It was bit annoying - it looked like everything works correctly, but breakpoints worked out in wrong place and code was executed somehow mysteriously. (Appeared in watch window even thus execution has not reached particular line yet).

    Hopefully this will get fixed in next versions of Visual studio.

    Friday, February 24, 2017 9:34 AM
  • (First of all, this is hands down the worst I've ever experienced of Microsoft products/development!)

    I think I disabled Tools > Options > Environment > Documents > Check for consistent line endings on load at one point. The bad line-endings seemed to be isolated to a section I was suspect of from a (WASTED/MISERABLE) afternoon of trial-and-error. But I cannot think of a reason for that section having different endings.

    THE WORST PART OF THIS is I have 0 confidence Microsoft will ever fix this nightmare experience. I know Microsoft's general lack of concern for customers or personal responsibility all to well. I want to "Report as abuse" this post :)

    Dunno why Microsoft stuck the underscore in my screen name. It won't wash out. I apologize, but I only post here in times of severe desperation :( Anyone else find the line/paragraph spacing in these forums very difficult to read?

    Friday, July 13, 2018 6:23 PM
  • Had the same problem with the exact same configuration.

    The issue was due to incoherent end of lines. Converting the files with debug problems into a coherent format solved it.

    Get EditPad and convert the file into Windows format.

    This bug still exists 8 years later!
    Friday, August 9, 2019 11:00 PM