Last week I ran into a really strange problem with an older WebForms application on Visual Studio 2013.  I was trying to debug my application on a breakpoint and when I hit the break point, none of the debugger member and watch expressions were working - specifically everything shows 'Could not evaluate expression' in the debugger. 

It appears that the issues discussed in this post have been addressed in Visual Studio 2013 Update 2, so updating to Update 2 (or later) might be the best path for avoiding the funky debugging behaviors described in this post. If you still have issues or simply can’t update to Update 2 yet, then the rest of this post is still relevant.

Here's what the error looks like for me:

In this example, you can see a couple of scoped values in the debugger. Here both this and user are in scope and instantiated, but the debugger doesn't show the evaluated values/references for those objects to drill into. Instead I get the error icon and 'Could not evaluate expression'. In more complex code with more scoped variables, I basically see a wall of red icons - nothing at all is evaluated.

The Visual Studio 2013 Debugger introduces a new feature which allows evaluating the result value of functions. With this new feature the existing behavior of Property evaluation (which are essentially functions) has also changed and this new behavior is now the default. Unfortunately it looks like in this particular case it ended up causing a problem.

To be fair, I've been working on various different projects (there are about 15 projects that I use on a regular basis plus many test and 3rd party projects) and this one is the only one where I've run into this behavior, so this is most likely a very rare edge case (and I feel oh so lucky about that!).

As I've been in Redmond on the Microsoft Campus for the MVP Summit this week I pinged some of the VS debugger folks and they were kind enough to let me show them the issue in person today and together we poked around to try and figure out what's causing this problem.

Debug Breakpoint Corruption

First let me say that we managed to make the problem go away, although since we weren't able to repro the failure outside of my specific environment it's hard to say exactly what the problem is. But here is what it looks what ended up solving it.

The original project was a VS2012 project that was recently moved and opened in VS 2013 RTM. In the process of moving the project to VS 2013 it looks that the underlying Solution support file (the .suo) file got corrupted somehow. The solution file ended up containing a number of oddly duplicated breakpoints that looked something like this:

Notice the duplicated global.asax.cs debugger breakpoint entries that are nested below the main reference. There are a few more of these weird breakpoints in the project.

Also odd was that some of these breakpoints were dated and didn't actually show up in the IDE, and none of these breakpoints actually show up in the source code editor. For this reason I didn't originally notice these funky breakpoints, although I wondered about the phantom stops in Session_Start() when starting the project, but when we took a look at the failures we happened to notice the duplicated breakpoints.

This prompted me to delete the breakpoints and lo and behold, the problem went away. Yay. Problem solved.

Most likely however, the breakpoint issue is just a symptom that's causing a load failure on one or more of the .NET assemblies referenced by the Web project during startup. The phantom breakpoint in web.config most likely resulted in interrupted assembly loading, which in the course of debugging through the project startup appears to have been triggered in the debugger's assembly loader. It appears there might be a bug there, in that there's no proper recovery from an assembly load error that's going to be addressed in the future (looks like Microsoft is aware of this issue and has a patch in the works for it).

This likely accounts for the fact that we weren't able to duplicate the problem outside of my machine, even when copying off the project with the corrupted .suo file. It's likely a timing issue.

Other Fixes

The debugger folks were mentioning that this 'expression evaluation' problem has come up on a few occasions for developers, so there are other issues besides my odd corrupted breakpoints scenario. The thought is that any error during assembly loading can cause failure of the debugger to evaluate expressions later on in the debugging process.

Luckily there's a workaround should you run into this by using a flag in Tools | Options | Debugger | General , which allows you to disable the new function evaluation behavior and which essentially gives you the VS 2012 behavior:

This also worked in eliminating the problem (I backed up the bad project to test for the failure), and if all fails this is an option that will get you going again. But you will get slightly different debugger behavior since when enabled you're actually getting a different debugger runtime. Still better than a non-working debugger :-)

The debugger folks mentioned they have a few bug fixes that will make it into the next Visual Studio update that are likely to solve these problems, so this is bound to be a temporary problem and a very edge case scenario at that. But when it does kick in, at least there is a workaround by reverting to the old behavior and make it work…