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

[Webreaper]

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 (Webreaper/Damselfly@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

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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 (Webreaper/Damselfly@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

Author:	Webreaper
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[AaronRobinsonMSFT]

@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

[agocke]

Unfortunately COREHOST_TRACE doesn't tend to work well with EFAIL (that's what 0x80004005 is). That means something has gone wrong during runtime startup. @vitek-karas might have some ideas, and + @VSadov for potential single-file issues.

[Webreaper]

Okay, thanks. Any other logging I can turn on?

Just on the off-chance it yields any clues, here's the COREHOST_TRACE output for the process (had to rename to .txt, but if you rename to .html it'll render as a table of log entries, newest-first).

damselfly_log.txt

I'll continue fiddling with some build settings to see if I can find an explicit link to something.

[am11]

@Webreaper, does it still fail if you switch to daily build plan?

-         dotnet-version: '7.0.100-preview.5.22307.18'
+         dotnet-version: '7.0.100-preview.6.22314.18'

[Webreaper]

Hey @am11, I just tried that, but it's failing to pull packages from Nuget in my Github build, e.g.:

/home/runner/work/Damselfly/Damselfly/Damselfly.Migrations.Sqlite/Damselfly.Migrations.Sqlite.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.linux-x64 with version (= 7.0.0-preview.6.22312.1) [/home/runner/work/Damselfly/Damselfly/Damselfly.Web/Damselfly.Web.csproj]
/home/runner/work/Damselfly/Damselfly/Damselfly.Migrations.Sqlite/Damselfly.Migrations.Sqlite.csproj : error NU1[10](https://github.com/Webreaper/Damselfly/runs/6895291025?check_suite_focus=true#step:5:11)2:   - Found 89 version(s) in nuget.org [ Nearest version: 7.0.0-preview.5.22301.12 ] [/home/runner/work/Damselfly/Damselfly/Damselfly.Web/Damselfly.Web.csproj]

Is there anything else I need to switch to allow me to pull that newer version (I've not used the dailies before)?

[am11]

Webreaper/Damselfly@3d3e7dd#r76136400

[Webreaper]

Thanks, just saw that!

[Webreaper]

Okay, thanks to @am11 's help, I got a build working using the daily build, but I still see the same CoreCLR failure.