Incorrect OS architecture reported for x86 code running on ARM64

[AntonLapounov]

When x86 code is executed on an ARM64 Windows, System.Runtime.InteropServices.RuntimeInformation.OSArchitecture returns X86 and System.Environment.Is64BitOperatingSystem returns False. These two properties call GetNativeSystemInfo and IsWow64Process Kernel32.dll functions respectively, which conceal the real OS architecture from x86 code by returning PROCESSOR_ARCHITECTURE_INTEL (meaning x86) and FALSE. To obtain the real OS architecture, Windows 10 introduced a new IsWow64Process2 function in version 1511.

We need to make a decision how an app may reliably figure out the real OS architecture it is running on:
Should we fix the implementation of the existing CoreFX properties?
Or do we recommend resorting to an IsWow64Process2 PInvoke wrapped in a necessary try/catch?

[kpreisser]

When x86 code is executed on an ARM64 Windows, System.Runtime.InteropServices.RuntimeInformation.OSArchitecture returns X86 and System.Environment.Is64BitOperatingSystem returns False.

Note that (at least) starting with Windows 10 (ARM64) Build 21277, when running an x86 process, OSArchitecture returns X64 and Is64BitOperatingSystem returns true, probably because starting with that build, x64 apps can also be run using emulation on ARM64.

I'm in favor of fixing the implementation of the .NET properties (in a new major release), so that RuntimeInformation.OSArchitecture will return Arm64 on that OS when the process runs as x86 or x64 using emulation, so that these properties don't "lie" about the true OS architecture, similar to how Environment.OSVersion was fixed with .NET 5.0 (so that it doesn't lie about the actual Windows version if the required <supportedOS> entries aren't present in the manifest).

I think the behavior of GetNativeSystemInfo reporting x86 or x64 on ARM64 OSes is probably for compatibility reasons (for apps that don't know about ARM64); however, in .NET, the Architecture enum already contains values Arm and Arm64, so someone using that property should be aware of ARM64.
(The only compatibility concern would be Environment.Is64BitOperatingSystem currently returning false on earlier ARM64 builds of Windows 10, which would need to change to true when fixing RuntimeInformation.OSArchitecture, which could impact apps that use this property to detect an x64 OS and don't know about ARM64, when those older Windows ARM64 builds can't run x64 apps. However, I think such a breaking change is acceptable with a new major release of .NET.)

For example, an app might want to detect if it runs as x86/x64 on an ARM64 OS, to notify the user that for better performance the native ARM64 version should be used. Currently, we have to p/invoke IsWow64Process2 for that logic.

Windows 10 introduced a new IsWow64Process2 function in version 1511.

I think the documentation doesn't correctly reflect the version where this function is available; IsWow64Process2 is actually only available starting with RS3 (Windows 10 Version 1709, Build 16299).

Thanks!

[Serentty]

It seems that OSArchitecture is also reported as X64 when running in Rosetta 2 on Macs, which seems like a fundamentally similar issue.

[jkotas]

System.Runtime.InteropServices.RuntimeInformation is area-System.Runtime according to https://github.com/dotnet/runtime/blob/main/docs/area-owners.md

[ericstj]

Should we consider doing this in 6.0.0 since we're making a push to get x64 on ARM64 working better? @richlander what are your thoughts?

Seems like we can have RuntimeInformation check for https://docs.microsoft.com/en-us/windows/win32/api/wow64apiset/nf-wow64apiset-iswow64process2 and use it if available, otherwise fallback to using GetNativeSystemInfo. Alternatively we follow Windows' lead and create a new API that exposes this info. I don't think it's correct to not expose this, it's basically the same problem that the existing API was trying to solve.

[jkotas]

@ericstj I have included you on the email thread where we have discussed it.

It is unclear whether fixing this would be an improvement. It is likely to break some applications that depend on this API.

OSArchitecture is a questionable API that is unlikely to be ever 100% right. For example, the API won’t return the actual OS architecture under Linux QEMU either. The primary goal of the OS architecture emulation is to hide the actual OS architecture, and make everything look like emulated architecture. The implementation of the OSArchitecture API has to defeat that, so this API is basically in arms race with how good the OS architecture emulation is.

[richlander]

+1 -- we talked to the Windows folks and decided to leave our implementation as-is. I started from the viewpoint that we should change it. I did not realize that WoW64 has always had this behavior. x84 on Arm64 is the same as that, so changing it doesn't seem very compelling.

[jeffhandley]

Closing per the discussion above that the current behavior is the better option.