What's happening
You double-click an executable and immediately get:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
Error code 0xc000007b maps to STATUS_INVALID_IMAGE_FORMAT in the Windows NT kernel. Translation: a 32-bit application tried to load a 64-bit DLL (or the other way around). This is an architecture mismatch — the DLL exists on disk, but Windows flat-out refuses to load it because the bitness is wrong.
Worth emphasizing: this is not a "DLL not found" error. The file is there. It just can't be used by that process. That distinction matters when picking your fix.
Step 1 — Find the offending DLL before touching anything
Randomly reinstalling things wastes time. Spend two minutes identifying which DLL is the culprit first. Process Monitor (Sysinternals) and Dependency Walker both work well for this — filter on the process name and look for failed load events.
No third-party tools? Use the built-in where command to see which DLL path Windows resolves:
where msvcp140.dll
where vcruntime140.dll
where msvcr120.dll
Finding results in both C:\Windows\SysWOW64\ and C:\Windows\System32\ is completely normal — that's how Windows handles 32-bit and 64-bit side-by-side. The problem is when a 32-bit app accidentally picks up the 64-bit variant. This usually happens when someone dropped a DLL directly into the application folder with the wrong bitness.
To check a DLL's architecture directly, paste this into PowerShell:
$bytes = [System.IO.File]::ReadAllBytes('C:\Windows\System32\msvcp140.dll')
$peOffset = [System.BitConverter]::ToInt32($bytes, 0x3C)
$machine = [System.BitConverter]::ToUInt16($bytes, $peOffset + 4)
if ($machine -eq 0x8664) { "64-bit" } elseif ($machine -eq 0x14c) { "32-bit" } else { "Unknown: $machine" }
Swap in whatever DLL you suspect. A 32-bit app needs 0x14c (x86). If you're getting 0x8664 (x64), that's your mismatch.
Step 2 — Delete stray DLLs from the application folder
Some installers bundle runtime DLLs alongside the executable. When those bundled copies are the wrong architecture, they shadow the correct system DLLs — and the app breaks.
dir "C:\path\to\your\app\*.dll"
If you spot files like msvcp140.dll, vcruntime140.dll, or msvcp_win.dll sitting next to the .exe, check their bitness using the PowerShell snippet above. Wrong architecture? Delete them. The application will fall back to the correct system copies in System32 or SysWOW64.
Step 3 — Reinstall Visual C++ Redistributables (x86 and x64 both)
This fixes the problem in roughly 70% of cases. Applications written in C++ need the MSVC runtime to be installed — and if the right variant is corrupted or missing, 0xc000007b appears.
Search Microsoft's site for "Microsoft Visual C++ Redistributable latest" and download:
- Visual C++ 2015-2022 Redistributable — x86 (32-bit apps need this even on 64-bit Windows)
- Visual C++ 2015-2022 Redistributable — x64
- Older apps may also need the 2013 and 2012 versions
Install the x86 version regardless of your Windows edition. Most games and older desktop software ship as 32-bit and pull from SysWOW64, not System32. Skipping x86 is a common mistake.
After installing, reboot — then verify what's actually installed:
Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*Visual C++*" } | Select-Object Name, Version | Sort-Object Name
Step 4 — Repair Windows system files with SFC and DISM
Corrupted Windows system DLLs won't be fixed by reinstalling redistributables. If msvcp140.dll itself is damaged inside System32, no installer will touch it. Run these as Administrator:
# Step 1: System File Checker
sfc /scannow
# Step 2: If SFC reports unfixable errors, repair the component store first
DISM /Online /Cleanup-Image /RestoreHealth
# Step 3: Run SFC again after DISM finishes
sfc /scannow
Expect this to take 10–20 minutes depending on disk speed. The message "Windows Resource Protection found corrupt files and repaired them" means it worked — reboot and test your app.
Step 5 — Confirm the executable's own architecture
Occasionally the fix is just running the right version of the application. If a vendor ships both a 32-bit and 64-bit installer, installing the wrong one causes exactly this error.
$bytes = [System.IO.File]::ReadAllBytes('C:\path\to\app.exe')
$peOffset = [System.BitConverter]::ToInt32($bytes, 0x3C)
$machine = [System.BitConverter]::ToUInt16($bytes, $peOffset + 4)
if ($machine -eq 0x8664) { "64-bit EXE" } elseif ($machine -eq 0x14c) { "32-bit EXE" } else { "Unknown" }
Got a 32-bit EXE when you needed 64-bit? Uninstall, grab the correct installer from the vendor, and start fresh.
Step 6 — .NET Framework repair (for .NET-based apps only)
A smaller percentage of 0xc000007b errors come from corrupted .NET installations rather than MSVC. If the app is .NET-based — you'll usually see this in its documentation or the installer — download the Microsoft .NET Framework Repair Tool from Microsoft's site and run it. It handles the most common .NET corruption scenarios without manual intervention.
Verification
After any of the above fixes:
- Reboot. Non-negotiable — DLLs loaded in memory won't be refreshed otherwise.
- Launch the application normally.
- Still broken? Open Event Viewer → Windows Logs → Application. Find the error entry. The detail pane usually names the specific DLL that refused to load — that gives you a concrete next target.
# Pull recent 0xc000007b errors from Event Viewer
Get-EventLog -LogName Application -EntryType Error -Newest 20 | Where-Object { $_.Message -like "*0xc000007b*" -or $_.Source -eq "Application Error" } | Format-List TimeGenerated, Message
Quick reference: fixes ranked by likelihood
- Most common (~70%): Reinstall Visual C++ Redistributables — x86 + x64, 2015-2022
- Second most common: Delete stray DLLs from the application folder
- Corrupted system files: Run
DISM /RestoreHealth, thensfc /scannow - .NET apps specifically: Run the .NET Framework Repair Tool
- Last resort: Uninstall cleanly, then reinstall the application
Why does this keep happening?
Almost every case traces back to one of four scenarios:
- A software update swapped a 64-bit system DLL with a 32-bit one (or the reverse)
- An installer bundled wrong-architecture DLLs next to the executable
- Antivirus quarantined or modified a runtime DLL — silently, without telling you
- A partial uninstall left corrupted DLL fragments that now take precedence over clean system copies
If you ship applications: never bundle msvcp*.dll or vcruntime*.dll in your application folder unless you've explicitly verified they match your build target. Use the official MSVC Redistributable merge modules or the standalone installer — that's what they're for.