Repository navigation
Failed to create CoreCLR, HRESULT: 0x8007FF02 #44417
Description
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)
Activity
janvorli commentedon Nov 9, 2020
@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 #34793 and #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.
John0King commentedon Nov 10, 2020
but xamarin app runs fine , and also the vs for Mac. no matter what you try to ensure, sacrifice the ability to run is not acceptable，so please learn from mono
TanayParikh commentedon Nov 13, 2020
Can confirm, I'm getting
Failed to create CoreCLR, HRESULT: 0x8007FF02when I rundotnet newwhile Parallels Desktop is also running. Possibly of note, other applications and commands can be started and run without issue.John0King commentedon Nov 13, 2020
@TanayParikh In my case is different. I can confirm that the parallels desktop is not even install.
janvorli commentedon Nov 13, 2020
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.
janvorli commentedon Nov 13, 2020
@John0King can you please share the output of the following commands?
These would show how many wired pages are there currently allocated on your machine, what is the per process limit imposed on them and what applications use them.
John0King commentedon Nov 24, 2020
janvorli commentedon Nov 24, 2020
Thank you @John0King. From these, I can see that the amount of allocated wired memory is currently 2404175 pages, which is 9847500800 bytes (9.17GB). From those, only ~30MB is allocated by the kernel extensions, so I assume the rest must be consumed by some application(s). However, I have not found a way to print or view wired memory usage per process.
Can you please share what is the physical memory amount on your machine?
John0King commentedon Nov 24, 2020
it's 12 GB RAM
dustinmoris commentedon Mar 19, 2021
The same happens when running .NET in a VS Code devcontainer.
Nothing else is running.
zaneclaes commentedon Jun 4, 2021
Also happens running the dotnet5 arm32v7 Docker image on a Raspberry Pi 4. Rebooting has no effect.
janvorli commentedon Jun 5, 2021
@zaneclaes are you sure the HRESULT is exactly the same (0x8007FF02) on the RPI 4? We use different HRESULT codes for different failure locations and the problem specific to 0x8007FF02 was never observed on anything else than macOS.
zaneclaes commentedon Jun 5, 2021
@janvorli ah, no, the HRESULT was
0x80004005. Since this value is a dword, I assumed it was a pointer or memory offset of some kind (which would change with every build). I will open a new issue for this, in that case.arrowd commentedon Sep 27, 2021
Bumped into this problem when tried to run
dotnet newunder FreeBSD jail. Indeed, it fails due tomlock(2)returningEPERM, because jails aren't allowed to lock pages by default.Zamana commentedon Jan 18, 2022
This can be solved by setting allow_mlock in the jail:
iocage set allow_mlock=1 <jail name>gwr commentedon Jun 30, 2024
Looking at what Apple did for MacOS offers some interesting ideas.
On many OS implementations, it may be sufficient to walk all threads in the process (except the caller) and use some (yet to be determined) mechanism to force all those threads to flush state.
I'm not sure how to do that, but walking all threads happens some places in the private implementations already (eg. on fork).
dotnet-policy-service commentedon Apr 9, 2026
Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.