dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.28k stars 4.73k forks source link

Failed to create CoreCLR, HRESULT: 0x8007000C #96247

Closed LilyStilson closed 7 months ago

LilyStilson commented 10 months ago

Description

After updating to macOS Sonoma from macOS Monterey, dotnet runtime does not start with error Failed to create CoreCLR, HRESULT: 0x8007000C.

❯ dotnet new console
Failed to create CoreCLR, HRESULT: 0x8007000C
❯ dotnet --info
Failed to create CoreCLR, HRESULT: 0x8007000C

Host:
  Version:      8.0.0
  Architecture: arm64
  Commit:       5535e31a71
  RID:          osx-arm64

.NET SDKs installed:
  8.0.100 [/opt/homebrew/Cellar/dotnet/8.0.0/libexec/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0 [/opt/homebrew/Cellar/dotnet/8.0.0/libexec/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.0 [/opt/homebrew/Cellar/dotnet/8.0.0/libexec/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  DOTNET_ROOT       [/opt/homebrew/Cellar/dotnet/8.0.0/libexec]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Reproduction Steps

1) Be on macOS Sonoma 2) Run dotnet --info or dotnet new console 3) Observe Failed to create CoreCLR, HRESULT: 0x8007000C

Expected behavior

dotnet runtime starts and works normally.

Actual behavior

It outputs Failed to create CoreCLR, HRESULT: 0x8007000C and exists with SIGKILL.

Regression?

It was working perfectly on macOS Monterey for me. .NET version stayed the same, installed through Homebrew.

Known Workarounds

No response

Configuration

Device: MacBook Air 13 (M1, 2020) 16 GB, 512 GB .NET Version: 8.0.100 (Homebrew) OS: macOS Sonoma Version 14.2 (23C64), ARM64 There was similar issue over on YouTrack/RIDER-97269, but it was somehow solved for the person reporting it.

Other information

I have attached a log of running dotnet --info with export COREHOST_TRACE=1. dotnet_info.log

ghost commented 10 months ago

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

Issue Details
### Description After updating to macOS Sonoma from macOS Monterey, dotnet runtime does not start with error `Failed to create CoreCLR, HRESULT: 0x8007000C`. ```text ❯ dotnet new console Failed to create CoreCLR, HRESULT: 0x8007000C ``` ```text ❯ dotnet --info Failed to create CoreCLR, HRESULT: 0x8007000C Host: Version: 8.0.0 Architecture: arm64 Commit: 5535e31a71 RID: osx-arm64 .NET SDKs installed: 8.0.100 [/opt/homebrew/Cellar/dotnet/8.0.0/libexec/sdk] .NET runtimes installed: Microsoft.AspNetCore.App 8.0.0 [/opt/homebrew/Cellar/dotnet/8.0.0/libexec/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 8.0.0 [/opt/homebrew/Cellar/dotnet/8.0.0/libexec/shared/Microsoft.NETCore.App] Other architectures found: x64 [/usr/local/share/dotnet/x64] registered at [/etc/dotnet/install_location_x64] Environment variables: DOTNET_ROOT [/opt/homebrew/Cellar/dotnet/8.0.0/libexec] global.json file: Not found Learn more: https://aka.ms/dotnet/info Download .NET: https://aka.ms/dotnet/download ``` ### Reproduction Steps 1) Be on macOS Sonoma 2) Run `dotnet --info` or `dotnet new console` 3) Observe `Failed to create CoreCLR, HRESULT: 0x8007000C` ### Expected behavior `dotnet` runtime starts and works normally. ### Actual behavior It outputs `Failed to create CoreCLR, HRESULT: 0x8007000C` and exists with `SIGKILL`. ### Regression? It was working perfectly on macOS Monterey for me. .NET version stayed the same, installed through Homebrew. ### Known Workarounds _No response_ ### Configuration Device: MacBook Air 13 (M1, 2020) 16 GB, 512 GB .NET Version: `8.0.100` ([Homebrew](https://formulae.brew.sh/cask/dotnet)) OS: macOS Sonoma Version 14.2 (23C64), ARM64 There was similar issue over on [YouTrack/RIDER-97269](https://youtrack.jetbrains.com/issue/RIDER-97269), but it was somehow solved for the person reporting it. ### Other information I have attached a log of running `dotnet --info` with `export COREHOST_TRACE=1`. [dotnet_info.log](https://github.com/dotnet/runtime/files/13744187/dotnet_info.log)
Author: LilyStilson
Assignees: -
Labels: `area-Host`, `untriaged`
Milestone: -
janvorli commented 10 months ago

The error code means ERROR_INVALID_ACCESS and it seems the only place it can come from is this: https://github.com/dotnet/runtime/blob/9fa5128e2d16855bef83560a5a38b493fa3eb7ea/src/coreclr/pal/src/map/virtual.cpp#L1216 I'll update my macOS to the latest Sonoma and see if I can repro it.

janvorli commented 10 months ago

@LilyStilson I've just tried it on my macOS (updating to the latest Sonoma got me 14.3 beta) and I cannot repro the issue. But I have not tried the homebrew version. So I wonder if homebrew could be involved in the process somehow. Can you please try to download the official .tar.gz from our site https://dotnet.microsoft.com/en-us/download/dotnet/8.0 (use the link in the Binaries column, macOS row, arm64), untar it somewhere and then run the dotnet from that location? This is what I get:

 ./dotnet --info
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.6c33ef20

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.3
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /Users/janvorli/dotnet80/sdk/8.0.100/

.NET workloads installed:
 Workload version: 8.0.100-manifests.6c33ef20
There are no installed workloads to display.

Host:
  Version:      8.0.0
  Architecture: arm64
  Commit:       5535e31a71

.NET SDKs installed:
  8.0.100 [/Users/janvorli/dotnet80/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0 [/Users/janvorli/dotnet80/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.0 [/Users/janvorli/dotnet80/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
LilyStilson commented 10 months ago

@janvorli Hello, thanks for your reply. I tried getting binaries from the link you sent me, but it's all the same for me

❯ ./dotnet --info
Failed to create CoreCLR, HRESULT: 0x8007000C

Host:
  Version:      8.0.0
  Architecture: arm64
  Commit:       5535e31a71
  RID:          osx-arm64

.NET SDKs installed:
  8.0.100 [/Users/lilystilson/Downloads/dotnet-sdk-8.0.100-osx-arm64/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0 [/Users/lilystilson/Downloads/dotnet-sdk-8.0.100-osx-arm64/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.0 [/Users/lilystilson/Downloads/dotnet-sdk-8.0.100-osx-arm64/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

At this point, I'm not sure at all why this happens, and it looks like it's something that happens on my particular machine, and I have no idea why it even could happen...

LilyStilson commented 10 months ago

I've also tried getting .NET version 7 (ARM, macOS) and it seems to work perfectly fine

❯ ./dotnet --info
.NET SDK:
 Version:   7.0.404
 Commit:    22f221a24c

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.2
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /Users/lilystilson/Downloads/dotnet-sdk-7.0.404-osx-arm64/sdk/7.0.404/

Host:
  Version:      7.0.14
  Architecture: arm64
  Commit:       808851b07a

.NET SDKs installed:
  7.0.404 [/Users/lilystilson/Downloads/dotnet-sdk-7.0.404-osx-arm64/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.14 [/Users/lilystilson/Downloads/dotnet-sdk-7.0.404-osx-arm64/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.14 [/Users/lilystilson/Downloads/dotnet-sdk-7.0.404-osx-arm64/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
❯ ./dotnet new console

Welcome to .NET 7.0!
---------------------
SDK Version: 7.0.404

Telemetry
---------
The .NET tools collect usage data in order to help us improve your experience. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.

Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry

----------------
Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
Learn about HTTPS: https://aka.ms/dotnet-https
----------------
Write your first app: https://aka.ms/dotnet-hello-world
Find out what's new: https://aka.ms/dotnet-whats-new
Explore documentation: https://aka.ms/dotnet-docs
Report issues and find source on GitHub: https://github.com/dotnet/core
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli
--------------------------------------------------------------------------------------
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring /Users/lilystilson/Downloads/dotnet-sdk-7.0.404-osx-arm64/dotnet-sdk-7.0.404-osx-arm64.csproj:
  Determining projects to restore...
  Restored /Users/lilystilson/Downloads/dotnet-sdk-7.0.404-osx-arm64/dotnet-sdk-7.0.404-osx-arm64.csproj (in 31 ms).
Restore succeeded.
doghouch commented 10 months ago

I also had this issue on macOS Sonoma (14.1), so just a tad older than 14.2. Spent a few hours re-installing and stumbled on this issue with the exact same error code.

I saw the linked issue (which seems to be resolved), and the "temporary fix" was to re-enable SIP (System Integrity Protection), assuming it was disabled. Given that it seems to have already been tried here, I'm not sure what else to do -- would the best course of action be to just revert to a previous version of macOS?

Edit: Checked anyway and it seems like I had SIP disabled. Re-enabling SIP seems to have fixed the problem for me.

LilyStilson commented 9 months ago

@doghouch Thanks for the idea with SIP, I actually haven't tried that one. Unfortunately, I don't really have time to always reboot into recovery and constantly enable-disable SIP if I want to work in Rider, so I just installed a macOS 14 VM to work this around. However, the issue persists, and imo it should not be like that: .NET 7 works even with SIP disabled.

doghouch commented 8 months ago

@doghouch Thanks for the idea with SIP, I actually haven't tried that one. Unfortunately, I don't really have time to always reboot into recovery and constantly enable-disable SIP if I want to work in Rider, so I just installed a macOS 14 VM to work this around. However, the issue persists, and imo it should not be like that: .NET 7 works even with SIP disabled.

Yeah, it doesn’t really make much sense to me either. While I managed to work around this (thankfully, I had only disabled SIP to install Linux on my machine, so flip-flopping didn’t become a problem), I do hope that a fix is found soon.

meghrathod commented 8 months ago

@janvorli Can you try to reproduce this by disabling SIP temporarily, I'm using a legacy piece of software which requires SIP disabled, and I am unable to use apps that reply on this runtime with SIP disabled.

janvorli commented 7 months ago

@meghrathod I am sorry for the delay, I was heads down investigating and fixing some bugs. I have tried to disable SIP today. And dotnet works for me without any issues:

janvorli@janvorli-M1 testsip % csrutil status
System Integrity Protection status: disabled.

With .NET 8

janvorli@janvorli-M1 testsip % ~/dotnet80/dotnet --info
.NET SDK:
 Version:           8.0.200
 Commit:            438cab6a9d
 Workload version:  8.0.200-manifests.014977a5

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.4
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /Users/janvorli/dotnet80/sdk/8.0.200/

.NET workloads installed:
 [maui]
   Installation Source: SDK 8.0.200
   Manifest Version:    8.0.0-rc.1.9171/8.0.100-rc.1
   Manifest Path:       /Users/janvorli/dotnet80/sdk-manifests/8.0.100-rc.1/microsoft.net.sdk.maui/8.0.0-rc.1.9171/WorkloadManifest.json
   Install Type:        FileBased

Host:
  Version:      8.0.2
  Architecture: arm64
  Commit:       1381d5ebd2

.NET SDKs installed:
  8.0.200 [/Users/janvorli/dotnet80/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.2 [/Users/janvorli/dotnet80/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.2 [/Users/janvorli/dotnet80/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
janvorli commented 7 months ago

And the same with .NET 7:

janvorli@janvorli-M1 testsip % ~/dotnet7/dotnet --info

.NET SDK:
 Version:   7.0.100-rc.2.22477.23
 Commit:    0a5360315a

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.4
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /Users/janvorli/dotnet7/sdk/7.0.100-rc.2.22477.23/

Host:
  Version:      7.0.0-rc.2.22472.3
  Architecture: arm64
  Commit:       550605cc93

.NET SDKs installed:
  7.0.100-rc.2.22477.23 [/Users/janvorli/dotnet7/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.0-rc.2.22476.2 [/Users/janvorli/dotnet7/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 7.0.0-rc.2.22472.3 [/Users/janvorli/dotnet7/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
janvorli commented 7 months ago

Actually, I've just spotted something in one of the outputs from the dotnet --info above that has failed:

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

I wonder if they can somehow collide.

agocke commented 7 months ago

From the log, it looks like the host, which is signed with the MSFT key, is trying to load the runtime from homebrew, which is signed with an ad hoc key. That is likely producing the security issue in the original issue. It's not clear what's happening with the other cases. I'm going to close this issue since it's not clear each of these problems is the same thing.