Windows on Snapdragon X Elite: 71 of 85 running processes were ARM64 native

I started using the Surface Pro 11th Edition as my everyday machine on May 20, 2025, so more than a year has passed. ARM64 Windows is often described as still being full of emulation, so I counted what was actually running on my machine instead of relying on impressions. Experience alone gets pulled toward whichever heavy application happens to stand out.

As of August 2, 2026, 71 of the 85 running processes were ARM64 native. Eleven were x64 emulation and three were x86 emulation. That means 83.5% were running natively. The running set was more heavily ARM64-oriented than I expected.

The machine used for the measurement had a Snapdragon X Elite X1E80100 and 32 GB of memory. The OS was Windows 11 Pro 10.0.26200, ARM64 edition. These were conditions close to normal daily use.

Reading the PE header directly

I did not rely on Task Manager's Architecture column. I classified each executable by reading its PE header directly. Rather than trust Task Manager's presentation, I wanted to inspect the original file.

The PE header location is given by the value stored at byte 0x3C from the beginning of the file. Four bytes after that location is a 2-byte Machine field, and that value determines the architecture. The mapping is:

0xAA64 -> ARM64
0x8664 -> x64 (running under emulation)
0x014C -> x86 (running under emulation)

PowerShell reads it with BinaryReader.

$fs = [System.IO.File]::OpenRead($path)
$br = New-Object System.IO.BinaryReader($fs)
$fs.Seek(0x3C,'Begin') | Out-Null
$pe = $br.ReadInt32()
$fs.Seek($pe + 4,'Begin') | Out-Null
$machine = $br.ReadUInt16()

Among the items returned by Get-Process, I included only those with a Path and grouped them by process name. Some system processes could not be opened because of permissions, so I excluded them as indeterminate. I did not want to guess about processes I could not inspect.

What was native

The largest memory user was msedge at 4840.3 MB. Next was copilot at 1830.2 MB, followed by msedgewebview2 at 549.7 MB. The browsers being native fits my experience of the system feeling light. At least the layer I use most often was not an exception.

The development tools were all native as well: node at 392.7 MB, pwsh at 301.3 MB, python at 153.0 MB, and git at 15.5 MB. chrome was also on the native side at 309.6 MB. This lineup matched everyday behavior fairly well.

PowerToys was the surprise. Every module I could check - ColorPickerUI, ZoomIt, Awake, FancyZones, KeyboardManagerEngine, CropAndLock, Peek.UI, and AlwaysOnTop - was ARM64. I had expected small utilities to be left behind, so this was different from my expectation.

The 14 emulated processes

These were the entries remaining on the x64 side:

On the x86 side were node-runner at 82.7 MB, spacedeskServiceTray at 3.3 MB, and py at 1.0 MB.

This py entry was where I got stuck once.

Only the py launcher was x86

The python executable itself was under Python312-arm64 and was naturally ARM64. But Python's py.exe launcher was running as x86.

I normally invoke python directly, so I had not noticed. Only when I put #! at the beginning of a script and ran it through py did an emulation layer get inserted. That means losing a few tens of milliseconds on each launch. For small automations invoked repeatedly, this kind of fixed floor matters.

It took time to notice. I suspected Python, reviewed the environment variables, and only understood the issue after measuring the architecture. If I had reversed that order, it would have been a five-minute investigation. In hindsight, I wondered why I had not checked the Machine value of py.exe first.

What the count revealed

The emulated programs share a pattern. They are a Japanese chat application, peripheral-vendor utilities, an internal business tool, and an older launcher. None of their distributors provides an ARM64 build.

Conversely, the software distributed by Microsoft and Google appeared to be native almost without exception.

This may suggest that the boundary is not "ARM64 or not" but whether the software distributor is willing to support ARM64. With a sample of 85 processes on this machine, that boundary was clear.

Even among the 14 emulated processes, none caused noticeable trouble in daily use. LINE uses 447.1 MB and works normally; the Logitech utilities are only somewhat heavy, with no practical impact. Before seeing the details, I thought "14 are still left?" but the breakdown was understandable.

The script that performs the same count is at test machine specifications and measurement conditions. Your own environment will probably produce a different breakdown. After counting, checking only the x86 entries may uncover an unexpected resident process. On my machine, py was the one that stood out, which led me to review how it was launched.