Side-by-Side Configuration Incorrect: Fix on Windows 11/10

"The application has failed to start because its side-by-side configuration is incorrect" almost always means the same kind of thing: a Visual C++ runtime the program depends on is missing or mismatched, not that the program, the download, or your PC is broken. The fastest fix is reinstalling the correct Visual C++ Redistributable — both the x86 and x64 builds, from Microsoft directly — which clears it for most people in under five minutes. If it doesn't, the real fault sits in Windows' own component store, and DISM plus sfc /scannow repair that instead. What this page is really about is the wrong turns that waste an hour before someone finds either of those — and how to skip straight past them.

Jake's Saturday went like this: a customer dropped off a laptop at 10am with a game refusing to launch, throwing the side-by-side error, and asked if it could be ready by closing. Jake's first move — reasonable, and wrong — was uninstalling and reinstalling the game. Forty minutes gone. Second move: a factory-reset suggestion the customer wisely declined, since it would have wiped a school project on the desktop. By 11:30, with nothing fixed and a customer starting to look for reasons to walk, Jake finally called Ethan.

"You spent forty minutes solving the wrong problem," Ethan said. "This error has almost nothing to do with the game. It's a missing runtime file. The actual fix takes about four minutes, and you already had every tool you needed."

What this error actually costs, if you fix it the wrong way

The reason this error is worth a page of its own isn't that it's hard — it's that almost everyone's first instinct is expensive and wrong. Here's what the wrong turns actually cost, in time you don't get back:

The gap between row one and row four is the entire point of this page. Jake's forty minutes weren't a fluke — they're the default outcome of treating a runtime-component error as a program error, the classic misdiagnosis this error produces.

There's a cost the table doesn't capture: what happens to the customer while the wrong fix is running. A reinstall that takes forty minutes and doesn't work reads to a customer as "this shop doesn't actually know what's wrong," even when the underlying diagnosis effort was genuine. A four-minute fix, by contrast, reads as expertise — not because it's dramatic, but because it's fast and it's right the first time. That gap in perceived competence is worth more to a repeat-business shop than the minutes saved on the clock.

Why the error message doesn't point you at the actual fix

"Side-by-side" (SxS, or WinSxS) is the Windows system that lets multiple versions of the same shared code — a DLL — live on one PC at once without one overwriting another. Before this existed, installing a newer program could quietly replace a file an older program relied on, breaking it: common enough in the Windows 98/XP era to earn its own name, "DLL hell."

Microsoft's fix is the WinSxS folder at C:\Windows\WinSxS (never worth editing by hand). Every program that needs a shared component ships a small XML manifest embedded in its .exe, listing exactly which version, architecture, and cryptographic "public key token" it expects. Windows checks that manifest against what's registered in WinSxS at launch. "Side by side configuration is incorrect" means that check failed — the exact version and architecture the manifest demands isn't registered. The classic, manifest-based form of this message traces back to the older 2005 and 2008-era runtimes, whose C runtime files lived in WinSxS behind exactly these strict manifests; a missing modern 14.x runtime usually announces itself with a different message instead ("VCRUNTIME140.dll was not found"). Either way, the cause is the same family — the matching Visual C++ Redistributable was never installed, got removed by a cleanup tool, or was left half-installed by an interrupted update — and reinstalling the redistributables is the standard first fix in both cases.

None of that involves the game, the installer, or your download being broken — which is exactly why reinstalling any of those doesn't touch the actual cause, and why it's the costliest wrong turn on the table above.

The under-five-minute fix, on Windows 11

Windows 11 24H2 and 25H2 use identical steps here — nothing about this process changed between builds.

Step 1 — remove the existing redistributables first

Open Settings > Apps > Installed apps, search visual c++, and you'll likely see several entries: "Microsoft Visual C++ 2015-2022 Redistributable (x64)," an (x86) counterpart, and possibly older 2013–2005 entries. That's expected — different programs target different years. Uninstall each via the three-dot menu, rather than installing over a possibly half-broken copy, since a broken existing install is a common reason Step 2 doesn't fully take.

Step 2 — reinstall both architectures from Microsoft

Get the current package straight from Microsoft's permanent links: aka.ms/vc14/vc_redist.x64.exe and aka.ms/vc14/vc_redist.x86.exe. Microsoft now brands this download the Visual C++ v14 Redistributable, one package covering software built with Visual Studio 2017 through 2026 (Visual Studio 2015 itself has aged into legacy, unsupported territory). Don't let the naming throw you: the download page says v14, but once installed it appears in Installed apps under the older name "Microsoft Visual C++ 2015-2022 Redistributable" — same runtime family, rebranded — which is exactly what Step 1 had you uninstall. Install both x86 and x64, even on a fully 64-bit PC — this is the step people skip, and skipping it is why the "quick fix" sometimes doesn't stick. A 64-bit Windows install still runs plenty of 32-bit software, which needs the x86 runtime specifically. If the failing program is genuinely old — built before 2015 — you may separately need a matching older package, since a newer redistributable doesn't retroactively satisfy an older manifest request.

Restart before testing. A restart costs nothing, and it occasionally clears the error on its own once the correct component is registered.

Step 3 — if it's still failing, the store itself needs repair

When the redistributable reinstall doesn't clear it, or several unrelated programs are throwing the same error, the WinSxS component store is the more likely fault — not any single app's manifest. This costs more time (ten to twenty minutes, mostly unattended) but it's still far cheaper than a reset.

Right-click Start, choose Terminal (Admin), and run:

DISM /Online /Cleanup-Image /RestoreHealth

This needs an internet connection — it pulls clean replacement files from Windows Update to patch whatever DISM finds damaged. Let it finish; stopping partway can leave things worse. Once it reports success, run:

sfc /scannow

which checks protected system files against known-good copies, drawing on the store DISM just fixed. Running sfc before DISM is the common ordering mistake: if the store is damaged, sfc has nothing clean to pull from and reports success while the problem remains. Restart once both finish.

Step 4 — rule out a wrong-architecture install

Occasionally the cost isn't a missing component but a wrong one: the installer put the wrong-architecture build on the PC. This shows up most on Arm-based Snapdragon Copilot+ PCs, where x86 programs run under Windows' built-in x86 emulation, and an oddly-packaged older installer can get confused about which runtime it should be asking for. On an Arm PC, grab the ARM64 redistributable as well — aka.ms/vc14/vc_redist.arm64.exe — alongside the x86 and x64 builds; the current x64 package actually bundles ARM64 binaries too, which is why Step 2's install-both advice carries over to Arm machines intact. If Steps 1–3 haven't helped on an Arm-based PC, also check whether the software offers a native Arm64 build.

Step 5 — find the exact missing piece with sxstrace, if you need certainty

If Step 2 didn't help and you don't want to guess which older redistributable year to try next, Windows ships a built-in diagnostic: sxstrace.exe. It costs a few extra minutes but replaces guesswork with a definite answer.

From an elevated Terminal: sxstrace trace -logfile:sxstrace.etl, then launch the failing program so it errors again while tracing. Press Ctrl + C to stop, then run sxstrace parse -logfile:sxstrace.etl -outfile:sxstrace.txt. Look for "Resolve Partial Assembly" near the bottom — it names the exact assembly and version Windows couldn't find.

The right-click trap that costs its own few minutes

While doing any of the above: Windows 11's right-click menu is condensed, so "Run as administrator" or "Uninstall" sometimes aren't visible on the first menu. Click Show more options (or Shift+F10) rather than assuming the option doesn't exist.

The same fix on Windows 10

Every step above costs the same amount of time on Windows 10 — WinSxS, DISM, SFC, and sxstrace are the same tools on both operating systems. Only where you go to uninstall and reinstall software differs.

Open Settings > Apps > Apps & features, or the classic Control Panel > Programs > Programs and Features — both routes list the same entries, so use whichever you reach first. Uninstall each Visual C++ Redistributable entry, then reinstall the current v14 package from the same aka.ms/vc14 links as Step 2, plus any older year needed — both x86 and x64, always. For the DISM and SFC repair, right-click Start and choose Windows PowerShell (Admin) — that's the label Windows 10 shows by default — and run the same two commands in the same order; they work identically in PowerShell.

If it's your own compiled program: a different bill entirely

If your own .exe runs fine on your development machine but fails with this exact error for a colleague or on a clean test VM, the cost isn't a missing redistributable on their end — it's a design choice on yours. Your program almost certainly links the Visual C++ runtime dynamically rather than statically, and the test machine has no Visual Studio installation to supply that runtime.

Two genuine fixes: ship the matching Visual C++ Redistributable installer alongside your program, or in Visual Studio go to Project Properties > C/C++ > Code Generation > Runtime Library and switch Multi-threaded DLL (/MD) to Multi-threaded (/MT) to statically link the runtime into your .exe. Static linking costs binary size but removes the dependency entirely — fine for a single portable tool, wasteful for a larger app where several .exes would each duplicate the same code.

The other developer-side version shows up at packaging time, not compile time: a Release .exe runs fine locally because Visual Studio itself supplies the runtime, then gets wrapped in an installer — Inno Setup, NSIS, a hand-rolled MSI — without bundling the actual Visual C++ Redistributable as a prerequisite. The .exe is identical either way; what's missing is a packaging step, not the code. Inno Setup and NSIS both support chaining the official Microsoft redistributable installer as a silent prerequisite (typically with /quiet /norestart); WiX and other MSI-based tools support Visual C++ merge modules for the same purpose. Skipping that step is a classic reason a program that "worked when I tested it" fails the moment it ships to a customer.

One more version that costs teams real time: shipping a Debug build instead of a Release build by accident. Debug builds link against the debug C runtime — files like MSVCP140D.dll, the "D" marking it debug — which is a separate side-by-side component with its own manifest, and Microsoft doesn't distribute the Debug CRT as a standalone public redistributable at all; it only ships with a full Visual Studio install. A tester running a Debug .exe will hit this exact error no matter how many redistributables they install, since the file their manifest asks for was never meant to leave a developer's machine. It's an easy mistake in a rushed release, and one that costs a support ticket every time a customer hits it — and the fix isn't telling the customer to install anything; it's rebuilding and shipping the Release configuration. If a build works internally but fails for every external tester, check the solution configuration dropdown before touching anything else.

If this keeps happening on the same machine

A single side-by-side error is cheap to fix once you know where to look. A PC that develops it repeatedly — a new instance every month or two, on a machine that's otherwise fine — is usually telling you something about the drive or the update process, not about any one program. Before writing that off as bad luck, it's worth checking two things: whether the disk itself is aging (an older mechanical hard drive nearing failure can corrupt files mid-write, including the ones DISM just repaired, which is a very different repair bill than a five-minute redistributable reinstall), and whether Windows Updates are consistently completing cleanly rather than being interrupted.

For a machine already showing this pattern, a straightforward SSD swap tends to be the actual fix, not another round of component repairs — a failing mechanical drive will keep re-corrupting whatever gets fixed. It's also the point where a proper backup, rather than a repair, is the responsible next step: if the drive is genuinely on its way out, the priority shifts from "fix this error" to "get the data off before the next thing that breaks is something DISM can't repair at all." Recommending a backup and a drive check here isn't upselling — it's the honest reading of what a recurring pattern like this usually means.

The hidden cost of "one-click fixer" tools

Search this error and you'll find "DLL fixer" tools promising a one-click solution — and the honest math on most is that they cost more than they save. Skip nearly all of them. The one useful category is a bundler that installs every Visual C++ Redistributable version from 2005 through 2022 in one pass. Stick to a well-known, actively maintained open-source project with visible source code — never an unlabeled .exe from a "driver fix" site.

Actively avoid anything claiming to "clean" or "optimize" your registry as part of the fix. A registry cleaner that strips WinSxS-related entries it misidentifies as unused is a classic self-inflicted cause of side-by-side errors — that's how a healthy PC develops this error out of nowhere. If a PC that never had this problem suddenly does right after a "speed up your PC" tool runs, that tool is the prime suspect, and the DISM/SFC repair above is the bill you're paying to undo it.

One worry you can cross off, though: a genuine redistributable bundler installing older versions alongside the current v14 package is normal and harmless, whether it runs before or after a DISM repair. Coexisting versions are the entire point of side-by-side technology — a 2008 or 2010 package landing next to the v14 runtime doesn't conflict with anything, and doesn't undo anything DISM fixed. The real cost with these tools isn't interaction with the repair; it's provenance, which is why the visible-source-code rule above matters far more than the order you run things in.

The one download mistake that costs more than the error itself

Fake Visual C++ installers are a known malware trick, precisely because so many people search this error and grab the first result. Only download from Microsoft's own domain — learn.microsoft.com or microsoft.com, nothing else, no matter how convincing a mirror looks or how many "Verified Safe" badges it shows. One address that is genuine despite not looking like it: Microsoft's own permanent download links are aka.ms/vc14/... addresses (aka.ms is Microsoft's link shortener) that redirect straight to microsoft.com — so the aka.ms links in Step 2 are the real thing, not a mirror. A redistributable bundled with an unwanted toolbar is a classic malware route specifically because the file really does fix the error, so there's no reason for a victim to suspect it.

If a shop sees this error often, a decent antivirus with real-time scanning is worth having on hand — it catches most bundlers at the download stage, well before a machine ever needs this fix.

If you're already leaning toward a reset anyway

Every step above fixes this error without touching a single personal file. But some machines with this error also come with a longer list of problems — a drive that's audibly failing, an install "cleaned" by three different optimizer tools, a PC old enough that a reset is genuinely the better spend of an afternoon than another round of targeted fixes. If that's the machine in front of you, back up before doing anything else, not after: a reset turns a five-minute redistributable fix into a much longer conversation if a school project or years of family photos live only on that one drive. An external drive large enough for a full image costs a fraction of what redoing that conversation costs later. This isn't the fix for the error itself — Steps 1 through 5 above are — it's the honest adjacent advice for the smaller share of machines where the error is really a symptom of something bigger.

Cutting the recurring cost, for anyone doing this repeatedly

If you set up PCs regularly — a shop reimaging trade-ins, a home lab — Windows 10 and 11 both ship the winget package manager, which installs the current v14 redistributable without opening a browser. From an elevated Terminal:

winget install Microsoft.VCRedist.2015+.x64

winget install Microsoft.VCRedist.2015+.x86

Both lines together cost under a minute and cover the current v14 package — the same one the aka.ms links deliver, still listed by winget under its 2015+ family name — in both architectures, pulled directly from Microsoft's own source, with no third-party download risk. It won't install the older 2005–2013 packages an especially old program might need — those still have to be sourced individually if Step 5's diagnosis points at one of them.

Edge cases that cost extra time if you don't spot them early

Remote Desktop and VMs

If the error only appears over Remote Desktop or inside a VM, and runs fine locally, the redistributables on the host don't carry over — each environment has its own WinSxS store and needs its own install.

Windows Sandbox for isolating the real cause

Windows Sandbox (Pro/Enterprise/Education only, not Home) creates a clean, temporary Windows copy every time it opens, with nothing pre-installed beyond the base OS. Running a failing installer inside Sandbox first is the fastest way to tell whether an error is specific to one PC or a packaging problem in the installer — cheaper than testing on a second physical machine.

Different results per user account on the same PC

Redistributables install machine-wide, not per account, so an error under one Windows account but not another isn't a missing-component issue — it's more likely a per-user setting or a folder permission the program can't write to. Reinstalling the redistributable again just burns more time here.

Multi-monitor and docked-laptop setups

If the error only shows up when a laptop is docked to an external monitor, or with a specific multi-monitor arrangement, that's almost never a side-by-side issue at all — it's worth ruling out before spending time on any of the steps above. Some older games and utilities crash on launch when they can't find the display configuration they expect, and the resulting crash dialog can look similar enough to a manifest error that people misattribute it. Undock, launch the program on the built-in display alone, and see if it opens cleanly; if it does, the fix is in the program's display or resolution settings, not in Visual C++ at all, and none of the redistributable or DISM steps above will change the outcome.

It only started right after a Windows Update

This is worth calling out on its own because it's the situation most likely to justify skipping straight to Step 3's DISM/SFC repair without needing Step 1 or 2 first — and skipping straight there saves real time instead of costing it. A cumulative update that gets interrupted (a shutdown mid-install, a forced restart, a low-battery laptop closing the lid) can leave the WinSxS store in a half-updated state where some components reference a version that update never finished registering. The giveaway is timing: if several previously-working programs, not just one, started failing on the same day an update installed, that's the store, not any individual program's redistributable. The redistributables themselves are very likely still present and healthy; it's the store's record of them that got damaged mid-update. Running DISM /Online /Cleanup-Image /RestoreHealth repairs exactly this, and there's no need to burn time reinstalling redistributables for every affected program individually first.

Tablets and low-storage devices

On smaller-storage Windows 11 tablets and budget laptops with 64 or 128 GB of eMMC storage, check free space before assuming a deeper cause. A near-full drive can cause an installer to exit early without a clear error, which then surfaces later as this same message. Clearing a few gigabytes (Settings > System > Storage) and re-running the installer is the actual fix here, not a component-store repair.

The most expensive misdiagnosis: assuming the PC itself is failing

The costliest wrong turn isn't on the table above, because it doesn't happen at the fix stage — it happens when someone gives up before trying any fix at all. A side-by-side error that keeps recurring across several programs can look, to someone without the WinSxS context, like a sign the hardware itself is dying: a failing drive, bad RAM, a PC worth replacing rather than repairing. That conclusion is usually wrong. The case where several unrelated programs all throw the error points at a damaged component store, which DISM and SFC repair in minutes — not a hardware fault, which would typically show up as far more varied symptoms than one specific error message. Ruling out the five-minute software fix before recommending a replacement PC is worth doing every time this error shows up more than once on the same machine, since the alternative is a customer spending on new hardware to solve a problem a repair command would have fixed for free.

The cost that doesn't show up until the second visit

Jake's customer came back three weeks after her side-by-side error was fixed — not for the same problem, but because the laptop's hard drive was failing, and nothing on it was backed up. That's a separate issue from anything on this page, but it's worth naming here because it's the second visit that actually costs a repair shop a customer, not the first one. A machine that needed a component-store repair or a full reinstall further down this page's methods is exactly the kind of machine worth a quick honest conversation about backup, since a drive that's already struggling enough to corrupt system files is often not far from struggling with everything else on it.

For a customer in that position, the practical options are the same three every shop should have an opinion on: an external drive for local backup, a cloud subscription for anything that needs to survive the PC itself being lost, or — if the repair cost doesn't make sense anymore — simply pricing out a replacement. None of that needs to be a hard sell; it's a thirty-second mention at the counter, made once, while the fix is still fresh.

The thirty-second check that avoids paying this cost again

Once a machine is fixed, the practical next question is what Jake asked: "How do I catch this before it costs another Saturday?" Open Settings > Apps > Installed apps on Windows 11 (or Control Panel > Programs and Features on Windows 10) and search visual c++ before handing a PC back to a customer, or before installing an older game. Seeing the current v14 package — which the list still shows under its installed name, "Microsoft Visual C++ 2015-2022 Redistributable" — plus the relevant older years covers most of what you'll ever be asked to run — a thirty-second check that would have caught Jake's Saturday before it started.

Running through several machines in a row makes the winget commands above worth running as a standard step on every one, the same way you'd check for Windows Update. It costs nothing on a PC that never needs it.

Frequently asked questions

Is this error caused by a virus?

Almost never directly — it's a missing or damaged shared runtime component. The one indirect link: a bundled "PC cleaner" or fake "driver updater" downloaded from an ad can be what removed the component in the first place, which is a separate issue from the error itself being malicious.

Does the actual fix cost anything, or is it free?

Every method on this page is free. The Visual C++ Redistributable, DISM, SFC, sxstrace, and winget are all built into or provided free by Microsoft — nothing here requires paid software, a paid repair tool, or a support call. The only money this error should ever cost is time, and that's the entire reason for laying out which steps waste it and which don't.

I've fixed this before but it keeps coming back on the same PC. What's actually going on?

A genuinely recurring error on one machine, after the redistributable and DISM/SFC steps have both been done properly, usually points at something actively re-breaking the store — often a registry cleaner or "optimizer" tool still installed and still running on a schedule. Check Task Scheduler and the installed-apps list for anything matching that description before assuming the fix itself failed; a fix that keeps getting undone looks identical to a fix that never worked.

Why doesn't reinstalling the program fix it, when that's everyone's first instinct?

Because the program's installer usually doesn't bundle the runtime it depends on — it assumes Windows already has it. Reinstalling the program reinstalls that same assumption without adding the missing component, which is why it's the costliest wrong turn most people try first.

Do I need every Visual C++ Redistributable year installed, or just the latest?

Install the current v14 package as your baseline — the one Microsoft's download page now brands "Visual C++ v14 Redistributable" and Installed apps still lists as "Microsoft Visual C++ 2015-2022 Redistributable." It covers most modern software at no extra cost. Add an older 2005, 2008, 2010, 2012, or 2013 package only if the specific program targets that older runtime, since a newer redistributable doesn't retroactively satisfy an older manifest request — and those older runtimes are the ones behind the classic manifest-based form of this exact error.

Does having multiple redistributable versions installed cause conflicts, or cost anything?

No, and it costs negligible disk space. Multiple versions coexisting is the entire point of side-by-side technology, and having the 2008, 2013, and 2015–2022 packages all installed at once is normal on any well-used PC.

I already reinstalled the redistributable and it still fails. What's the next cheapest step?

Move to the DISM and SFC repair in Step 3. If the redistributable reports success but the error persists, the WinSxS store itself likely has a damaged entry silently rejecting the registration — the installer has no way to know the store underneath it is unhealthy.

Does this mean my whole Windows installation is damaged?

Not necessarily, and usually not. One program failing on its own doesn't imply anything wrong with Windows itself — only that one program's specific dependency is missing. Multiple unrelated programs failing at once is the pattern that actually points toward the component store needing repair.

Can I delete the WinSxS folder to save space and clear this up at the same time?

Don't — that's the single most expensive mistake on this page. Much of WinSxS is hard-linked to files Windows actively uses, so deleting it breaks the OS rather than freeing meaningful space, and it will very likely trigger this error across far more programs than you started with. To reclaim space safely, use DISM /Online /Cleanup-Image /StartComponentCleanup instead.

Is this more common on Windows 11 or Windows 10?

About equally common on both — the underlying WinSxS system and manifest-matching behavior didn't change between the two, and most of the software that triggers it predates either OS. The fix is identical on both; only the uninstall/reinstall menu locations differ.

My antivirus flagged the redistributable installer I downloaded. Do I stop?

If it came directly from microsoft.com or learn.microsoft.com (including via one of Microsoft's own aka.ms links, which redirect there), treat the flag as a likely false positive and report it — genuine Microsoft-signed installers occasionally trip heuristic scanners. If it came from anywhere else, stop and re-download from Microsoft's own site instead.

How do I check whether a program needs the 32-bit or 64-bit redistributable, without guessing?

Check Task Manager's Processes tab while the program briefly runs (before it crashes) — 32-bit programs show a "(32-bit)" suffix next to their name there, which means the program needs the x86 redistributable regardless of your edition being 64-bit. (On the Details tab that suffix doesn't appear; you'd have to right-click a column header and add the optional Architecture column.) Installing both, as Step 2 recommends, sidesteps the guesswork entirely.

Is there a way to stop paying this cost every few months?

Avoid registry cleaner and "PC optimizer" tools — a cleaner that strips WinSxS entries is a classic self-inflicted cause of a previously healthy PC developing this error out of nowhere. Beyond that, there's nothing to proactively maintain — a correctly installed redistributable stays installed unless something actively removes it.

Revision note. Originally published June 16, 2016 as a short personal account of fixing this error for one game by reinstalling the Visual C++ Redistributable. That core fix held up and is still Step 2 above. This rewrite reframes the post around the time actually wasted on wrong turns, and adds the DISM/SFC component-store repair, sxstrace diagnosis, the developer-side causes, current Windows 11 and Windows 10 navigation paths, and current Visual C++ Redistributable download guidance.