- Windows 11 ARM emulates x86 and x64 with Prism (24H2), improving performance and CPU usage.
- Not everything is emulated: drivers, shell extensions, and restricted dynamic code require native Arm64.
- There are fine-tuning (cache, CHPE, multicore, SMC) that increases compatibility in apps conflicting.
- The optimal path is to port to Arm64/Arm64EC with VS 2022 and publish native binaries while maintaining parity.
If you've just bought a new PC with an Arm processor—like a Copilot+ with Snapdragon X—you're probably wondering how to run your x86 and x64 applications in Windows 11 ARMs without losing compatibility. The answer lies in the system's built-in emulation and, more recently, in Prism, the new translation layer Windows 11 24H2 which speeds up and improves the experience.
In this guide, you'll find a clear explanation of how emulation works, what its limits are, and why an x64 installer sometimes refuses to continue. You'll also learn about little-known compatibility tweaks that can make a difference. concrete examples of real failures, a review of apps that are already native to Arm, and a migration path for developers who want to compile on Arm64 with Visual Studio or LLVM.
What is emulation on Windows 11 on Arm?
Windows 11 for Arm includes a translation layer that makes it possible to run x86 and x64 apps unchanged. Windows ARM vs x86 comparison
Emulation is "transparent": it's part of the operating system and doesn't require any additional installation. Internally, the emulator compiles at runtime (JIT). x86/x64 to arm64 instruction blocks, applying optimizations to generate good native code. A system service maintains a cache of these translated blocks per module, so that when you reopen the app, the translation overhead is significantly reduced.
When it comes to x86 processes, the well-known WOW64 layer comes into play. Just like on x64 systems, WOW64 allows x86 binaries to run in 64-bit environments, and in the case of Windows on Arm it also adds file system and registry redirection necessary to properly isolate the x86 process. For x64 the story is different: there is no intermediate WOW64 and Windows uses system binaries in ARM64X PE format that can be loaded into both arm64 and x64 processes from the same location, avoiding redirections and ensuring consistent access to the system.
There is a key point: emulation only covers user mode codeKernel-mode drivers, UMDFs, and other kernel-touching components must be compiled natively for Arm64. If an application depends on a driver that doesn't exist for Arm, emulation won't be able to save that piece.
Prism: The New Translation Layer for Windows 11 24H2
With Windows 11 24H2 comes Prism, the new emulator that replaces the previous technology with Major optimizations in performance and CPU usageMicrosoft is talking about improvements of between 10% and 20% in the same hardware After installing 24H2, you'll notice improvements in loading times, UI fluidity, and power consumption.
Prism is highly tuned for Qualcomm desktop processors, especially the Snapdragon X series found in the Copilot+ PCs. Some advanced optimizations depend on specific hardware capabilities, but Prism is available for any Windows 11 compatible device 24H2 on Arm, and marks the path of coexistence between native and emulated apps during this transition.
Philosophy is very reminiscent of Rosette 2 across Mac with Apple Silicon: this is about providing continuity to the x86-64 ecosystem while developers release their native versions for Arm. Microsoft is confident that Prism performance will be competitive, and as the catalog of Arm64 apps grows, the need for emulation will naturally decrease.
How the system detects emulation and what your app sees
An x86/x64 app typically doesn't "know" it's running on an Arm PC unless it queries specific APIs. If you use IsWow64Process2For example, you can find out if it's running under WOW and what architecture it runs under. If you query CPU details via the API, the system returns data from the emulated processor, and for compatibility, GetNativeSystemInfo It can also provide virtualized values when called from a process under emulation.
If you need to know host capabilities from an app, use GetMachineTypeAttributes to check whether the system supports emulation and what types. This is the path recommended by Microsoft for making compatibility decisions without inducing errors due to architectural assumptions.
Why x64 apps sometimes fail to install and other cases where emulation fails
A very common question: “I have Windows 11 24H2 with Prism and yet an x64 installer tells me that my system is not compatible.” This happened, for example, to a user with the Mechdyne TGX scope on a Surface Pro 11. The cause is usually the installer itself, which implements architecture checks and crashes before even running the app binary. The emulation doesn't intercept this pre-installation logic if the package decides to "self-discard."
There are more scenarios where emulation may fail or not be sufficient: if the app depends on kernel mode drivers (non-emulated), if it injects shell extensions or IMEs that must match the system architecture, or if the installer includes components that load within system processes where mixing architectures isn't possible. In these cases, even if the main executable could be emulated, the dependencies prevent the installation from completing.
Another known block is the dynamic code security policy. Emulation of x86 apps works by generating real-time arm64 code. If an x86 process triggers mitigation ProcessDynamicCodePolicy through SetProcessMitigationPolicy To prevent the generation or modification of JIT code, the x86 app will not be able to run under Arm64 emulation. The solution is to disable this policy in the process.
Finally, some installers assume that if they detect WOW they are in a “classic” x64 system and force the x64 branch of their packages, which can't be used that way on Arm. This pattern is considered bad practice: the recommendation is not to infer the native architecture just from the presence of WOW, and to always refer to IsWow64Process2.
A little-known ally: the compatibility solver and emulation settings
Windows on Arm includes a set of fine controls for emulation which may increase compatibility at the expense of some performance. You can launch the "Program Compatibility Troubleshooter" from the .exe context menu (right-click, Troubleshoot Compatibility) and choose between trying the recommended settings or reporting the observed problem.
If you select "Troubleshoot program problems," you'll see options such as "Worked in previous versions, but now doesn't," "Opens but looks bad," or "Requires additional permissions." Several of these options automatically apply two powerful emulation tweaks: Disable application cache (avoid using the translated block cache) and Disable hybrid execution mode (disables CHPE and forces x86-only binaries).
Additionally, in the Properties of the executable, Compatibility tab, a specific section appears in Arm “Windows 10 on ARM” or “Windows 11 on ARM” with the button “Change emulation settings”From there you can apply predefined sets or activate advanced options individually.
The most relevant options are: disable the application cache (forces re-translating everything on every run), disable CHPE hybrid mode (useful when x86+Arm64 compatible binaries introduce incompatibilities), enable additional light protections, demand strict compatibility with self-modifying code (supports more SMC patterns at the cost of performance) or disable RWX page optimizationIn x64 apps there are also switches to emulate x87 floating point at 80 bits for maximum accuracy, at the expense of speed.
The section of use of multiple cores Allows you to choose between “Fast,” “Strict,” “Very Strict,” or “Force Single Core.” Higher strictness introduces more memory barriers for synchronization and reduces the risk of subtle race conditions, at the cost of lower performance. If an app is unstable with “Fast,” try “Strict.” If a specific option fixes your issue, Microsoft encourages you to submit feedback to woafeedback@microsoft.com for incorporation into the emulator.
Best practices in WOW and detections: how to avoid false assumptions
Many issues arise from incorrect assumptions when detecting WOW. An app that discovers it is running WOW should not conclude that the host is classic x64: on Arm, that condition means emulation, and Registry views, the presence of frameworks and system paths are not equivalent to those of an x86-64 PC.
Typical mistakes: installing the software by force x64 edition When WOW is detected, look for keys in the "native" view of the Registry instead of using abstracted APIs, or assume 64-bit .NET is available on the host. The recommendation is to query IsWow64Process2, use Windows functions that resolve paths appropriately, and avoid code that depends on the host process architecture.
Drivers, Shell Extensions, and Virtualization: When You Need Native Arm64
Any driver that touches the kernel—kernel-mode drivers, UMDF, print drivers—must be compiled as Native Arm64There is no emulation in the kernel. This impacts scenarios such as virtualization or apps that install capture drivers, low-level antivirus, or file filters.
Shell extensions, IMEs, and assistive technologies that load DLLs within Windows processes must also be architecturally appropriate for the system. If your application registers x86 DLLs to integrate with the Explorer, in Arm you will need to recompile them to Arm64.
About Virtual machines, there are chipset limitations. For example, the Windows Hypervisor Platform is not supported Qualcomm 835 platform, so Hyper-V won't work there. Microsoft indicates that it continues to invest in expanding compatibility for future generations.
Practical tips for users: install, test and resolve
First of all, make sure you are on Windows 11 24H2, as Prism boosts performance and fix incompatibilities. If the x64 installer doesn't progress, look for a native Arm64 version or an MSIX/Store edition: many modern apps already offer cross-platform packages that select the correct architecture. If your system includes pre-loaded software, learn how to remove pre-installed apps and bloatware to simplify installations and diagnostics.
If there is only an x86/x64 installer, try running the compatibility solver and adjust the emulation (disable cache, disable CHPE, increase multicore strictness). If the app requires a driver or inject shell extensions, you probably need an Arm64-specific version of those components.
To decide if an app will work, the community maintains catalogs such as “Windows on ARM” that indicate whether an app has full support, works with Prism or is incompatible. It's not official and may become outdated, but it's a useful reference before purchasing or migrating.
If you need to use critical software that doesn't offer an Arm path in the short term, consider alternatives: progressive web builds, UWP editions or equivalent clients, or even running the software on a Remote VM or x86-64 remote desktop and access it from your Arm PC until the native port arrives.
Applications that are already native on Arm: what you can install today
The catalog is growing rapidly. Microsoft has ported its core apps (Teams, Word, Excel, Outlook, PowerPoint), and there's native support for popular browsers and tools. With Windows 11 24H2 and Copilot+ PC, Chrome now has an Arm version, and the base Chromium project is also supported, opening the door to most derivative browsers.
In creativity and productivity there are mature options: Adobe Photoshop and Lightroom are available for Arm, and Adobe has announced native versions of Premiere Pro and Illustrator. You can also work with Blender, the Affinity suite (Designer, Publisher, Photo), GIMP, LibreOffice or even DaVinci, covering everything from photo retouching to editing and modeling.
For multimedia and services, clients such as VLC, Netflix, Disney+, Spotify or Prime Video run on Arm, either as native apps or through the Store. This native ecosystem allows for better performance and lower battery consumption for everyday tasks compared to emulation.
Recent history: from x86 emulation in Windows 10 to x64 and Prism
In Windows 10 for Arm, emulation was limited to 86-bit x32 applications. Later, Microsoft added x64 emulation in Insider channels (for example, build 21277), making a fundamental leap to running software that had already abandoned 32-bit support.
With Windows 11 x64 emulation is consolidated and 24H2 introduces Prism, which brings faster translation and a Rosetta 2-like approach: frictionless continuity as the ecosystem migrates to Arm64 binaries. In many scenarios, the emulated performance is good enough for everyday use, although the goal will always be the native binary.
Developer Path: Bringing Your App to Arm64 (and Arm64EC)
While Prism gets you out of the way, porting the application to Arm64 offers better runtimes. Boot, lower consumption and access to CPU, GPU and NPU optimized. The path is straightforward with Visual Studio 2022 (v17.4 or later), which natively supports building and debugging Arm64 projects on Arm machines. You can also use Visual Studio 17.10 Preview and LLVM/Clang 12+ if you prefer that toolchain.
Basic steps: add a Arm64 configuration to your solution (Configuration Manager, new Arm64 platform copying from x64), recompile, fix dependency errors, and test on Arm hardware or in a Windows VM on Arm using local or remote debugging. If you want to verify the binary, run dumpbin /headers .\<appname>.exe and search in FILE HEADER VALUES for the string AA64 machine (ARM64).
Once validated, compile and test automatically on Arm (CI/CD). To publish, add the Arm64 package to the Microsoft Store or your MSI/EXE/MSIX channel. If you distribute from the web, you can use Client Hints User-Agent to detect Windows devices on Arm and serve them the appropriate installer, rather than relying on the classic user-agent chain.
Dependencies that block the port are the most common obstacle. You have several options: recompile internal libraries, request a third-party Arm64 build, review vcpkg for already ported versions, or even contribute to Arm support for those projects yourself. Linaro offers a Service Desk to accelerate ports in the Arm ecosystem if you need it.
If migrating everything to Arm64 at once is not feasible, consider Arm64EC: allows you to compile your main app for Arm64 while still consuming x64 dependencies that will run under emulation within the same process. It's not possible to mix pure Arm64 dependencies into an Arm64EC process that expects x64, but it can be very useful as a transition.
Don't forget architecture-specific code: CPU intrinsics and inline assembler must be rewritten for Arm or encapsulated behind portable layers. And if your app install drivers, you'll need to compile those drivers natively for Arm64 using the WDK; there are no shortcuts with in-kernel emulation.
Supported tools and frameworks include .NET 7 and 6 (LTS), .NET 5.0.8+, .NET Framework 4.8.1, and clang-cl (MSVC-compatible ABI). For installers, frameworks like WiX, Squirrel, Inno Setup, or InstallAware support Windows on Arm without any surprises. Plan for functional parity between architectures to avoid user confusion.
If you get stuck, Microsoft offers App Assure Arm Advisory Service to help optimize and resolve crashes. And as a best practice, keep versions aligned and automate tests on Arm to avoid breaking compatibility in future releases.
Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.