runtime: Failed to create CoreCLR, HRESULT: 0x8007FF02
Issue moved from dotnet/sdk#14351
- Please respond to @John0King.
From @John0King on Wednesday, October 28, 2020 4:05:52 AM
installed version :
- .net core sdk 3.1
- .net core sdk 5.0 rc2
platform and hardware
on MacOs 10.15.3 with Black Mac (Non Apple hardware)
command and result
dotnet -> ok
dotnet --info -> ok
dotnet -h -> Failed to create CoreCLR, HRESULT: 0x8007FF02
dotnet new -> Failed to create CoreCLR, HRESULT: 0x8007FF02
additional info
Vs for Mac run ok,
create xamarin forms for mac run ok,
create C# project (Non .net core) run ok
create .net core console app run fail (both build and clean not work)
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 2
- Comments: 15 (6 by maintainers)
This can be solved by setting allow_mlock in the jail:
iocage set allow_mlock=1 <jail name>Currently, .NET Core relies on the ability to lock single memory page (4kB) for an essential function that is necessary for high performance synchronization of threads with garbage collector. It is used to emulate the FlushProcessWriteBuffers API that we use on Windows which creates a process wide memory barrier. Unfortunately, macOS doesn’t support any equivalent of the membarrier syscall that we use on Linux. We didn’t know of any other way to implement that functionality on macOS until very recently where we have discovered an alternative method that could possibly be used as a fall back in case there was no wired memory left. We are planning to add the new method I’ve mentioned as a fallback mechanism.
@John0King this error means that there is not even a single page of wired memory available for our use. We use one such page. There is a system-wide limit to the amount of memory that can be allocated as wired (locked via mlock). The error means that some other application has consumed all the available wired memory. I’ve seen several such cases reported in the past, one of such applications being parallels desktop. Please see https://github.com/dotnet/runtime/issues/34793 and https://github.com/dotnet/runtime/issues/34708 for more details. The error code mentioned in those issues is different - I have modified coreclr PAL after those to report more fine grained initialization errors, so the 0x8007FF02 is a new error code to indicate the issue described above.
The same happens when running .NET in a VS Code devcontainer. Nothing else is running.