That sounds like a bug in the expression evaluator. For a better workaround, instead of checking “Use Managed Compatibility Mode”, check “Use the legacy C# and VB expression evaluators”. This should enable you to continue using Edit and Continue as well as other features added within the last few releases.

In terms of the “Internal error in expression evaluator”, can you please open an issue by going to Help -> Send Feedback -> Report a problem? That will help us fix the problem in future releases.

Just extending on the solution provided by Patrick Nelson. For Visual Studio 2015+ as inquired, the steps are as follows.

If you’re debugging at the moment, this option will be unavailable. Stop the debugger.

Go to Tools -> Options

and here under the Options select Debug -> General and scroll down to find the …legacy C# expression.. option:

More information is provided here:

Switching to Managed Compatibility Mode

Note: There are also some serious drawbacks that occur from switching to the legacy mode. Especially Runtime Reflection of the implemented Interfaces becomes almost an impossibility or extremely inconvenient. There are also other Reflection methods which will throw errors.

I finally figured out what created this problem in my Visual Studio!

The quick fix is to delete the debug object favorites from the “Documents/Visual Studio xx/Visualizers” folder and restart Visual Studio.

When you “pin” a variable in the debugger, Visual Studio saves a ‘favorite’ json object for it.

It appears that there is a bug in Visual Studio which corrupts the ‘favorite’ for some child variables that are dynamic in nature (not exactly sure of the conditions though).

For me checking “Use Managed Compatibility Mode” option worked. I was also seeing question marks when hovering over variables, instead of properties and values

I resolved this issue by simply resetting my visual studio settings by going to: to Tools->Import and Export Settings and selecting to reset to default settings

I had the same issue with VS2019. I ended up deleting my Documents/Visual Studio 2019 folder. Hope this might help someone, one day. Cost me a day.

PS. Probably not required to delete all, and of course not your projects (if they’re in there), but in my case, everything in there was autogenerated by VS.

I of course tried all solutions mentioned here, and even reinstalling VS didn’t work. Refactoring the class to another name was the ‘trigger’ which made me think there must be some cache, despite cleaning symbols and such didnt work.

In my case I was trying to evaluate lambda expression on List<> and had such error (“Internal error in the expression evaluator”). I was using VS2015, so lambda expressions were allowed. It turns out expression evaluator was lacking of Linq library. I added

using System.Linq;

to my current class and voilà! Lambda evaluated.

I encountered the “internal error in the expression evaluator” error when I was debugging in release mode instead of in debug mode. I had changed it to Release when publishing to production and forgot to change it back to Debug.

Check your use of the [DebuggerBrowsable] attribute; I found a minimal case in VisualStudio 2017 15.5 and posted it here.

In this particular case, the expression evaluator (EE) crash appears related to the [DebuggerBrowsable] attribute applied to a property overriding a field of the same name. This will account for some percentage of the cases that people are experiencing out there, but there’s no way of knowing how many are due to this specific issue until it gets fixed.

The full and complete demonstration example is shown in the image (and included below for good measure)

Machine-readable copy of the code in the image:

using System;
using System.Diagnostics;

class Program { static void Main() => new _derived(); }

abstract class _base
{
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    public Object trace;
};

class _derived : _base
{
    public _derived() => Debugger.Break();      // <-- vs2017 EE crash when stopped here

    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    new public Object trace => base.trace;
}

In my case, I had 2 same dll files in 2 different folders (seems, one dll was not correct). Deleting the .dll and rebuilding solution solved my issue.

In my case the data I was attempting to inspect was extremely large, a string which unexpectantly had hundreds of megabytes of data in it. The issue wasn’t apparent when the amount of data being inspected was reasonable.