Fix 0x000002D0 ERROR_IMAGE_MACHINE_TYPE_MISMATCH_EXE

Stop code 0x000002D0 (ERROR_IMAGE_MACHINE_TYPE_MISMATCH_EXE) shows up when the kernel tries to load an executable image and the PE header's machine type doesn't match what the CPU can actually run. What's actually happening here is that Windows has already read the file into memory, passed the header check inside nt!MiVerifyImageHeader, and then realized the IMAGE_FILE_HEADER.Machine field says i386 (0x14c) while the CPU is reporting AMD64 (0x8664), or vice versa. The loader can't map it, so it bugchecks.

This is not a corruption error. It's not a RAM problem. It's the kernel saying "you handed me a binary I can't decode." You have three likely culprits. I'll go through them in order of how often I've seen them in the wild.

Cause 1: A 32-bit kernel driver or service binary on 64-bit Windows

This is the big one. On 64-bit Windows, user-mode 32-bit apps run fine through WOW64 — that's the whole point of the WOW64 layer. But kernel-mode code has no WOW64 equivalent. A 64-bit kernel cannot load a 32-bit .sys driver, period. If a service or driver tries anyway, you get 0x2D0 on the next boot or the moment the service starts.

A very common real-world trigger: someone copies an old driver from a Windows XP x86 machine onto a Windows 11 x64 box because "the vendor's new driver is broken." Or a legacy backup agent (older versions of a few well-known ones) ships a 32-bit filter driver that gets registered as a boot-start service. The machine posts, loads the driver, and bluescreens before the login screen appears.

The fix is to find the binary and replace or remove it. Boot into Safe Mode (hold Shift while clicking Restart, or press F8 on older builds), then:

driverquery /v /fo csv | findstr /i "32-bit"

:: Or check a specific driver's PE header
powershell -Command "$b=[IO.File]::ReadAllBytes('C:\\Windows\\System32\\drivers\\suspect.sys'); [BitConverter]::ToUInt16($b, 0x3C) -join ''"

Cleaner: use dumpbin /headers from a Visual Studio install, or the free Dependencies tool (the modern Dependency Walker). Look at the Machine field. 14C = x86. 8664 = x64. AA64 = ARM64. If a boot-critical driver shows 14C on an x64 system, that's your bugcheck.

Remove the service with sc delete <name> and reboot. If the vendor claims "it works on Windows 10 too," they mean 32-bit Windows 10.

Cause 2: Running an ARM64 or x64 binary on the wrong architecture (mainly Windows on ARM)

Windows on ARM (Snapdragon X Elite laptops, Surface Pro X, etc.) is where this gets interesting. ARM64 Windows can run x64 code via emulation, and ARM64EC lets developers mix native ARM64 and emulated x64 in one process. But that emulation is user-mode only. Kernel drivers are ARM64 only.

I've seen 0x2D0 on Snapdragon laptops after someone installs a printer or VPN driver that only ships x64 .sys files. The installer happily copies them to System32\drivers, the service registers, reboot, blue screen. Same story on the reverse side: someone pulls an ARM64 driver from a Surface and tries to use it on an Intel machine.

Fix:

1. Boot to WinRE. Shift + Restart, then Troubleshoot → Advanced → Command Prompt.
2. Find the offending driver. The crash dump's stack usually names it, but if you can't read the dump, look at recently-added services:

reg load HKLM\TEMP_SYS C:\Windows\System32\config\SYSTEM
reg query HKLM\TEMP_SYS\ControlSet001\Services /s /v ImagePath | findstr /i drivers

3. Delete the service key or rename the .sys file to .bak, then reboot.

On ARM64 Windows specifically, check the vendor's download page for an explicit "ARM64" or "Windows on ARM" build. If there isn't one, the driver won't work. No compatibility shim exists for kernel code.

Cause 3: Corrupted or tampered PE header (misdirection)

This one is rarer but worth ruling out. If a disk sector goes bad right where the PE header lives, or if malware patches the Machine field (some old packers did this to confuse analysis tools), Windows sees garbage in the header and throws the same bugcheck. The binary itself might actually be the right architecture, but the header says otherwise.

The tell: the crash happens with a file you've been running for months, no driver updates, no new software. Run sfc /scannow from an elevated prompt. If it flags a system file, replace it from a known-good source. If it's a third-party binary, download a fresh copy and compare hashes:

certutil -hashfile "C:\path\to\file.sys" SHA256
:: Compare against vendor's published hash

Also scan for rootkits. A handful of bootkits patch PE headers at load time to evade signature checks. sfc won't catch those because they're not on disk. If you've ruled out the architecture mismatch and the file hash is clean, run a proper offline scan (Microsoft Defender Offline, or a Kaspersky Rescue Disk boot).

Reading the crash dump (worth 5 minutes)

If you have a minidump in C:\Windows\Minidump, load it in WinDbg and run:

!analyze -v
lm v

The !analyze -v output names the module that failed to map. The lm v (list modules verbose) output shows every loaded module's machine type. Look for one that stands out — a single 14C in a sea of 8664, or vice versa. That's your culprit, and you don't have to guess.

Quick reference

The single most useful thing you can do is read the dump. 0x2D0 always names the binary in the stack. Guessing which driver is at fault wastes an afternoon; WinDbg tells you in under a minute.