重要
使用 Visual Studio 2017 或更高版本，可以将应用重新编译到 Arm64 或 Arm64EC，以便应用以完全本机速度运行。 有关编译为 Arm64 的详细信息，请参阅博客文章：Arm 开发上对 Windows 10 的官方支持。 有关 Arm64EC 的信息，请参阅 宣布推出 Arm64EC：在 Arm上生成适用于 Windows 11 的本机和可互操作应用。
如果 x86 桌面应用在 x86 计算机上无法正常工作，可参考以下指南帮助你进行故障排除。
| 問题 | 解决方案 |
|---|---|
| 你的应用依赖于不是针对 Arm 设计的驱动程序。 | 将 x86 驱动程序重新编译到 Arm64。 请参见 使用 WDK构建 Arm64 驱动程序。 |
| 你的应用仅适用于 x64。 | 如果针对 Microsoft Store 进行开发，请提交应用的 Arm 版本。 有关详细信息，请参阅 应用包体系结构。 如果你是 Win32 开发人员，我们建议将应用重新编译到 Arm64。 有关详细信息，请参阅 Arm 开发上对 Windows 10 的 Visual Studio 支持的早期预览版。 |
| 你的应用使用低于 1.1 的 OpenGL 版本，或者需要硬件加速的 OpenGL。 | 使用应用的 DirectX 模式（如果可用）。 使用 DirectX 9、DirectX 10、DirectX 11 和 DirectX 12 的 x86 应用可在 Arm 上运行。 有关详细信息，请参阅 DirectX 图形和游戏。 |
| x86 应用无法按预期工作。 | 请遵循 Arm上的 |
WOW 的最佳做法
当应用发现它在 WOW 下运行，然后假定它位于 x64 系统上时，会出现一个常见问题。 做出此假设后，应用可能会执行以下操作：
- 尝试安装 x64 版本，它不受 Arm 支持。
- 检查默认注册表视图中的其他软件。
- 假设有 64 位 .NET 框架可用。
通常，当应用确定在 WOW 下运行时，不应对主机系统做出假设。 避免尽可能多地与 OS 的本机组件进行交互。
应用可以在本机注册表视图下放置注册表项，或者根据 WOW 的存在执行函数。 原始 IsWow64Process 仅指示应用是否在 x64 计算机上运行。 应用现在应使用 IsWow64Process2 来确定它们是否在具有 WOW 支持的系统上运行。
司机
所有内核模式驱动程序、User-Mode 驱动程序框架（UMDF） 驱动程序，并且必须编译打印驱动程序以匹配操作系统的体系结构。 如果 x86 应用具有驱动程序，则必须为 Arm64 重新编译该驱动程序。 但是，x86 应用在仿真下可能运行正常，但是，需要为 Arm64 重新编译其驱动程序，并且依赖于驱动程序的任何应用体验都不可用。 有关为 Arm64 编译驱动程序的详细信息，请参阅 使用 WDK生成 Arm64 驱动程序。
Shell 扩展
尝试将 Windows 组件或将其 DLL 加载到 Windows 进程中的应用需要重新编译这些 DLL，以适应系统架构，例如 Arm64。 通常，输入法编辑器（IME）、辅助技术和 shell 扩展应用（例如，在资源管理器中显示云存储图标或右键单击上下文菜单）使用这些图标。 若要了解如何将应用或DLL重新编译以在Arm64上运行，请参阅有关 Windows 10 上开发的 Visual Studio 支持的 早期预览版的 博客文章。
调试
若要更深入地调查应用的行为，请参阅 Arm 上的调试，了解有关在 Arm 上进行调试的工具和策略的详细信息。
虚拟机
Qualcomm Snapdragon 835 移动 PC 平台不支持 Windows Hypervisor 平台。 因此，使用 Hyper-V 运行虚拟机将不起作用。 我们将继续在这些技术上进行投资，以应用于未来的高通芯片。
动态代码生成
X86 桌面应用程序在 Arm64 上通过系统在运行时生成 Arm64 指令进行仿真。 这意味着，如果 x86 桌面应用在其进程中阻止动态代码生成或修改，则不支持该应用在 Arm64 上运行为 x86。
某些应用程序通过使用带有 标志的 ProcessDynamicCodePolicy API，在它们的进程中启用这种安全缓解措施。 若要在 Arm64 上成功作为 x86 进程运行，必须禁用此缓解策略。
