Windows: The application was unable to start correctly (0xc000007b)

Hi, it's BlueByte. You double-click an app and Windows answers with a box titled The application was unable to start correctly (0xc000007b) and a single OK button that just closes it. Nothing launches. The code looks cryptic, but Windows is being specific: 0xc000007b is the NTSTATUS value STATUS_INVALID_IMAGE_FORMAT, which Microsoft documents as {Bad Image} ... is either not designed to run on Windows or it contains an error. We'll walk through what that means, how to find the actual bad file, fix it per cause with commands you can run, and keep it from happening to the next app.

What "unable to start correctly (0xc000007b)" actually means

The dialog usually names the app, and it's sometimes preceded by a separate Bad Image dialog that names a specific .dll:

The application was unable to start correctly (0xc000007b).
Click OK to close the application.

Under the hood, the Windows loader tried to map an executable or DLL into memory and found the image format invalid for this process. In practice that is almost always an architecture (bitness) mismatch: a 32-bit process tried to load a 64-bit DLL, or the reverse. The image is a real file — it's just the wrong shape for the process loading it.

Why a bitness mismatch is the usual culprit

The invalid-image error comes from one of a few concrete causes:

• A wrong-bitness DLL — the most common by far: a 32-bit app finds a 64-bit copy of a DLL (on its PATH or in its own folder), or a 64-bit app finds a 32-bit one. The loader rejects the format.
• A missing or outdated Visual C++ Redistributable — the app needs the MSVC runtime and the matching-architecture redist isn't installed.
• Corrupted system files — a system DLL was damaged, so a valid app ends up loading an invalid image.
• A corrupt or half-copied app install — a DLL was truncated during copy.
• Rarer: a missing DirectX or .NET component an older game expects.

Confirm whether the app is 32- or 64-bit

Find the bad file before you start changing things. If a Bad Image dialog named a .dll, that is your suspect. Otherwise, open Event Viewer and read the Application log:

eventvwr.msc  →  Windows Logs  →  Application

The matching Application Error entry names the faulting module — the DLL whose image was invalid. For the app's own bitness, the install folder is a strong hint: 32-bit apps normally live under C:\Program Files (x86), 64-bit apps under C:\Program Files. Match that against the faulting DLL: a 32-bit app pulling in a 64-bit DLL (or vice versa) is the mismatch the error is complaining about.

Install the matching Visual C++ Redistributable

This is the highest-yield fix. Because 64-bit Windows runs both 32- and 64-bit apps, install both architectures — the x86 redist for 32-bit apps and the x64 redist for 64-bit apps. Microsoft's permalinks always point at the latest v14, which covers apps built with Visual Studio 2015 through 2026:

x86: https://aka.ms/vc14/vc_redist.x86.exe
x64: https://aka.ms/vc14/vc_redist.x64.exe

Run them silently if you prefer:

.\vc_redist.x64.exe /install /quiet /norestart
.\vc_redist.x86.exe /install /quiet /norestart

Microsoft's docs are explicit that the redistributable architecture must match the app's architecture, and a 64-bit machine commonly needs both installed side by side. Reboot, then relaunch the app.

Repair corrupted system files with SFC and DISM

If a system DLL is the bad image, repair the component store first, then the files. Microsoft's own guidance is to use sfc /scannow for a quick check and DISM /Cleanup-Image for a deeper one. From an elevated command prompt:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

You'll see output close to this:

[==========================100.0%==========================]
The restore operation completed successfully.
...
Windows Resource Protection found corrupt files and successfully repaired them.

Run DISM first — it repairs the store that SFC pulls its known-good files from — then SFC. If DISM can't reach Windows Update for source files, add a /Source: argument as described in Microsoft's Repair a Windows image guide.

Reinstall the app or restore the right-bitness DLL

If Event Viewer named a DLL that ships with the app, that copy is corrupt or wrong-bitness — reinstall the app cleanly: uninstall it, delete the leftover folder, and reinstall from the original download or media. If the named DLL is a shared one that someone hand-copied into C:\Windows\System32 or the app folder, remove that stray copy so the loader falls back to the correct one.

A 32-bit game that won't launch, walked end to end

An old 32-bit game threw 0xc000007b on launch, with a Bad Image dialog naming xinput1_3.dll. Event Viewer's Application Error confirmed xinput1_3.dll as the faulting module. The game folder held a 64-bit copy of that DLL that someone had pasted in to fix an earlier "missing dll" popup. Installing both Visual C++ redists changed nothing; deleting the stray 64-bit xinput1_3.dll from the game folder let the game launch, because Windows then fell back to the correct system copy. The root cause was a bitness mismatch from a hand-copied DLL.

Check it launches and stop it recurring

Verify the fix by launching the app and confirming no new Application Error appears in Event Viewer. To prevent a repeat: keep both Visual C++ redists current, never hand-copy DLLs between folders to silence a missing-dll popup, and install apps from the vendor rather than random DLL-download sites — those are a frequent source of wrong-bitness files.

How it differs from 0xc0000135 and 0x80070005

0xc0000135 (STATUS_DLL_NOT_FOUND) means a required DLL is missing entirely — usually a missing .NET or runtime, not a bitness mismatch. 0x80070005 is ACCESS_DENIED — a permissions problem, not a bad image. 0xc000007b specifically means the image format is invalid, which points at architecture or corruption, not absence or permissions.