Error: Failed to create CoreCLR, HRESULT: 0x80004005

[superbonaci]

Description

I'm getting this error when launching a program compiled with dotnet. How can I debug what can be the cause?

Reproduction Steps

Run the program.

Expected behavior

Do not crash.

Actual behavior

Crashes.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[filipnavara]

It's "access violation" error. As a good start, you should at least state your platform (Windows? Linux?), .NET version, etc. It would be ideal if you could produce a small repro or at least capture a crash dump (instructions depend on the system).

[superbonaci]

It's macOs 15.1.1 with CPU Apple M1.
I can compile the dotnet app with debug info I think.
dotnet version is 9.0.100 and the app was compiled with that version too.

[janvorli]

@filipnavara this is actually not an access violation error, that would be 0xC0000005. This error code (0x80004005) means E_FAIL. @superbonaci, does it write only the message you have put to the title to the console or is there something more?

[filipnavara]

This error code (0x80004005) means E_FAIL.

D'oh. Of course. Thanks for correcting me :-)

[superbonaci]

@janvorli it's only that.

[janvorli]

@superbonaci how do you compile and run your app? Can you check if a hello world app that "dotnet new console" creates has the same problem? And have you compiled your app on the same Apple M1 device?

[superbonaci]

@janvorli that command does not fail, and if I run it before my app doesn't crash either. It looks like "dotnet new console" sets a proper environment for my app which doesn't happen if I run it alone.

[janvorli]

@superbonaci I am sorry I was not clear. I meant running the app created by the "dotnet new console" too. So in the same directory where you've ran the "dotnet new console", you'd do "dotnet run".

[superbonaci]

@janvorli yes the Hello, World! appears then my program runs. I've noticed that this issue only happens with I call it from a script, if I run it from the terminal directly doesn't happen.

[janvorli]

Ok, thank you for the details. Can you please share how you build and how you run your app? Invoking it from a script should make no difference.

[superbonaci]

dotnet publish MyApp -p:PublishProfile=MacOSArm64

[janvorli]

Thank you. I have several more questions:

• what is the definition of the MacOSArm64 profile that you are using?
• how exactly do you invoke your app from the script (I would like to know the full command line)?
• are you sure that the right .NET runtime host is on the PATH when you run it from the script?

[superbonaci]

The app was always published as self-contained:

$ dotnet publish MyApp -p:PublishProfile=MacOSArm64 -r osx-arm64 --self-contained

Compiled with newest update dotnet--9.0.101.arm64_sequoia.bottle.tar.gz using brew.sh and still same issue.
How can I debug it?

[elinor-fung]

@superbonaci could you share the information @janvorli requested at #110251 (comment)?

[superbonaci]

Is there any GDB for dotnet? I just can't work with this.

[janvorli]

@superbonaci you can use LLDB, that's what we use to debug native parts of the .NET runtime. I think we can help you more without you having to debug stuff though if you'd share all the details I have asked for before.

One more question - what is the reason for using the brew version of .NET instead of the official build? We don't control or test that one, so that could also be part of the problem.

[superbonaci]

I'll try again after upgrading to macOS 15.2, in case it's operating system bug.