CLR crash when code change during debugging ("Edit and Continue") is followed by Debug.SetNextStatement

Question

During Visual Studio 2015 debugging session (breakpoint hit), if I change almost any code and select any of Continue, Step Into, Step Over (, etc.), commands, I immediately get ExecutionEngineException followed by CLR crash.

This seems to be appearing only in one project.

System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason, int pvLoopData)    Unknown
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason, System.Windows.Forms.ApplicationContext context)    Unknown
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) Unknown
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.ApplicationContext context)  Unknown
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun() Unknown
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()    Unknown
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(string[] commandLine)   Unknown
[Native to Managed Transition]  
[Managed to Native Transition]  
mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) Unknown
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()   Unknown
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state)    Unknown
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) Unknown
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart()    Unknown

How to troubleshoot this issue?

miroxlav · Accepted Answer · 2015-09-28T17:35:26.657

I found the answer by minimalization of the problem scenario.

It looks that problem is with combination visual-studio-2015 + .net-3.5 + vb.net and this code:

Public Class Form1
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Dim gridSize As Size = New Size(3, 11)
        Dim z As Integer
        z = 22
        z = 1
    End Sub
End Class

Place breakpoint at End Sub, stop at it, swap the assignments and set next statement to the first assignment. Boom.

Reported to the Microsoft. Workaround is to use .net-4.0 and higher.

score 1 · Answer 2 · answered Mar 05 '16 at 19:35

1

I have the same problem with Visual Studio Community 2015 in C#. When debugging a project compiled for .Net 3.5, hitting a breakpoint and doing 'edit and continue', it rarely survives. The compiler/IDE crashes with one of several possible error messages, most often with ExecutionEngineException followed by CLR crash.

When the same project is compiled to .net 4.6.1, the VS 2015 IDE debugger operates correctly. It is enough to set the main project to .net 4.6.1; the .dlls called are then debuggable even when they are still .net 3.5.

(The old VS 2013 IDE debugger operated correctly with .net 3.5, only very rarely it crashed.)

This behaviour is true for many projects.

answered Mar 05 '16 at 19:35

user3653977

29
2

Your answer was downvoted by someone because it actually does not answer the question. **Please consider deletion** or change it. If you wish to add true answer, please *answer the question asked on top*. This is how the [so] works. In case of this partcular bug, you can also [vote at the bug report](https://connect.microsoft.com/VisualStudio/feedback/details/1844855/clr-crash-executionengineexception-thrown-on-debuggers-edit-and-continue-for-net-3-5) in Microsoft. – miroxlav Mar 05 '16 at 22:04
In my opinion, this answer is essentially the same as the answer given by the original poster which is to use a higher version of .net. I disagree with down voting an attempted answer. There will always be a "best" answer chosen but the fact that this wasn't chosen as the best answer is not a valid reason for down voting. Obviously this answer is at least as useful as the one that was chosen by the original poster, and nobody else had a better reply. – shawn1874 Oct 27 '16 at 17:38

CLR crash when code change during debugging ("Edit and Continue") is followed by Debug.SetNextStatement

2 Answers2