8

I'm using VS 2010 Professional (On Windows 7 Professional 64), writing with WCF 4.0. I have the following code:

        if (responseMessage.StatusCode == HttpStatusCode.NotFound)
        {                
            throw new ContentNotFoundException(contentId, SSPErrorCode.PartnerRestGetStream404);
        }

When attaching the debugger to the process, having set a breakpoint at the "if" statement or before that, while the condition is false (responseMessage.StatusCode is 'OK'), the debugger steps into the "if" statement. It then steps over the "throw" statement without doing anything, then continuing on with the code.

I've tried:

Restarting VS, logging out my Windows user, rebooting, cleaning the solution, building it again, rebuilding it, recycling the application pool, resarting IIS, adding more code inside the "if" statement and inside the condition - nothing worked so far.

There must be a cache somewhere which I can clean to get rid of it, but what, and where?

Googling this I only found http:--social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/d4b70fd7-b74a-42ce-a538-7185df3d3254/, so I tried manually setting the breakpoint, and it didn't break in this class, although the same did break in other classes.

I would love to fix this without reinstalling VS. Thank you in advance!


Update:

  1. Since I put this up and could not find an answer, I moved on with my project.
  2. I stumbled upon this issue, reported by John MacIntyre on this post, which ends up with a simplified example:
using System; 

namespace IEnumerableBug2 
{ 
    class Program 
    {
        static void Main(string[] args) 
        {
            if (new object() == null)
                throw new Exception();
            try { }  catch { }
        }
    }
}

Update #2:

Note that my Method also has a try-catch statement in it, a few lines after the 'if' statement.

I've just tried reproducing this bug again, and failed. I'm going to leave the question on stackoverflow for others who might need it, but, as I wrote, I am no longer able to reproduce the behaviour.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
H.Wolper
  • 699
  • 1
  • 13
  • 26
  • Looks like a genuine bug in the IDE. Report it to MS. – Martin Dec 28 '10 at 10:16
  • This appears to be fixed in Visual Studio 11 when targeting .NET 4.5; however, the bug persists when targeting .NET 4.0. – Nick VanderPyle Apr 05 '12 at 13:29
  • 1
    And now, many years later, I ran into this issue yesterday. The thing I noticed is how it only seems to occur when the code in the if-statement only throws an exception. It does so in my case as well. I commented it out, and replaced with some random statements involving a string and a bool, and it skips over that just fine. At the same time, while it doesn't seem to skip over the exception throwing line, it doesn't actually execute it: no exception is thrown, despite Visual Studio entering the if-block. Strange, seems like a bug, but not severe as long as the throw doesn't actually happen. – Rob Oct 02 '12 at 09:05
  • @Rob - Yes, that is exactly the same behavior. Confusing, but not exactly effecting the debug logic. – H.Wolper Oct 03 '12 at 09:16
  • Answer via related question: http://stackoverflow.com/a/27552372/19308 – Joshua Drake Apr 17 '15 at 15:31
  • isn't this related to this question? https://stackoverflow.com/questions/16305637/why-is-my-program-going-into-both-an-if-statement-and-its-corresponding-else-sta – Wakan Tanka Aug 11 '17 at 08:21
  • @WakanTanka, looking at the link's answers, I think it is not the same issue. – H.Wolper Aug 13 '17 at 06:46

3 Answers3

3

I am experiencing this problem too, but slightly different. Here's my code:

        string lockCode = Guid.NewGuid().ToString();
        bool alreadyLocked = string.IsNullOrWhiteSpace(lockCode);

        if (alreadyLocked) {
            throw new Exception("already running");
        }

        try {
            PerformTask(task);
        }
        finally {
            UnlockTask(task, lockCode);
        }

As you can see, the lockCode string is always assigned with a Guid value. The debugger steps into the 'if' scope, although it shouldn't. The exception isn't thrown.

I am running Visual Studio 2010 SP1 on Windows 7 64-bit with ReSharper 6.0.

Microsoft Visual Studio 2010
Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework
Version 4.0.30319 SP1Rel
Installed Version: Premium

This happens to me with an ASP.NET application on framework 4.0. I tried running the repro code posted here on a different project on my machine but could not reproduce the issue.

Also, I have deleted the Shadow Copy Cache for the .NET Framework on this path:

C:\Users\username\AppData\Local\assembly

I deleted the VS2010 symbols cache directory, and the Temporary ASP.NET Files. I restarted my computer, cleaned the whole solution and rebuilt everything. No clue why this happens.

Workaround: If I remove the 'try-finally' part from the method, or extract the throw statement to a different method, the debugger steps over the 'if' scope correctly.

Sorry for not posting a real solution to this, I hope this helps either isolate the problem or work around it.

Dor Rotman
  • 1,511
  • 1
  • 15
  • 27
1

Today I also experienced this issue. The following code solves the problem, with the advantage of not compiling the workaround on release builds:

using System; 

namespace IEnumerableBug2 
{ 
    class Program 
    {
        static void Main(string[] args) 
        {
            if (new object() == null)
                throw new Exception();

            #if DEBUG
            bool workaround = true; // dummy instruction
            #endif

            try { }  catch { }
        }
    }
}
lbras
  • 70
  • 2
  • 8
0

While stranger things have in fact happened, I highly doubt that this is a bug in the debugger or bad bad VS installation.

I think something must be happening that you're not interperting correctly. Did you put the expression "responseMessage.StatusCode == HttpStatusCode.NotFound" into the Debug Watch window? What does it return? Is it possible StatusCode is returning a different value each time? Did you try evaluating it several times to make sure it is consistent?

The only way I could imagine this happening is if the code was changed, and when prompted whether or not you want to debug the source file even though its version does not match, you answered Yes. This would explain why you can skip over the "throw" line without it doing anything - you're not debugging the actual code you're seeing, but an older version of it. To fix this, rebuild everything, and never say yes when prompted if you want to debug even though there is a version mismatch - it is way too confusing!

Omer Raviv
  • 11,409
  • 5
  • 43
  • 82
  • Thanks for your response. Omer. I'm sorry to say that it's not it. I have checked the value of the return code, and have done so for several times, as well as make sure the condition itself returns 'false'. Yes, there's a big chance that the reason is some cache of code being debugged which isn't the last version of code, however, as I wrote in my question itself, I've cleaned the solution, rebuilt, and even reset the IIS and the machine itself. I also showed this strange behavior to a few of my colleagues, and my boss, and they tried themselves and checked, so it can't be that I dreamed it... – H.Wolper Dec 18 '10 at 19:28
  • If you set a new breakpoint on the If statement, or on the throw statement, does the breakpoint icon in the margin of the code editor appear wholly red, or is it just an un-filled red circle? If it isn't wholly red, right after you rebuild everything, open the Modules window and find the path it the app loaded your DLL from. Go to that path in explorer and verify the DLL was created "just now", and not some time ago. – Omer Raviv Dec 18 '10 at 22:21
  • Also, if you put a MessageBox.Show("1") just before the if, and a MessageBox.Show("2") inside the if, and a MessageBox.Show("3") just after the if, which of the three MessageBoxes show up? – Omer Raviv Dec 18 '10 at 22:28
  • 1
    Also, maybe this will help: http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx – Omer Raviv Jan 05 '11 at 09:39
  • 1
    The OP is correct that this is a known issue with Visual Studio, see: http://stackoverflow.com/a/27552372/19308. – Joshua Drake Apr 17 '15 at 15:30