You try to launch an application — maybe an old game, a custom tool, or something that came from an older Windows install — and instead of the window you expect, you get an error dialog with code 0XC0000249 and the text STATUS_IMAGE_MP_UP_MISMATCH. The app won't start at all. This usually happens right after moving a program folder or restoring files from a backup, not during a fresh install.
What's Actually Happening Here
The error code tells you exactly what's wrong: MP stands for multiprocessor, UP stands for uniprocessor. Windows is telling you that the executable or one of its DLLs was compiled for a uniprocessor system but is now running on a multiprocessor system — or vice versa. The critical thing to understand is that this isn't a compatibility setting you can toggle. It's baked into the binary's internal structure.
What's actually happening here is that the file in question was built as a uniprocessor hotpatch image — a special variant used by older Windows kernels for single-core systems. When Windows loads it on a multicore CPU (which is basically every modern PC), it sees the mismatch and refuses to run the image. The loader checks the IMAGE_FILE_UP_SYSTEM_ONLY flag in the PE header. If that flag is set and the system has more than one processor, you get this error.
This error is rare these days — it mostly shows up with legacy software or when you've moved an old Windows installation's system files into a newer OS. You might also trigger it by copying a .exe or .dll from a Windows NT 4.0 or early Windows 2000 install.
The Fix: Replace the Mismatched File
There's no registry key or group policy that fixes this. The only solution is to replace the offending file with a correct multiprocessor build. Here's how to find and replace it.
Step 1: Identify Which File Is the Problem
Windows will tell you in the error dialog — look at the top bar or the message body. It usually says something like "Filename.exe - Application Error" and includes the DLL or EXE name in the text. If the dialog doesn't show it clearly, check the Windows Event Viewer under Windows Logs > Application. Look for an event with ID 1000 or 1001 and search for the faulting module name.
Step 2: Check if the File Is Part of the System
If the file is something like KERNEL32.DLL, NTDLL.DLL, or another system DLL, you're looking at a system file corruption or a bad migration. Run this command as Administrator to repair system files:
sfc /scannowThen reboot. If it still fails, dism can fix the store:
dism /online /cleanup-image /restorehealthIf the file is a third-party DLL or EXE, move to the next step.
Step 3: Replace the Application File
For a third-party app, the correct multiprocessor version is almost certainly the one from a fresh install of the same software. Uninstall the app completely, then reinstall it from the original installer. If you don't have the installer, download it from the official source — not some random mirror.
If the app is a standalone executable that you copied from a backup, don't copy it back. Instead, find the original distribution archive (a ZIP, an ISO, a MSI) and extract a fresh copy. The reason step 3 works is that modern installers always use multiprocessor-safe binaries — the uniprocessor hotpatch builds died out around Windows 2000.
Step 4: If It's a Custom DLL From an Old Project
If you wrote the DLL yourself or it's from an open-source project, you need to recompile it with the /NXCOMPAT linker flag and without the /GS- flag that sometimes triggers this. In Visual Studio, check the project settings under Linker > Advanced and make sure Image Has Safe Exception Handlers is set properly. But honestly, the real fix is to just get a binary compiled for the right target.
What to Check If It Still Fails
If the error persists, you have one of two problems:
- You replaced the wrong file. The error might be caused by a dependency chain — app.exe loads a.dll, which loads b.dll, and b.dll is the one with the mismatch. Use Process Monitor to see which DLL fails to load. Filter on the process name and look for
NAME NOT FOUNDorPATH NOT FOUNDresults — though this error usually shows up as a successful open with a subsequent load failure. - The file is genuine but truly is a uniprocessor-only build. Some very old software (DOS-era stuff running under NTVDM or 16-bit Windows apps) simply cannot run on a multiprocessor system. In that case, your only option is to run the app inside a virtual machine running a single-core Windows version. VirtualBox or VMware with a single CPU assigned to the VM works.
Skip the idea of hex-editing the PE header — it's not just a flag, the actual code inside is written assuming single-core behavior. Changing the flag will crash the app in a more spectacular way. The only clean solution is the right binary.