visual studio 2010 debugger - steps into an "if" statement despite condition false

Question

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.

Answer 1

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.

Answer 2

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 { }
        }
    }
}