The build server came back up after Patch Tuesday and half the toolchain stopped loading. Not a compile error. Not a missing dependency. Just a small modal from Windows with one line: The application was unable to start correctly (0xc000007b). Click OK to close the application.
Every machine that had picked up the 24H2 update showed the same thing. Every machine still sitting on 23H2 was fine. That pattern is the whole story, and it points at the cause before you touch anything: a Visual C++ runtime that Windows no longer lays down the way it used to, and an executable that expects the old layout.
0xc000007b is a status code, not a bug. It stands for STATUS_INVALID_IMAGE_FORMAT, which means the loader tried to map a binary and found something it could not reconcile, most often a 32 bit image pulled into a 64 bit process or the reverse. When a new OS build changes how the side by side runtime store is assembled, an old app or an old helper DLL that hard-links against a specific redistributable can fail this check without anything being visibly wrong with the file itself.
Confirm it is the runtime and not something else
Fastest way to stop guessing is to read what the process actually needs. Open an elevated command prompt and run:
where msvcp140.dll
where vcruntime140.dll
where vcruntime140_1.dllYou want matches under System32, plus any private copies that shipped alongside the executable. If the only hits are inside the app folder, the app is carrying its own runtime and the system store is not the problem. If System32 returns a vcruntime140_1.dll but not the base pair, you have a partial runtime, which is exactly the shape 0xc000007b tends to take after an in place upgrade.
Then check the binary itself. Sysinternals depends.exe is old and ugly but still the fastest reader for import tables. Point it at the failing exe and look for a red entry. It will usually be one of the 2015 to 2022 runtimes, sometimes a version that predates the current one by a couple of service packs. That name is your repair target.
The actual fix, in the order that works
- Install the current Visual C++ Redistributable for both architectures. Microsoft ships x86 and x64 as separate packages, and a 64 bit app can still load a 32 bit plugin. Install both. Do not uninstall the older ones first, the side by side store is designed to hold several at once and removing them breaks other apps.
- Repair rather than reinstall where you can. Settings, Apps, Installed apps, find the runtime entry, open the three dot menu and choose Modify, then Repair. This rewrites the files under WinSxS without touching the version key.
- Reboot before testing. Not a fast startup shutdown, a real restart. The runtime store is loaded early and a shell restart will not pick up the new files.
- If the app still fails, check for a private copy. Some installers drop their own msvcp140.dll into the program directory. Delete it and let the loader fall back to System32. Keep a copy in case the vendor insists on it.
- Rerun the app. If the error code changes, you fixed the 32 bit layer and hit a second problem. That is progress. Chase the new code, usually 0xc0000135, which is a missing DLL the manifest expects.
If step one fails because the installer itself throws a different error, run it from a clean shell with the Windows Installer service restarted. net stop msiserver then net start msiserver. That sounds superstitious. It is not. Pending installer transactions from the update are a real cause of redistributable installs silently doing nothing.
Why 24H2 makes this worse than previous builds
We have seen the same pattern after other releases. The in place upgrade leaves the old side by side folders in place but updates the loader’s resolution rules. Apps that pinned a specific runtime version through an application manifest keep asking for it, and if the upgrade moved that version out of the active resolution order, the load fails. The file is still on disk. The loader no longer looks there.
It is worth reading the Microsoft.VC142.CRT and Microsoft.VC143.CRT folders under WinSxS and confirming the one your app asks for is present. If it is present and the app still fails, the manifest is pointing at a version that the loader has decided to retire. The clean fix then is a fresh redistributable from Microsoft, because the current package carries forward the older version folders as well as the new ones.
Microsoft has been public about update regressions in this cycle. The Always On VPN break reported against the September 2026 security updates is the same category of problem, a change in the update that reaches further than the component it was meant to patch. The runtime issue is quieter because most users only notice it when an app refuses to launch, not when something stops working across the network.
If you are repairing a build machine
Install the redistributables once, then audit. A quick PowerShell pass over the usual suspects saves a week of one at a time fixes:
Get-ChildItem -Path C:\ -Recurse -Filter "vcruntime140*.dll" -ErrorAction SilentlyContinue |
Select-Object FullName, VersionInfoAnything outside System32 and outside a known vendor program folder is a private copy that will cause this error again the moment the system store changes. Patching those out of the project is worth more than any runtime reinstall.
One more thing we would stop doing. Registry cleaners and all in one cleanup tools offered as a fix for this error are the wrong tool. The runtime problem lives in WinSxS and the manifest, and those tools do not touch either. They will delete temp files and give you a progress bar. The error code comes back.
For the toolchain side, the same pattern holds. If your IDE starts throwing 0xc000007b after a Windows build change, and it bundles its own JetBrains Runtime or bundled JRE, check that folder for private msvcp140.dll copies before you reinstall the IDE. Nine times out of ten the reinstall pulls the same private runtime and the problem survives. Replacing the runtime next to the exe with the current redistributable is the smaller, faster move.
Final check we run every time. Open a fresh command prompt and start the failing executable from there rather than from the Start menu. If it launches, the shortcut is the problem. If it fails with the same code, the loader is. That distinction saves an evening of pointing at the wrong thing.