Fix MSVC C++ Compiler Errors in Visual Studio 2022
Why This Is Happening
Picture this: you open Visual Studio 2022, load a C++ project you've been working on for weeks, hit Build , and get slapped with a wall of red errors. Maybe it's MSB8036: The Windows SDK version X.X was not found, or error MSB4019: The imported project "Microsoft.Cpp.Default.props" was not found, or the compiler just silently refuses to start. I've seen this exact situation on dozens of machines, and it almost always comes back to the same handful of root causes.
The MSVC toolset for Visual Studio 2022 is identified internally as v170. When Microsoft says you're running the v170 compiler toolset, they mean the full suite of tools , the cl.exe compiler, the link.exe linker, the standard libraries, the C Runtime (CRT), and all the supporting build infrastructure that ships with Visual Studio 2022. That entire stack needs to be present and correctly configured before a single line of your C++ code can compile.
The tricky part is that Visual Studio 2022 doesn't install C++ support by default. When you run the Visual Studio installer, you get the IDE shell and some basic tools, but the actual MSVC v170 compiler, headers, and libraries are part of an optional workload called "Desktop development with C++". If that workload wasn't selected during install (or got partially corrupted during an update), you end up with an IDE that looks fine but can't build anything. The error messages you get are rarely helpful about this. They point at MSBuild property files instead of telling you plainly that your compiler is missing.
There's also the side-by-side scenario. According to Microsoft's official documentation, you can install Visual Studio 2015, 2017, 2019, and 2022 on the same machine simultaneously. That's genuinely useful, but it also means four different toolset versions (v140, v141, v142, v170) can coexist, and projects opened in VS 2022 might try to use a toolset from an older installation that's no longer intact. If you upgraded from VS 2019 and your project's .vcxproj file still targets v142, you'll get build failures that look bizarre until you understand what's happening under the hood.
Other common triggers I see regularly: partially failed Windows Update cycles that break the Visual C++ Redistributable packages, antivirus software quarantining cl.exe mid-install, disk space running out partway through a component installation, and corporate IT pushing group policy changes that block certain executable paths. Any of these can leave your MSVC v170 setup in a broken half-state.
The good news is that the fix is almost always doable without reinstalling Visual Studio from scratch. Work through the steps below in order and you'll be back to building C++ in Visual Studio 2022 faster than you'd think. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go digging through registries or reinstalling anything, try the Visual Studio Installer's built-in repair function. This fixes the majority of MSVC v170 compiler issues in under ten minutes, and it's completely safe, it doesn't touch your projects or settings.
Here's exactly what to do:
- Close Visual Studio 2022 completely. Make sure it's not running in the background, check Task Manager for any
devenv.exeprocesses and end them. - Open the Visual Studio Installer. You'll find it by searching "Visual Studio Installer" in the Start menu. It's a separate app from Visual Studio itself, usually listed right below VS 2022 in your results.
- In the installer, you'll see your installed Visual Studio 2022 product listed. Click the three-dot menu (⋯) next to it and select Repair.
- The installer will verify every installed component against its expected state and redownload anything that's missing or corrupted. On a typical broadband connection this takes 5–15 minutes depending on how much needs to be replaced.
- Once the repair completes, the installer will prompt you to restart. Do it, don't skip this.
After the restart, open Visual Studio 2022 and try building your project again. For a lot of people, this is the end of the story. The repair catches corrupted binaries, re-registers components, and restores any files that got wiped by an aggressive antivirus scan or a failed update.
If repair alone doesn't work, your next move is to verify that the "Desktop development with C++" workload is actually installed. In the same Visual Studio Installer screen, click Modify instead of Repair. Look for the "Desktop development with C++" tile in the Workloads tab. If it's not checked, check it and click Modify to install it. Make sure the right panel also shows "MSVC v143 - VS 2022 C++ x64/x86 build tools" checked, that's the actual v170 compiler package.
The most common cause of C++ build failures in Visual Studio 2022 is missing toolset components, and the installer's workload UI doesn't always make this obvious. Let's confirm exactly what's installed.
Open the Visual Studio Installer, click Modify on your VS 2022 installation, then go to the Individual components tab. In the search box type MSVC v143. You should see entries like:
- MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest)
- MSVC v143 - VS 2022 C++ ARM64 build tools (Latest), if you target ARM
If any of these are unchecked, check them and install. While you're in this view, also verify that Windows 11 SDK (or Windows 10 SDK if applicable) is checked. MSVC needs the SDK to access platform headers and libraries for building Windows applications.
You can also verify the toolset is present on disk. Navigate to:
C:\Program Files\Microsoft Visual Studio\2022\[Edition]\VC\Tools\MSVC\You should see a versioned subfolder like 14.43.34808 (the exact number varies by patch level). Inside that folder you want to confirm bin\Hostx64\x64\cl.exe exists. If that file is missing, the compiler genuinely isn't installed, no amount of project configuration will fix it. Run the installer repair or modification to get it back.
When this step succeeds, opening a new Developer Command Prompt for VS 2022 and typing cl should print the compiler version banner starting with "Microsoft (R) C/C++ Optimizing Compiler Version 19.4x..." rather than an error.
If you opened a project that was created in Visual Studio 2017 or 2019, its .vcxproj file may reference an older toolset version (v141 or v142) that isn't installed on your current machine. Visual Studio 2022 will usually offer to retarget the project automatically, but sometimes it doesn't, or you dismissed that dialog accidentally.
To fix this manually, right-click your project in Solution Explorer and select Properties. Under Configuration Properties > General, look for the Platform Toolset dropdown. Change it from whatever it shows (v141, v142) to Visual Studio 2022 (v143). Click Apply, then OK.
If you have multiple projects in a solution, you'll need to do this for each one. A faster way for large solutions: right-click the solution in Solution Explorer and choose Retarget Solution. This opens a dialog where you can update all projects at once to target the installed Windows SDK version and platform toolset.
For command-line or CI/CD environments, you can also force the toolset version via MSBuild properties:
msbuild MyProject.vcxproj /p:PlatformToolset=v143 /p:Configuration=Release /p:Platform=x64After changing the platform toolset, do a full Clean Solution (Build menu > Clean Solution) followed by a fresh Rebuild Solution. The clean step is important, stale object files built with the old toolset can cause linker errors even after you've switched toolsets.
Success indicator: the Output window should show Build succeeded with no MSB8036 or MSB4019 errors. If you still see toolset-related errors, double-check that no individual project in the solution still has a hardcoded toolset path in its property sheets.
This one catches a lot of people off guard. The Visual C++ Redistributable packages are separate from the developer toolset, they're the runtime libraries that compiled C++ applications need to run. When these get corrupted or when an app you installed replaces them with an older version, you can see crashes, missing DLL errors, or even build failures where the linker can't find expected runtime imports.
I know this is frustrating, especially when the error message says something like The program can't start because MSVCP140.dll is missing and you've got the full Visual Studio 2022 installed. The redistributables and the compiler toolset are distributed separately, having one doesn't guarantee the other is intact.
To fix this, head to Microsoft's official download page for Visual C++ Redistributable packages. You want the Visual Studio 2022 versions. Download and run both:
- vc_redist.x64.exe, for 64-bit applications
- vc_redist.x86.exe, for 32-bit applications (yes, even on a 64-bit OS)
Run each installer and choose Repair if the redistributable is already present, or Install if it's not. The installer will register the correct DLL versions in the right system locations.
After installing, verify via PowerShell that the correct versions are registered:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64" | Select-Object Version, BldYou should see a version number in the 14.4x.xxxxx range for the VS 2022 redistributable. If you're still seeing 14.2x entries as the highest version after installing, something blocked the registration. Try running the redistributable installer from an elevated command prompt rather than by double-clicking.
MSVC doesn't compile in a vacuum, it needs the Windows SDK to access platform headers, import libraries, and the actual API definitions for Windows. If your SDK installation is mismatched with your project settings, you'll see errors like cannot open include file: 'windows.h': No such file or directory or the MSB8036 "Windows SDK version not found" error.
First, check which SDK versions are installed. Open the Visual Studio Installer, click Modify on VS 2022, go to Individual Components, and search for "Windows SDK". Make sure at least one recent SDK (Windows 11 SDK 10.0.22621 or newer is recommended for VS 2022 development) is checked and installed.
Then, verify your project is targeting an installed SDK version. In your project's Properties > Configuration Properties > General, check the Windows SDK Version field. If it shows a specific version number that's not installed (like 10.0.19041.0 when you only have 10.0.22621.0), change it to match what you have. You can also set it to 10.0 (latest installed version) to always use whatever's current on the machine, that's usually the safest choice for projects you control.
For projects that need to stay pinned to a specific SDK version (common in embedded or driver development scenarios), install that exact SDK version via the Visual Studio Installer Individual Components tab rather than changing the project settings. That preserves build reproducibility.
After making SDK changes, always do a full Clean + Rebuild. The IntelliSense engine also caches header paths separately from the build system, so if IntelliSense is still showing red squiggles under #include <windows.h> after a successful build, close and reopen the solution to force IntelliSense to re-index.
Visual Studio 2022's MSVC toolset supports a wide range of targets beyond Windows desktop, you can use it to build Linux applications (via the remote Linux development workload), Android projects, and cross-platform libraries that run on Windows, Linux, iOS, and Android. Each of these scenarios has its own setup requirements, and misconfiguration is easy.
For standard Windows desktop C++ development, make sure your project's C++ Language Standard setting matches what you're actually using in code. Find this at Properties > C/C++ > Language > C++ Language Standard. If your code uses C++20 features (concepts, ranges, coroutines) but the project is set to /std:c++17, you'll get confusing "feature not available" errors. Set it to /std:c++20 or /std:c++latest for the newest features.
For CMake-based projects (which Visual Studio 2022 supports natively via File > Open > CMake), the MSVC generator needs to be specified correctly in your CMakePresets.json or CMakeSettings.json. If CMake is picking up the wrong compiler (a GCC from WSL, for instance), explicitly set the generator:
"generator": "Visual Studio 17 2022",
"architecture": "x64",
"toolset": "host=x64"If you're targeting Linux from Visual Studio using the GCC cross-compilation path described in the official documentation, verify the Linux development with C++ workload is installed and that your SSH connection to the remote machine is configured under Tools > Options > Cross Platform > Connection Manager. Connection failures here produce build errors that look like local compiler problems but are actually SSH or path translation issues.
When the fix works, a CMake project should show "CMake generation finished" in the CMake output window with no errors, and a native Windows project should build in under 30 seconds for a clean hello-world.
Advanced Troubleshooting
If you've worked through all five steps above and you're still fighting the MSVC v170 toolset, it's time to dig deeper. Here's what I look at for the harder cases.
Checking the Windows Event Log
Visual Studio installer failures and MSBuild crashes often leave detailed records in the Windows Event Log. Open Event Viewer (search "Event Viewer" in Start), then navigate to Windows Logs > Application. Filter the log by Source = "MsiInstaller" and look for entries timestamped around when your issue started. Event ID 1033 indicates a successful installation, while 1034 signals a removal, if you see a 1034 for a Visual C++ component, something uninstalled it. Event ID 11708 indicates a critical install failure.
Visual Studio also writes its own detailed logs. After a failed install or repair, find the logs at:
%TEMP%\dd_installer_[timestamp].logThese are verbose text files, search them for "Error" or "Failed" to find the specific component that broke.
Registry-Level Toolset Verification
MSBuild locates the MSVC toolset through registry entries. If these got corrupted, builds fail even when the files exist on disk. Check this key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7You should see a 17.0 value pointing to your Visual Studio 2022 install directory (typically C:\Program Files\Microsoft Visual Studio\2022\Community\ or Professional\ or Enterprise\). If it's missing or pointing somewhere that no longer exists, running the Visual Studio Installer repair will re-create it.
Enterprise and Domain-Joined Scenarios
On corporate machines, Group Policy can prevent certain executables from running or restrict write access to directories that the MSVC toolset needs. Specifically, cl.exe, link.exe, and msbuild.exe are sometimes flagged by application whitelisting tools like AppLocker or Windows Defender Application Control. Run this PowerShell command to check if AppLocker is blocking anything:
Get-AppLockerPolicy -Effective | Test-AppLockerPolicy -Path "C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.43.34808\bin\Hostx64\x64\cl.exe" -User EveryoneIf the result shows "Denied", you'll need to work with your IT team to whitelist the Visual Studio compiler binaries. Similarly, network-level proxy settings can block the Visual Studio Installer from downloading components, use the installer's offline mode by downloading the full layout package, or configure the proxy under Tools > Options > Environment > Proxy Settings inside Visual Studio.
Spectre Mitigation Conflicts
The MSVC v170 toolset ships with Spectre-mitigated library variants, a security improvement against CPU side-channel attacks mentioned in the official Microsoft documentation. However, mixing Spectre-mitigated and non-mitigated code in the same project causes linker errors like LNK2038: mismatch detected for 'Spectre'. Make sure every project in your solution has the same Spectre mitigation setting under Properties > C/C++ > Code Generation > Spectre Mitigation. Either all Enabled or all Disabled, don't mix.
%TEMP% and the specific error messages you're seeing. They can run the VS Setup diagnostic tool on your machine remotely.
Prevention & Best Practices
Once you've got your MSVC v170 setup working, the last thing you want is to end up back here next month. Here's how to keep things stable.
Keep the Visual Studio Installer running its updates on a regular cadence. Microsoft ships monthly updates to the MSVC v170 compiler that include bug fixes, C++ standard conformance improvements, and security patches. Unlike Windows Update, Visual Studio updates are not automatic by default, you have to open the installer or accept the update notification that Visual Studio shows in its title bar. Don't let it fall more than two or three versions behind. Older compiler versions occasionally have codegen bugs that silently produce incorrect output, and those are far harder to diagnose than a build error.
If you're working in a team environment, standardize on a specific Visual Studio version and toolset across the team. One person on VS 2022 17.6 and another on 17.11 can cause subtle build differences, especially when property sheets or CMake presets are involved. Document the expected Visual Studio version in your repo's README and enforce it in CI/CD. MSBuild has the VisualStudioVersion property and CMake supports the CMAKE_VS_VERSION check to help with this.
Back up your Visual Studio workload configuration. You can export the list of installed components with:
"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -format json > vs_config.jsonKeep this file in a known location so you can restore your exact environment after a fresh install or machine replacement.
For projects targeting multiple platforms (Windows desktop, UWP, Linux, Android), install each target workload upfront rather than discovering missing components during a build. The modular workload system in Visual Studio 2022 means you can have cross-platform C++ development, game development with C++, Linux C++ development, and desktop C++ all installed simultaneously without them conflicting, but they need to be installed deliberately.
- Run the Visual Studio Installer every month and apply pending updates to keep the MSVC v170 compiler current
- Always install both the x64/x86 build tools and the x64 native tools, the latter is needed to compile large projects without hitting 32-bit memory limits
- Pin your Windows SDK version in the project file rather than using "Latest" in shared or open-source projects to avoid breaking contributors who have different SDK versions
- Enable the Visual Studio crash feedback dialog so that compiler crashes automatically submit diagnostic data to Microsoft, this helps them fix MSVC bugs faster
Frequently Asked Questions
Why does my C++ project say "MSVC v143 build tools not found" even though Visual Studio 2022 is installed?
Visual Studio 2022 and the MSVC v143/v170 compiler toolset are separate install components. The Visual Studio IDE can be installed without any C++ support at all, you need the "Desktop development with C++" workload specifically. Open the Visual Studio Installer, click Modify on your VS 2022 installation, and check the Desktop development with C++ tile in the Workloads tab. Also expand the right-side panel and make sure "MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest)" is checked. Once installed, close and reopen your solution and try building again.
Can I use Visual Studio 2022 to open and build a project created in Visual Studio 2019?
Yes, this is fully supported and actually a common workflow. According to Microsoft's official documentation, you can install Visual Studio versions side-by-side and use the toolset from any installed version. When you first open a VS 2019 project in VS 2022, you'll typically get a prompt to retarget the project to the current SDK and toolset. You can also retarget manually via right-clicking the solution and selecting "Retarget Solution." The original .vcxproj file will be updated to reference v143 instead of v142. If you need to keep the project buildable in VS 2019 as well, you can install the v142 build tools as an individual component inside VS 2022 and keep your project pinned to v142.
I'm getting "cl.exe" not found errors in my terminal even though Visual Studio is installed, what's wrong?
The MSVC compiler is not added to your system PATH by default, it's only available in specialized developer environments that set up the correct environment variables. You have two options: use the Developer Command Prompt for VS 2022 or Developer PowerShell for VS 2022 shortcuts that Visual Studio installs in your Start menu (these automatically run vcvarsall.bat to configure the environment), or call vcvarsall.bat directly in your own script: "C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64. Trying to run cl.exe from a plain Command Prompt or PowerShell window will always fail because the header and library paths aren't set.
My build was working fine yesterday and now I'm getting MSVC linker errors, what changed?
The most common cause of sudden linker failures after a period of working builds is a Visual Studio update that partially completed, or a Windows Update that replaced or deleted a Redistributable component. Open the Visual Studio Installer and check if there's a pending update, if there is, complete it rather than dismissing it, since a half-applied update leaves components in an inconsistent state. Also check Windows Update history for any recent C++ Redistributable updates. If you find a recently installed update that correlates with when things broke, run the Visual Studio Installer repair to re-synchronize all components. A full Clean + Rebuild after the repair resolves lingering object-file inconsistencies.
How do I build a C++ project from the command line using the MSVC v170 toolset without opening Visual Studio?
Use MSBuild from a Developer Command Prompt. First, open Developer Command Prompt for VS 2022 from the Start menu, then navigate to your project directory and run: msbuild YourProject.vcxproj /p:Configuration=Release /p:Platform=x64. For CMake projects, use: cmake --build . --config Release after configuring with the Visual Studio 17 2022 generator. If you need this in a CI/CD pipeline that doesn't have the Start menu shortcuts, use the vsdevcmd.bat script at "C:\Program Files\Microsoft Visual Studio\2022\[Edition]\Common7\Tools\VsDevCmd.bat" to initialize the build environment before calling MSBuild. The Visual Studio Build Tools package (a separate, lighter-weight installer available from Microsoft) lets you install just the compiler and build tools on CI machines without the full IDE.
Why are there so many different MSVC version numbers, v140, v141, v142, v143, v170? Which one do I need?
These are platform toolset version identifiers that correspond to Visual Studio release generations. v140 = Visual Studio 2015, v141 = VS 2017, v142 = VS 2019, and v143 = VS 2022. The "v170" designation you sometimes see refers to the internal version numbering of the VS 2022 IDE and toolchain as a whole, while v143 specifically identifies the compiler toolset within that generation. For new projects in Visual Studio 2022, you want v143. You only need older toolsets (v141, v142) if you're maintaining legacy projects or need to produce binaries that are binary-compatible with software built on those older toolsets. Microsoft's documentation confirms all these toolsets can coexist on the same machine via the Individual Components tab in the Visual Studio Installer, install exactly the ones your projects require and leave the rest out to save disk space.