EC2 Graviton Windows 11 ARM 的 x86/x64 模拟兼容性实测
在 EC2 Graviton 实例上跑 Windows 11 ARM 后，最实际的问题就是：x86/x64 的运维工具还能不能用？本文在 t4g.large（Graviton2）上对 Sysinternals Suite 全套工具做了兼容性测试，对比了 ARM64 原生与 x64 模拟的性能差异。
测试环境
| 项目 | 配置 |
|---|---|
| 实例 | t4g.large（2 vCPU / 8 GB），Graviton2 |
| 系统 | Windows 11 Pro 25H2 ARM64（Build 26200） |
| Sysinternals Suite | v2024.11.28（ARM64 版 + x64 版） |
结论速览
| 类别 | ARM64 原生 | x64 模拟 | 说明 |
|---|---|---|---|
| 用户态工具（PsExec、Handle、sigcheck 等） | 可用 | 可用 | 均正常工作 |
| 内核驱动型工具（Sysmon） | 可用 | 不可用 | x64 内核驱动无法加载到 ARM64 内核 |
| 性能开销 | 基准 | +10%~32% | IO 密集型差距小，CPU 密集型差距大 |
| SSM Agent / AWS CLI | x64 模拟运行 | — | 无 ARM64 原生版本，但工作正常 |
| PowerShell 5.1 | x64 模拟运行 | — | 进程自身报告 Architecture=X64 |
| Hyper-V / WSL / 容器 | 不可用 | — | 无嵌套虚拟化支持 |
模拟层原理
Windows 11 ARM 内置两套翻译器：
- xtajit64.dll（System32）：x64 → ARM64 即时编译翻译（Prism），处理 64 位 x64 程序
- xtajit.dll（SysWOW64）：x86 → ARM64 翻译，处理 32 位 x86 程序
翻译在用户态完成，对应用透明。进程自己"看到"的 ProcessArchitecture 是 X64，GetNativeSystemInfo 等 API 也返回 x64 信息。但这套机制只覆盖用户态——内核驱动必须是 ARM64 原生编译。
实测进程分布：ARM64 原生 138 个，x64 模拟 6 个，x86 模拟 1 个。
Sysinternals 工具兼容性
ARM64 原生版（文件名带 64a 后缀）有 58 个工具，x64 标准版有 151 个。核心运维工具均有 ARM64 原生版。
有 ARM64 原生版的工具（58 个）
包括：PsExec64a、Procmon64a、procexp64a、Sysmon64a、handle64a、autorunsc64a、sigcheck64a、procdump64a、strings64a、psping64a、Autoruns64a、accesschk64a、ADExplorer64a、ADInsight64a 等。
仅有 x64 版本的工具
PsLoggedon、psloglist、Cacheset、Clockres、Contig、CPUSTRES、ctrl2cap、Desktops、disk2vhd、Diskmon、DiskView、du、efsdump、hex2dec、junction、ldmdump、livekd、LoadOrd、logonsessions、movefile、notmyfault、ntfsinfo、pendmoves、pipelist、portmon、RAMMap、RDCMan、regjump、ru、sdelete、ShareEnum、ShellRunas、sync、tcpview、Testlimit、vmmap、Volumeid、Winobj、ZoomIt 等。
这些 x64-only 工具全部可在模拟层下正常执行（用户态工具）。
内核驱动工具测试
| 工具 | ARM64 原生 | x64 模拟 |
|---|---|---|
| Sysmon64a.exe（ARM64） | 驱动安装并启动成功，事件正常采集 | — |
| Sysmon64.exe（x64） | — | 安装成功但 SysmonDrv 启动失败 |
Sysmon ARM64 原生版安装后 SysmonDrv 内核驱动正常加载，Event Log 产生 Process Create 和 Process Terminate 事件。x64 版安装时输出 installed，但 StartService failed for SysmonDrv——内核只接受 ARM64 原生驱动。
x64 工具模拟执行实测
| 工具 | 测试操作 | 结果 |
|---|---|---|
| PsExec64.exe | 本地执行 cmd /c echo | 正常 |
| PsInfo64.exe | 查询本机信息 | 正常显示 Graviton2 处理器 |
| handle64.exe | 列举 explorer.exe 句柄 | 正常 |
| Listdlls64.exe | 列举 explorer.exe DLL | 正常 |
| autorunsc64.exe | 扫描启动项 | 正常 |
| sigcheck64.exe | 验证 ntoskrnl.exe 签名 | 正常（报告 MachineType: 64-bit ARM） |
| strings64.exe | 提取 ntoskrnl.exe 字符串 | 正常 |
| psping64.exe | TCP ping localhost:3389 | 正常（延迟 ~0.43ms） |
| procdump64.exe | dump explorer 进程 | 成功（1055 MB，32.6 秒） |
| Coreinfo64.exe | 查询 CPU 信息 | 能运行但部分信息不准确（地址宽度报告 32-bit） |
性能对比：ARM64 原生 vs x64 模拟
sigcheck 签名验证（扫描 ntoskrnl.exe，5 次取总时间）
| 版本 | 耗时 | 相对开销 |
|---|---|---|
| sigcheck64a（ARM64 原生） | 731 ms | 基准 |
| sigcheck64（x64 模拟） | 964 ms | +32% |
strings 字符串提取（扫描 ntoskrnl.exe，单次）
| 版本 | 耗时 | 相对开销 |
|---|---|---|
| strings64a（ARM64 原生） | 15,671 ms | 基准 |
| strings64（x64 模拟） | 17,310 ms | +10% |
IO 密集型操作的模拟开销约 10%，CPU 密集型（加密签名验证）约 32%。
AWS 组件状态
| 组件 | 架构 | 状态 |
|---|---|---|
| Amazon SSM Agent 3.3.4624.0 | x64（模拟） | Running |
| Amazon Inspector SSM Plugin | x64（模拟） | 已安装 |
| AWS CLI v2.35.5 | x64（模拟） | 可用 |
| ENA 网卡驱动 | ARM64 原生 | 正常 |
SSM Agent 没有 ARM64 原生版本，但通过 x64 模拟层正常工作。
不兼容场景
- 内核驱动：所有依赖内核驱动的 x64 软件不能工作。包括 x64 版 Sysmon 的驱动、x64 杀毒软件的实时监控驱动、x64 VPN 客户端的 TUN/TAP 驱动等。
- Hyper-V / WSL / Windows Sandbox：全部不可用。Graviton 不支持嵌套虚拟化。
- Coreinfo 数据不准确：x64 版 Coreinfo 报告的 CPU 拓扑和地址宽度可能与实际不符，应使用 ARM64 原生版 Coreinfo64a。
- 16-bit 程序：完全不支持（Windows 11 本身就不支持）。
实操建议
- 优先使用 ARM64 原生版工具（
*64a.exe），性能最佳、信息最准确。 - 只有 x64 版本的纯用户态程序可直接运行，模拟层兼容性很好。
- 安装 Sysmon 做安全监控必须用 ARM64 原生版，x64 版本内核驱动加载失败。
- SSM Agent 虽然是 x64 模拟运行，但功能完整，Send Command、Session Manager 都正常。
- 做性能基准测试时注意区分测试工具本身是原生还是模拟——模拟模式下测到的数据包含翻译开销。