runtime: Intermittent System.ExecutionEngineException with EF Core DBContext
After updating the nuget packages in my solution, I started experiencing this error when starting a debug session. It happens almost every other time I start debugging. The stack trace is empty, there is no inner exception, and the only thing I can do is stop execution and then restart the debugging session.
Exception message:
System.ExecutionEngineException HResult=0x80131506 Message=Exception of type ‘System.ExecutionEngineException’ was thrown.
Stack trace: Empty Steps to reproduce
protected WinsDbContextBase(DbContextOptions options, ICurrentUserContext userContext) : base(options) <== The error occurs here { … }```
Further technical details
EF Core version: (found in project.csproj or packages.config) 2.2.1 Database Provider: (e.g. Microsoft.EntityFrameworkCore.SqlServer) SqlServer Operating system: Windows 10 IDE: (e.g. Visual Studio 2017 15.4) VS 2017 15.9.5
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 22 (10 by maintainers)
@camainc thanks for providing these dumps. With some further investigating by my teammate we’ve likely connected your issue to a bug in the runtime that was discovered last year. We have implemented a fix that is included in the forthcoming .Net 4.8 release and we’ve got some options for you to try that will hopefully workaround the issue using the build of .NET you already have.
The primary goal of all these workarounds is to avoid using an NGEN image for netstandard.dll and instead to use the IL image. The options are different ways of achieving that and you can pick whichever one is easiest to use/affects the right scope of processes:
If there is an existing file with a <configuration>, <runtime> or <disableNativeImageLoad> block, then the elements described above need to be “spliced in” to the existing blocks (i.e., I believe the CLR config file parser might have trouble if multiple blocks of the same name are listed).
Before editing it is a good precaution to save a copy of the existing file in case you need to roll back the change for any reason, then make the same edit as used for the app.exe.config case above.
I hope one of these options can you get debugging successfully and sorry for the trouble this has caused.
-Noah
Closing this issue as it seems resolved.
What would be most helpful to debug this is to capture a dump of the debuggee prior to continuing from that exception/killing the debuggee. If you are using Visual Studio you should be able to capture the dump via the Debug menu > Save Dump As. Once you have that dump just share it with us and we can investigate what may be going wrong.