runtime: .Net application aborts at startup with "Failed to create CoreCLR, HRESULT: 0x80004005" - .Net 7 preview 5

Description

I have a project here: https://github.com/Webreaper/Damselfly which I upgraded to .Net 7 preview 5 this evening, and also updated EF Core and a bunch of other dependencies (https://github.com/Webreaper/Damselfly/compare/master...develop).

The app compiles and runs fine on my M1 Macbook (I’m using VS for Mac 2022). However, when built and deployed to a docker container, and launched on Linux (I’m using a Synology NAS) it fails with:

Failed to create CoreCLR, HRESULT: 0x80004005

The same app launched fine built and ran (on both OSX and Linux) against .Net 7 preview 4.

I’ll do some additional tests tomorrow to see if I can narrow down to the specific update that cause this to break (i.e., is it .Net 7 preview 5 itself, or some other dep, or a combination of the two). The app is a Blazor Server app running as a self-contained single-file executable, but since it never gets as far as initialising the CLR I don’t think that Blazor or ASP.Net is relevant. I’ve also tried disabling trimming, but it didn’t resolve the issue.

I guess my first question is - how do I go about getting additional debugging information to figure out what’s causing this problem?

Reproduction Steps

Take my app, build and run it against .Net 7 preview 4. It works. Upgrade to preview 5, it fails to start.

Expected behavior

App runs successfully on both OSX and Linux.

Actual behavior

App runs successfully on OSX, but on Linux the app fails to start with Failed to create CoreCLR, HRESULT: 0x80004005

Regression?

Yes, this app worked with .Net 7 preview 4.

Known Workarounds

No response

Configuration

No response

Other information

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 39 (19 by maintainers)

Commits related to this issue

Fix for https://github.com/dotnet/runtime/issues/70758 — committed to Webreaper/Damselfly by Webreaper 2 years ago

Most upvoted comments

The runtime introspection approach is better than version check. CentOS 7 (aka pretty important distro) has kernel version 3.10.0-1160.el7.x86_64 and it doesn’t fail 9858 memfd_create("doublemapper", MFD_CLOEXEC) = 8.

COMPlus__

minor nit: the way runtime config lookup works is for a desired config XYZ, it first looks for DOTNET_XYZ then fallback to “legacy” COMPlus_XYZ. So here, you can simply use DOTNET_EnableWriteXorExecute to avoid an extra probe.

am11 on Jun 16, 2022

@Webreaper I’ll keep this open to track it until the fix is in. @am11 my plan is to base it on the failed memfd_create rather than a version check.

janvorli on Jun 16, 2022

@Webreaper can you please try to set env var COMPlus_EnableWriteXorExecute=0 before launching your app and see if it makes a difference? This is one of the things that we’ve changed in preview 6 (it was disabled by default, now it is enabled by default).

janvorli on Jun 15, 2022

@Webreaper You might start with setting the environment variable COREHOST_TRACE=1. Details on this can be found at https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#how-do-i-debug-the-probing-properties-construction and https://github.com/dotnet/runtime/blob/main/docs/design/features/host-tracing.md.

/cc @elinor-fung

AaronRobinsonMSFT on Jun 15, 2022