How to Fix “The application was unable to start correctly (0xc000007b)” for Your Game

The dialog says the application was unable to start correctly and gives a hex code that players paste straight into a search engine. Nothing in your game ran; the Windows loader gave up while mapping a DLL into memory. The cause is a mismatch between what the executable is and what it tried to load, and once you know how to read an architecture off a file it is a five-minute fix. Here is how to find the offending library, what to change in the build, and the short list of things that fix it on the player’s side.

The exact error

MyGame.exe - Application Error
The application was unable to start correctly (0xc000007b). Click OK to close the application.

The code is the NTSTATUS value STATUS_INVALID_IMAGE_FORMAT. The loader found a file it was asked to load, so this is not a “DLL was not found” problem, but the file was not a valid image for this process. In practice that means wrong bitness, or occasionally a truncated or corrupted file.

What causes it

1. A 32-bit DLL next to a 64-bit executable, or the reverse. The usual suspects are SDK libraries you copied by hand: steam_api.dll instead of steam_api64.dll, an x86 FMOD, Wwise, Discord or OpenSSL build, a plug-in that only ships one architecture. The application folder is first in the DLL search order, so a wrong-bitness file there beats a correct one anywhere else.
2. A broken Visual C++ redistributable on the player’s machine. A partially installed or corrupted msvcp140.dll / vcruntime140.dll set in System32 or SysWOW64 produces the same code.
3. An injected DLL from other software. Overlays and capture tools (older RivaTuner and MSI Afterburner builds, some Discord and screen recorder versions) inject themselves into every game. When their hook library is the wrong bitness for your game, your game is what fails.
4. A truncated download or a file quarantined and partially restored by antivirus. A DLL cut off halfway is not a valid image either.
5. A stray DLL from a mod or a previous version left in the game folder, with the right name and the wrong architecture.

How to find the bad DLL

Open a Developer Command Prompt for Visual Studio in your build folder and print the machine type of the executable and every DLL beside it:

for %f in (*.exe *.dll) do @(echo %f & dumpbin /headers "%f" | findstr /C:"machine (")

8664 machine (x64) is 64-bit and 14C machine (x86) is 32-bit. Everything must match the executable. Do the same for subfolders your game loads from (Plugins, MonoBleedingEdge, Binaries). Without Visual Studio, the open-source Dependencies tool (the modern replacement for Dependency Walker) shows the same information in a tree, and highlights a mismatched module in red.

If every shipped file is consistent, the problem is on the player’s machine. Ask them for the list of modules loaded into the process at the time of failure: Event Viewer > Windows Logs > Application records an Application Error event naming the faulting module, and that module’s path tells you whether it came from your folder, from System32, or from somewhere like an overlay’s install directory.

Fix 1: ship matching libraries

Decide on one architecture per build and enforce it. Almost every PC game today should be 64-bit only; a 32-bit build invites exactly this class of bug and gains you nothing on modern hardware. Then:

• Pull native libraries from the SDK’s own x64 folder and never rename a 32-bit file to a 64-bit name to make a linker happy.
• In Unity, check each native plug-in’s Platform settings in the Inspector so the x86 copy is excluded from x86_64 builds. In Godot, confirm each GDExtension’s .gdextension file maps windows.x86_64 to the 64-bit binary. In GameMaker and Unreal, check the extension or plug-in’s folder for a second architecture you did not mean to package.
• Add a step to the build script that runs the dumpbin loop above and fails the build on any mismatch. It costs seconds and catches the SDK update that quietly swapped a file.

Fix 2: install the runtimes you depend on

Do not rely on the player already having the Visual C++ runtime. On Steam, add the redistributable to your depot and reference it from installscript.vdf so it installs silently on first launch; Steamworks has a shared common redistributable depot for this. For itch.io and direct downloads, either ship vc_redist.x64.exe in the zip with a one-line README, or use an installer that runs it. Static linking of the CRT (/MT) is also an option for a plain C++ game and removes the dependency entirely.

Make sure the runtime you install matches the one you built against. A game compiled with Visual Studio 2022 wants the 2015–2022 unified redistributable; an older SDK you ship might still want the 2013 one, and both can coexist.

Fix 3: what to tell players

A short, ordered list, in the store FAQ and support replies:

1. Verify the game files (Steam: Properties > Installed Files > Verify integrity) or re-extract the download, and restore anything the antivirus quarantined.
2. Reinstall the Visual C++ 2015–2022 redistributable, both the x64 and x86 packages, from Microsoft’s site. Repair rather than skip if it says it is already installed.
3. Disable overlays and capture tools (RivaTuner, Afterburner, Discord overlay, recording software) and try again. If that fixes it, update the tool.
4. Install pending Windows updates and the GPU driver.

Avoid telling players to download individual DLLs from the web. Those sites are a common source of the wrong-bitness file that caused the problem, and of worse.

How to confirm it works

Test the shipped build on a clean Windows virtual machine with no Visual Studio, no SDKs and no redistributables installed. That is the only machine that looks like a player’s. If it launches there, the libraries and runtimes are self-contained. Keep a snapshot of that VM and reuse it for every release; a developer PC has every runtime ever made and will never reproduce this.

Seeing which players hit it

The loader fails before your process exists, so the game cannot report this one itself, but the follow-on is visible: the player who clicks OK, tries a workaround and then crashes in a different way five minutes later. Bugnet’s Unity, Godot and Unreal SDKs attach the OS build, GPU and loaded-module context to every crash they file, and a public tracker entry for “0xc000007b on launch” with the four steps above gives players something to find before they ask for a refund.

Related problems

• How to Fix “MSVCP140.dll was not found” Errors for Your Game’s Players
• How to Fix “VCRUNTIME140.dll was not found” for Your Game
• How to Fix “xinput1_3.dll is missing” Controller DLL Errors for Your Game
• How to Fix “UnityPlayer.dll was not found” for Your Unity Game
• Unity Game Won’t Launch on a Player’s PC? How to Fix It

Frequently asked questions

What does error 0xc000007b mean?

It is STATUS_INVALID_IMAGE_FORMAT. Windows found a DLL the game needs but could not load it into the process, almost always because the DLL is 32-bit and the game is 64-bit or vice versa, or because the file is corrupted.

How do I check whether a DLL is 32-bit or 64-bit?

Run dumpbin /headers on the file from a Visual Studio Developer Command Prompt and look at the machine line: 8664 is x64 and 14C is x86. The free Dependencies tool shows the same thing graphically.

Why does the game work on my PC but fail with 0xc000007b for players?

A development machine has every Visual C++ runtime and SDK installed, so a missing or mismatched library is often resolved from a system path. A player’s machine only has what you shipped. Test on a clean virtual machine to see what they see.

Can an overlay cause 0xc000007b?

Yes. Overlay and capture tools inject a DLL into every game they see. If that DLL does not match the game’s architecture, or the tool is out of date, the game fails to start with this code. Disabling the overlay confirms it.

The machine that can reproduce a launch failure is the one with nothing installed on it. Keep a clean VM snapshot and launch every release there first.