Repository navigation
Hostfxr.dll load failure with arm64 app on arm64 Windows 11 host #65263
Description
Description
After deploying a hello-world framework-dependent portable net6.0 app onto a Windows 11 arm64 host, attempts to launch that app result in failure.
Reproduction Steps
- Download/extract supplied
dotnet_6_arm64_repro.zip(see below) dotnet publish- Copy
\bin\ARM64\Debug\net6.0\publish\to arm64 machine - Execute
dotnet_6_arm64_repro.exe - (Optional) Address the missing .NET 6.0.2 dependency by installing
.NET 6.0 Desktop Runtime (v6.0.2) - Windows arm64, and revisit step 4.
Expected behavior
App to run and print Hello, World! successfully.
Actual behavior
App fails with:
Failed to load the dll from [C:\Program Files\dotnet\host\fxr\6.0.2\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Program Files\dotnet\host\fxr\6.0.2\hostfxr.dll failed
- Installing .NET prerequisites might help resolve this problem.
https://go.microsoft.com/fwlink/?linkid=798306
Regression?
No response
Known Workarounds
No response
Configuration
Windows 11 22504.1010 (arm64)
Visual Studio 2022 17.0.5
Other information
Host (useful for support):
Version: 6.0.2
Commit: 839cdfb0ec
.NET SDKs installed:
No SDKs were found.
.NET runtimes installed:
Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
Core host trace, verbosity=4
Tracing enabled @ Sat Feb 12 21:16:51 2022 GMT
--- Invoked apphost [version: 6.0.2, commit hash: 839cdfb0ecca5e0be3dbccd926e7651ef50fdf10] main = {
C:\Users\Rafael\desktop\publish\dotnet_6_arm64_repro.exe
}
Redirecting errors to custom writer.
The managed DLL bound to this executable is: 'dotnet_6_arm64_repro.dll'
Can't open the SDK installed location registry key, result: 0x2
Using global installation location [C:\Program Files\dotnet] as runtime location.
Reading fx resolver directory=[C:\Program Files\dotnet\host\fxr]
Considering fxr version=[6.0.2]...
Detected latest fxr version=[C:\Program Files\dotnet\host\fxr\6.0.2]...
Resolved fxr [C:\Program Files\dotnet\host\fxr\6.0.2\hostfxr.dll]...
Failed to load the dll from [C:\Program Files\dotnet\host\fxr\6.0.2\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Program Files\dotnet\host\fxr\6.0.2\hostfxr.dll failed
- Installing .NET prerequisites might help resolve this problem.
https://go.microsoft.com/fwlink/?linkid=798306
> dotnet --list-runtimes
Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
> dotnet --list-sdks
[no output]
Activity
vitek-karas commentedon Feb 13, 2022
I didn't try on actual Windows ARM64, but following the repro steps I think the problem is with the publish. The command line
dotnet publishwill not by default pick up theProperties\FolderProfile.pubxml, so it publishes as portable app (no target architecture). But it will still produce an apphost, theexe. Since no target architecture is specified, it will produce the apphost for the RID of the SDK it's using - which is presumably something likewin-x64.So if I follow the repro steps, the produced
.exeis awin-x64executable. When executed onwin-arm64, this will start an emulated x64 process, which will then find the arm64hostfxrand that fails to load. The error code is ERROR_BAD_EXE_FORMAT - which means "wrong architecture" in most cases.I think the main problem here is that apphost is not clever enough to default to the x64 install location on arm64 hardware. It did look into registry, into the x64 key, but that doesn't exist - failed with 0x2 ERROR_FILE_NOT_FOUND. So if defaults to the hardcoded install location - which should be
C:\Program Files\dotnet\x64on win-arm64, but it doesn't. (if it did, it would have failed saying that it's missing the runtime and would point out that it needs x64 runtime).We sort of fixed this with this PR: #59890
What that will do is make the x64 apphost look for the runtime in the right x64 location - and fail to find any runtime and correctly ask for installing the x64 runtime.
Maybe we should consider backporting this fix to 6.0.
Other improvements:
dotnet --infoclear that it lists arm64 runtimes (and not x64)riverar commentedon Feb 13, 2022
Hm @vitek-karas, I can verify the apphost is x64. But no configuration of publish commands appears to correct this. (For example, I tried
dotnet publish /p:PublishProfile=.\Properties\PublishProfiles\FolderProfile.pubxml /p:Platform=ARM64).vitek-karas commentedon Feb 13, 2022
I think that
Platformis not the right variable for this (but I admit knowing very little about which one is the right one). What should definitely work is:dotnet publish -r win-arm64ordotnet publish -a arm64.pfeifix commentedon Apr 25, 2022
Any updates on this issue?
I get the same error message when creating an inital migration for a database via the EntityFramework CLI tools, for example when trying to execute:
dotnet ef migrations add InitialCreatestrictly following the process described by Microsoft: https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/?tabs=dotnet-core-cli
The exact error is
The error might be related to the EF Core .NET CLI tools (https://docs.microsoft.com/en-us/ef/core/cli/dotnet) when running on ARM64. Maybe anyone from Microsoft has to look into this?
riverar commentedon Apr 25, 2022
@vitek-karas Friendly ping. Would be great if we could get this into 6.0 servicing, given it's a LTS release.
vitek-karas commentedon Apr 26, 2022
We're looking into it, but note that it might not fix the
dotnet-efproblem fully. There's a longer discussion about that specific tool here: dotnet/efcore#27787pfeifix commentedon Apr 26, 2022
I would greatly appreciate if someone can present me a workaround for using the basic database migrations commands with
dotnet-ef(see my post above) in VS Code. At the moment I am stuck with my work on my Surface Pro X running Windows on ARM64. :-(pfeifix commentedon Apr 26, 2022
Update: Problem is resolved, see dotnet/efcore#27787 (comment) .
elinor-fung commentedon May 4, 2022
We have backported a fix into 6.0 servicing which should make the x64 apphost look for the runtime in the correct location for the x64 runtime (and fail reasonably if one doesn't exist). It will be in 6.0.6.
riverar commentedon May 4, 2022
@elinor-fung That's fantastic, thanks for closing the loop!
AlisaZhang3 commentedon Jun 16, 2022
We encounter the similar issue in the latest main branch. When we create a new console core 6.0 project and change the target to X64. Start debugging. VS will pop up an error and the error is NET 7 not NET 6.
vitek-karas commentedon Jun 16, 2022
Can you please check the version of the apphost?
I guess the easiest way would be to set
COREHOST_TRACE=1and run the app in question. It will print out much more detailed trace including the version of the host.AlisaZhang3 commentedon Jun 16, 2022
Ok. I have collected the detailed trace as below:
vitek-karas commentedon Jun 16, 2022
Do you have x64 runtime installed?
Basically is there a file
D:\Program Files\dotnet\x64\dotnet.exe?AlisaZhang3 commentedon Jun 16, 2022
I checked the folder and found no x64 runtime installed
vitek-karas commentedon Jun 16, 2022
Well - it's weird that there are directories there but no dotnet.exe. It's as if the install is either corrupted or something else went wrong.
In any case, I don't think your apphost has the fix mentioned above - the commit hash it has is from Apr 13, while the fix was ported to 6.0 in May. @elinor-fung do you know which version of 6 has the fix and if it's in one of the public releases?
elinor-fung commentedon Jun 16, 2022
6.0.5 does not have the fix. The fix is in 6.0.6 - just released recently (14-JUN), so you'd need to rebuild the app with that to pick up the fixed apphost.
roofiq commentedon Jun 27, 2022
Hello, seems like 6.0.6 didn't fix the issue. I'm still experiencing this error, running on Windows Server 2022 version 21H2 x64.
vitek-karas commentedon Jun 27, 2022
@roofiq This GitHub issue is specific to the behavior on ARM64. Since you're running into a similar error message but on X64 I suggest you create a new issue as it's very likely not related.
Please try to collect host traces as per https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#corehost_trace.
agocke commentedon Jul 1, 2022
Closing as resolved