Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

ASP Net Core 1.1 and EF 6 Exception in Unmanaged Code?

Ok, this is a really freaky problem that has just developed, and for the life of me I have no idea where to start.

For some reason, I'm getting a fatal error somewhere in EF 6, but this has only happened since I've converted to .NET Core 1.1. This application ran without issue on ASP.Net MVC 4.

Reason for my sleepless nights

For the search engines:

Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has encountered a fatal error. The address of the error was at 0x77c81a09, on thread 0x2520. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.' ```

From what I can find online, this is a problem outside the managed environment of .NET.... Which means that I'm just shy of clueless.

The first time I was hit with this error, a simple Clean and Build fixed it for a little while, then it cropped up again in the same place.

I've seen this error in two places so far:

var vm = new ManagerLogIndexViewModel()
{
    Locations = await _db.Locations.ToListAsync(),
};

And the (albeit more complicated):

var results = await _db.InvolvedPersons
    .Where(
        x =>
            x.LastName.ToUpper().Contains(q) || x.FirstName.ToUpper().Contains(q) ||
            (x.FirstName + " " + x.LastName).ToUpper().Contains(q))
    .Select(x => new {x.FirstName, x.LastName, x.Id})
    .GroupBy(x => x.LastName + " " + x.LastName)
    .Select(x => x.FirstOrDefault())
    .ToDictionaryAsync(x => x.FirstName + " " + x.LastName, x => x.Id.ToString());

Could it have something to do with async?

There are other Entity Framework calls where everything works fine, even with the async operator.

Even the first example worked after a Clean and Build.

I'm really at a loss for what to do. I've read that it might have something to do with the environment. At the moment, I have no alternative environments to test on, just my dev machine. I'll attempt to update later if I get this spun up on an alternate machine.


I just did another test before posting:

If I step through the code (first example), everything works as intended.

Stop. Remove breakpoint. Start. Crash.

This is driving me up a wall.


Update

As if this couldn't get much stranger, this error doesn't happen every time I launch.

I'd say its about 60/40 in favor of crashing. When it runs (and the first query goes through) I have no issues for the lifetime of the process.

Another Update

Looks like this is isolated to running under IIS Express. If I run the application in a standalone fashion, I have not been able to produce a crash.


Some more technical bits:

  • ASP.Net Core 1.1
  • .NET 4.5.2
  • Windows 7 SP1
  • EF 6.1.3

Closing Edit

For the sake of completeness in this thread (since there are a few threads at this point), the workaround provided by @gregg-miskelly (And submitted to SO by @SwampyFox) does indeed work. The bug has been submitted to MS, and should be fixed in a future .NET Framework release.

The discussion took place on the coreclr GitHub page

like image 336
Adam Schiavone Avatar asked Mar 13 '17 20:03

Adam Schiavone


People also ask

Can you use EF 6 in .NET Core?

You can't put an EF6 context in an ASP.NET Core project because . NET Core projects don't support all of the functionality that EF6 commands such as Enable-Migrations require.

How does Web API handle global exception in .NET Core?

The middleware UseExceptionHandler can be used to handle exceptions globally. You can get all the details of the exception object (Stack Trace, Inner exception, message etc..) and display them on-screen. You can implement like this.


2 Answers

According to the OP post on github, EF 6.1.3 Crashing IIS Express with FatalExecutionEngineError in ASP.Net Core MVC #10717, this is a crash in the Framework.

The crash is triggered by turned on ETW GC memory tracing.

To workaround it, you can try turning off ETW GC memory tracing in Visual Studio.

  1. Open Tools->Options
  2. Type in 'Diagnostic Tools' in the search bar
  3. Uncheck 'Enable Diagnostics Tools while debugging' under the Debugging General section.
like image 200
SwampyFox Avatar answered Sep 20 '22 04:09

SwampyFox


I'm experiencing the same issue with net462 and ASP.NET 1.1 with an EF 6.1.3 project

  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Folder Include="wwwroot\" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.1" />
    <PackageReference Include="EntityFramework" Version="6.1.3" />
  </ItemGroup>

I receive the following exception much (but not all) of the time when I run in IIS Express:

Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has encountered a fatal error. The address of the error was at 0x709a1a09, on thread 0x5020. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.'

It happens if I call async or synchronous or even if I call my DbContext from Main:

    public static void Main(string[] args)
    {
        using (var db = new MyDbContext())
        {
            var WorkOrders = db.WorkOrders.ToList();
        }

            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();

        host.Run();
    }

This never happens if I run my app directly (outside of IIS Express).

So apparently this is still an issue.

like image 36
Curdie Avatar answered Sep 17 '22 04:09

Curdie