Yeah, this one's annoying because it pops up out of nowhere and the message tells you nothing useful. Let's cut to it.
The Fix (90% of cases)
What's actually happening here is that a C runtime function — usually memcpy, strcpy, or printf — received an argument that violates its contract. The OS catches it, raises this exception, and the process dies. The most common trigger is a corrupted or mismatched Visual C++ Redistributable package, not your code or your system.
- Uninstall all Visual C++ Redistributable packages — go to Apps & Features, search for "Visual C++", and remove every entry from 2005 through 2022. Don't skip the old ones.
- Reboot — yes, really. Some DLLs stay locked in memory.
- Download the latest supported runtime from Microsoft's official site:
vc_redist.x64.exeandvc_redist.x86.exe(both, even on 64-bit Windows — you'd be surprised how many 32-bit apps depend on the x86 runtime). - Install both, running as Administrator.
- Reinstall the program that crashed. Not repair — full uninstall, then fresh install. The installer will link against the fresh runtime.
Test it. If it still crashes, move to the next section.
Why This Works
Here's the thing about C runtime errors: the function signature hasn't changed, but the parameter validation internal to the CRT has gotten stricter over the years. When a program was built against an older runtime and then runs against a newer one, the new runtime might reject something the old one tolerated. For example, passing a null pointer to strlen used to just segfault; now the runtime raises this structured exception with a clear code.
Reinstalling the runtime forces the program to load the exact version it expects, and reinstalling the app cleans up any stale DLLs it may have dumped into its own folder. The reason step 3 works is that a mismatch between msvcp140.dll (C++ runtime) and ucrtbase.dll (Universal C Runtime) is a frequent culprit, and Microsoft bundles both in the latest redistributable.
Less Common Variations
If reinstalling doesn't fix it, you're in the other 10%. Here's what else can cause this:
1. Outdated GPU drivers
Yes, seriously. Some game engines pass a bad parameter to a runtime function when the GPU driver returns an unexpected error. Update your GPU driver from the manufacturer's site, not Windows Update.
2. Corrupted system files
Run these in an elevated command prompt:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealthThis isn't the first thing to try, but if you've had a recent blue screen or power loss, corrupted system files can cause this exact error.
3. Antivirus interference
Some aggressive antivirus hooks into process creation and can corrupt the stack before the CRT initializes. Temporarily disable your AV and test. If it stops crashing, whitelist the program folder.
4. A bug in the application itself
If the app is open-source or you can see its logs, look for a stack trace. If it points to a specific function call, the developer introduced a bug. Check for an update or a community patch. Don't waste time trying to hack around it.
Prevention
- Always install both x86 and x64 redistributables after a fresh Windows install. The x86 one isn't optional — tons of installers and utilities still ship as 32-bit.
- Prefer portable apps that bundle their runtime instead of relying on system-wide DLLs. They can still break, but less often.
- When updating Windows, do the optional updates too — the Universal C Runtime updates come through there.
- If you're a developer, link against the static CRT (
/MT) for small utilities. It eliminates the runtime dependency entirely. For larger apps, keep your build machine's redistributable up to date and test on a clean VM.
That last one is the real fix for developers: static linking means you're shipping your own runtime, so nothing external can mismatch it. For everyone else, the redistributable reinstall handles the vast majority of these crashes.