vcruntime140_1d.dll Is Missing: Fixes for Windows 10 and 11

×

Windows Errors? Fix Them Before They Spread

Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallFix My PC Now →

Outdated Drivers Are Slowing You Down

One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchScan My Drivers Free →

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The code execution cannot proceed because VCRUNTIME140_1D.dll was not found. Reinstalling the program may fix this problem.

If Windows reports that vcruntime140_1d.dll was not found, the executable cannot load a Microsoft Visual C++ debug runtime dependency. The final d is important: it identifies a debug build, so installing the normal Visual C++ Redistributable usually does not install the missing file.

As an Amazon Associate I earn from qualifying purchases.

Which fix applies to you

Use the path that matches the program showing the error.

• You are building or testing software with Visual Studio, CMake, Qt, Xbox tools, or another C++ toolchain: install or repair the matching Visual Studio or Build Tools C++ workload, then run the debug program from that development environment.
• A normal game or desktop application refuses to launch: the vendor may have shipped a Debug build by mistake, or its installation may be incomplete. Repair or reinstall the application and look for a corrected Release build.
• The error appears in an MSIX, UWP, WinUI, or Desktop Bridge package: install the matching debug Microsoft.VCLibs framework through the development tools or package workflow.
• The program worked until an update or antivirus detection: check Protection History, verify the installation, and reinstall from the trusted publisher if necessary.
• The message says the DLL is not designed to run on Windows or contains an error: investigate architecture, corruption, and toolset mismatches instead of downloading a replacement DLL.
• You do not know which program is responsible: identify the executable or launcher first. The missing file may belong to a helper process rather than the main application.

What vcruntime140_1d.dll actually is

vcruntime140_1d.dll is a Microsoft Visual C++ runtime library for debug C and C++ programs. The vcruntime portion provides compiler-specific startup code, exception handling, intrinsic support, and other runtime functions used by applications compiled with MSVC. Microsoft identifies this DLL as a CRT dependency intended for development rather than normal consumer deployment. Microsoft’s Xbox dependency sample lists it as a development-only dependency.

The final d is the key difference. Microsoft’s debug executable guidance explains that debug runtime libraries conventionally use a d suffix. A program linked with the /MDd runtime setting can therefore request files such as:

vcruntime140_1d.dll
vcruntime140d.dll
msvcp140d.dll
ucrtbased.dll

These are not interchangeable with their Release equivalents.

File	Build type	What normally provides it
vcruntime140_1.dll	Release runtime	Visual C++ Redistributable or an application installer
vcruntime140_1d.dll	Debug runtime	Visual Studio, Build Tools, a debug framework package, or a test deployment

Microsoft states that debug versions of its runtime DLLs are not redistributable for general public software. The ordinary Redistributable packages are intended for Release applications, not for distributing a consumer application together with a debug CRT. Microsoft’s DLL redistribution rules explain this distinction.

The related vcruntime140_1.dll was introduced with Microsoft’s Visual Studio 2019-era changes to x64 C++ exception handling. That does not make every vcruntime140_1d.dll identical across toolsets. The correct debug library still needs to match the executable’s architecture and compatible MSVC toolset. Microsoft’s C++ Team Blog describes the introduction of the runtime family.

There is no single universal version, file size, or bitness for this DLL. Those details vary between toolsets and architectures.

First, identify the program requesting the DLL

The error dialog normally names the executable or appears immediately after launching a particular game, installer, launcher, IDE, or test tool. Record that name before trying repairs.

Pay particular attention to whether the error comes from:

• The main game or application.
• A launcher, updater, crash reporter, or anti-cheat helper.
• A CMake test executable.
• A Visual Studio debugging session.
• A plugin, mod loader, or third-party extension.
• An MSIX, UWP, or WinUI package.

This distinction matters because reinstalling the main program will not repair a separate helper that was installed elsewhere.

If the application starts far enough to show a process in Task Manager, open Task Manager with Ctrl + Shift + Esc, select the Details tab, and look for the executable name. You can also right-click the process and choose Open file location when that option is available.

For a developer diagnosis, Microsoft documents this command:

dumpbin /DEPENDENTS YourProgram.exe

Run it from a Developer Command Prompt for Visual Studio and replace YourProgram.exe with the actual executable. The output shows imported DLLs and helps establish whether the executable itself requests vcruntime140_1d.dll or whether one of its secondary DLLs does. Microsoft’s /DEPENDENTS documentation explains the command.

If the application is distributed by someone else, send the vendor:

• The exact executable name.
• The complete error message.
• Whether the error appears in the launcher or the main program.
• Your Windows version.
• Whether Windows is 64-bit.
• Whether the application is 32-bit, 64-bit, or ARM64.
• Where you installed it.
• What changed immediately before the error.
• Whether other d-suffixed runtime files are also missing.

Fix 1: Install the correct Visual Studio debug tools

This is the most likely fix on a developer or test machine.

Do not start by installing random copies of the DLL. Install the development environment that owns the debug runtime.

1. Download Visual Studio or Build Tools from the official Visual Studio Downloads page.
2. Start the Visual Studio Installer.
3. Find the installed Visual Studio or Build Tools entry.
4. Select Modify.
5. On the Workloads tab, select Desktop development with C++.
6. Select Modify or Install.
7. If the project requires an older toolset, open Individual components and select the required MSVC toolset, such as the v141 or v142 components used by the project.
8. Allow the installer to finish.
9. Restart Visual Studio, the test runner, CMake, or the machine that is running the program.
10. Run the debug executable again.

Microsoft documents this workload and installation path in its C and C++ installation guide and Visual Studio modification instructions.

A successful repair means the program starts under the same development environment and configuration that built it. If the error remains, the project may require a different toolset or architecture than the one you installed.

Check the project’s runtime setting

In Visual Studio:

1. Right-click the project in Solution Explorer.
2. Select Properties.
3. Choose the affected configuration, such as Debug, from the Configuration menu.
4. Choose the affected platform, such as x64, Win32, or ARM64, from the Platform menu.
5. Open Configuration Properties.
6. Select C/C++.
7. Select Code Generation.
8. Check Runtime Library.

Microsoft defines the relevant settings as follows:

• /MD uses the multithreaded Release DLL runtime.
• /MDd uses the multithreaded Debug DLL runtime.

A debug configuration commonly uses /MDd, while a Release configuration intended for ordinary distribution uses /MD. The setting is documented in Microsoft’s runtime-library compiler options.

If you are debugging the application, keep /MDd and install the matching debug environment. If you are preparing software for other users, select the Release configuration and rebuild using /MD. All linked modules should use compatible runtime-library settings. A single plugin or library built with /MDd can cause the final application to request the debug CRT even when the main project appears to be configured for Release.

After changing the setting, rebuild every affected project. With a multi-project solution, use Build followed by Rebuild Solution.

For a CMake project, make sure you are running the intended configuration. With a multi-configuration Visual Studio generator, a Release build can be produced with:

cmake --build build --config Release

For a debug test deployment, use the matching Debug configuration and run it on a machine with the corresponding Visual Studio debug libraries installed.

Where the debug runtime may be located

Microsoft documents debug libraries inside the Visual Studio installation’s non-redistributable debug area. The structure resembles:

...\VC\Redist\MSVC\<toolset>\debug_nonredist\<architecture>\Microsoft.<toolset>.DebugCRT\

The exact folder depends on the installed Visual Studio version, toolset, and architecture. Do not treat this as an invitation to copy the DLL into System32. Use the directory as a diagnostic clue and let Visual Studio, the test deployment process, or the application’s documented development setup manage the runtime.

Fix 2: Repair or reinstall a game or normal desktop application

If a consumer game or application displays an error for vcruntime140_1d.dll, there is a strong possibility that the publisher shipped a debug build or included a debug-built library by mistake.

A normal end-user should not be expected to install Visual Studio merely to launch a finished game. The definitive fix is a corrected Release build from the software vendor.

Start with the application’s own repair option.

Repair through Windows 11

1. Open Start.
2. Select Settings.
3. Select Apps.
4. Select Installed apps.
5. Find the affected application.
6. Select its three-dot menu.
7. Choose Advanced options.
8. Select Repair.
9. Launch the program again.

If Repair does not help and Windows offers Reset, use Reset only after checking whether it removes local settings or saved data. Traditional desktop applications may instead show Repair or Change through:

1. Open Control Panel.
2. Select Programs.
3. Select Programs and Features.
4. Right-click the affected program.
5. Choose Repair or Change.

If repair fails, uninstall the application and install a fresh copy from its original trusted publisher or launcher. Do not preserve a suspicious application-local DLL just to avoid downloading the program again.

For a game, use the launcher’s file verification feature. In Steam, this is normally under the game’s Properties, then Installed Files, then Verify integrity of game files. Other launchers use names such as Verify, Repair, or Scan and repair.

File verification can restore a missing application-local dependency. It cannot convert a defective Debug build into a proper Release build. If verification repeatedly restores vcruntime140_1d.dll and the game still fails, contact the game publisher with the exact executable name and error.

Should you install the Visual C++ Redistributable

Microsoft provides the normal Release packages as:

• vc_redist.x64.exe
• vc_redist.x86.exe
• vc_redist.arm64.exe

The official packages are listed on Microsoft’s Latest supported Visual C++ Redistributable downloads page. Direct Microsoft downloads include the x64 package, x86 package, and ARM64 package.

These packages are appropriate when the error names the Release file:

vcruntime140_1.dll

They are not a general source for:

vcruntime140_1d.dll

Microsoft excludes debug runtime DLLs from normal redistribution. Installing the x64 or x86 Release package may repair a related Release dependency, but it should not be promised as a fix for the _1d error.

The application’s architecture must also match the package:

• A 64-bit program needs the x64 runtime.
• A 32-bit program needs the x86 runtime.
• A 32-bit program still needs x86 components on 64-bit Windows.
• An ARM64 program needs the ARM64 package or the deployment method documented by its publisher.

Many Windows PCs legitimately need both x64 and x86 Release runtimes because they run applications of both architectures.

Fix 3: Repair an MSIX, UWP, WinUI, or Desktop Bridge package

Packaged applications can use a C++ framework package rather than a traditional application-local DLL.

This is especially relevant when the failing program is:

• An MSIX package.
• A UWP application.
• A WinUI application.
• A Desktop Bridge conversion.
• An Xbox or GDK development package.
• A debug build installed from Visual Studio.

For a debug package, install the matching debug Microsoft.VCLibs framework through Visual Studio, the Windows SDK, or the package’s documented development workflow. Do not substitute a retail framework package for a debug package and assume the runtime names are interchangeable.

Microsoft documents Desktop Bridge C++ runtime framework packages under a path similar to:

%ProgramFiles(x86)%\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

The actual path can vary with the installed Windows SDK. Its SDKManifest.xml distinguishes debug and retail framework identities. Microsoft’s Desktop application preparation guidance and documentation for C++ runtime framework packages for Desktop Bridge cover this deployment model.

On a development PC:

1. Open the Visual Studio Installer.
2. Select Modify for the relevant installation.
3. Confirm Desktop development with C++ is installed.
4. Confirm the Windows SDK and required MSVC toolset are installed.
5. Rebuild or redeploy the package in the same architecture as the application.
6. Remove the broken test package if necessary.
7. Install the newly generated package and its matching dependencies.

On a consumer PC, obtain a corrected package from the application vendor. Installing development-only framework files system-wide is not an appropriate end-user repair.

Fix 4: Check whether antivirus removed the file

A missing DLL can be the result of an interrupted installation or antivirus quarantine. This is more plausible when:

• The application worked before a security scan.
• The file existed in the application folder and then disappeared.
• The error started immediately after an update.
• The application’s installer was interrupted.
• Other files from the same installation are also missing.

For Microsoft Defender:

1. Open Windows Security.
2. Select Virus & threat protection.
3. Select Protection history.
4. Expand the detection related to the application.
5. Check the original file path and detection details.
6. Restore the file only if it came from a trusted, known-good Visual Studio, SDK, or application installation.

Microsoft warns that restoring a detected file can expose the system if the detection was genuine. Protection History retains events for a limited period, documented by Microsoft as two weeks.

Do not repeatedly restore the file if Defender immediately detects it again. Instead:

1. Leave the detection quarantined.
2. Run a full Microsoft Defender scan.
3. Scan the original installer.
4. Download a fresh installer from Microsoft or the software publisher.
5. Reinstall the application.
6. Contact the publisher if the clean installer produces the same detection.

A debug runtime can be legitimate in a development environment, but a modified or unofficial DLL may also be malicious. The file’s name alone does not prove that a quarantined copy is safe.

Fix 5: Match the application architecture and toolset

A 64-bit Windows installation does not tell you whether the failing application is 32-bit or 64-bit. Windows commonly runs 32-bit applications on 64-bit systems.

The runtime must match the executable:

32-bit executable  → x86 runtime
64-bit executable  → x64 runtime
ARM64 executable   → ARM64 runtime

Do not copy the same DLL into both C:\Windows\System32 and C:\Windows\SysWOW64. Those directories serve different Windows loader paths, and placing an incompatible debug library there can create additional failures for unrelated programs.

A bad-image error can be caused by:

• An x86 DLL loaded by an x64 executable.
• An x64 DLL loaded by an x86 executable.
• A corrupted or truncated file.
• A debug DLL from an incompatible toolset.
• An application-local copy taking precedence over the intended runtime.
• Malware or an unofficial replacement.

If the file exists but Windows says it is not designed to run on Windows or contains an error, reinstall the complete toolset or application. Do not overwrite the file with a download from an arbitrary DLL website.

For developers, use dumpbin /DEPENDENTS on the executable and its likely secondary DLLs. Also check the project’s Configuration Manager in Visual Studio:

1. Open Build.
2. Select Configuration Manager.
3. Check whether the active configuration is Debug or Release.
4. Check whether the platform is Win32, x64, or ARM64.
5. Rebuild all linked projects using compatible settings.

Mixing Visual Studio 2017, 2019, 2022, or later toolsets can expose this problem when one library was built with a newer runtime expectation. Install the toolset that produced the dependency or rebuild all components consistently. The presence of vcruntime140_1.dll in the runtime family does not mean every toolset and binary combination is interchangeable.

Fix 6: Run Windows Update, DISM, and SFC when system corruption is plausible

Windows Update is relevant when Windows components or supported runtime servicing are damaged. It is not the normal source of a Visual Studio debug DLL.

To check for updates:

1. Open Start.
2. Select Settings.
3. Select Windows Update.
4. Select Check for updates.
5. Install available updates.
6. Restart Windows.
7. Test the application again.

If the issue affects several applications or Windows itself reports additional missing or damaged components, run Microsoft’s repair sequence from an elevated Command Prompt.

1. Open Start.
2. Type Command Prompt.
3. Right-click Command Prompt.
4. Select Run as administrator.
5. Run:

DISM.exe /Online /Cleanup-image /Restorehealth

1. Wait for it to finish.
2. Then run:

sfc /scannow

1. Restart Windows.
2. Try the application again.

Microsoft recommends running DISM before SFC in its System File Checker guidance.

Success means DISM or SFC reports that it repaired component-store or protected system-file problems, followed by a successful launch. If both commands report no integrity violations but vcruntime140_1d.dll is still missing, that result does not rule out the problem. This DLL normally comes from Visual Studio, a debug framework package, or a test deployment, not from protected Windows system files.

If you are tired of repeating SFC and DISM without knowing what changed, Outbyte PC Repair can scan for system problems and show what it finds; its free scan identifies issues, while repair is completed by the full version.

Do not expect Windows Features to install this DLL

The Windows Features panel is not a source for the Visual C++ debug runtime.

You can open it through:

1. Open Control Panel.
2. Select Programs.
3. Select Turn Windows features on or off.
4. Review the available Windows components.

Features such as .NET components, legacy media support, or virtualization do not normally install vcruntime140_1d.dll. Turning unrelated features on and off is unlikely to repair this error.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Fix 7: Investigate a driver or vendor helper only when identified

There is no verified general association between vcruntime140_1d.dll and a particular Windows driver package. Do not reinstall every driver simply because a game or application fails.

A driver-related fix is justified when the requesting executable is clearly a vendor helper, control-panel component, hardware monitor, RGB utility, capture tool, or updater installed with a device package.

To inspect Device Manager:

1. Press Win + X.
2. Select Device Manager.
3. Expand the category for the affected hardware.
4. Right-click the device.
5. Select Properties.
6. Open the Driver tab.
7. Record the provider, date, and version.
8. Obtain the current package from the hardware manufacturer.
9. Install it using the manufacturer’s installer.
10. Restart Windows.
11. Test the helper application again.

Windows can also check for a driver update:

1. Right-click the device in Device Manager.
2. Select Update driver.
3. Select Search automatically for drivers.

If the helper executable itself was built as Debug, updating the device driver may not solve the problem. The vendor must provide a corrected Release utility.

If you do not want to hunt through device names and guess which of dozens of drivers is stale, Outbyte Driver Updater can show what its free scan identifies; the driver installation or repair is completed by the full version.

Fix 8: Do not use regsvr32 for this runtime DLL

regsvr32 is for self-registering COM and ActiveX DLLs that export registration functions such as DllRegisterServer. vcruntime140_1d.dll is a runtime library, not a COM server.

Running:

regsvr32 "C:\Path\To\vcruntime140_1d.dll"

does not install or repair the runtime. It normally produces an error stating that the module was loaded but the DllRegisterServer entry point was not found.

Microsoft documents the purpose of regsvr32 and the COM self-registration requirements. Use the command only when the software vendor specifically identifies a COM or ActiveX component that supports self-registration.

For this DLL, the executable loads the runtime through its import table. Registration is not part of the repair.

Fix 9: Use System Restore only after a known system change

System Restore is a last resort, not the first response to one missing application dependency.

Consider it when:

• The program worked immediately before a known Visual Studio, driver, Windows, or software change.
• The change removed a working development environment.
• A suitable restore point exists.
• Reinstalling the affected program or toolset did not help.

To open System Restore:

1. Open Control Panel.
2. Select Recovery.
3. Select Open System Restore.

You can also press Win + R, type:

rstrui.exe

and press Enter.

Choose a restore point dated before the problem began, review the affected programs, and allow Windows to restart. Microsoft states that System Restore rolls back system files, registry settings, installed programs, and drivers while normally preserving personal files. It does not guarantee that a missing debug runtime will be restored, so reinstalling the matching Visual Studio workload may still be necessary.

Why random DLL downloads are a bad fix

Do not download vcruntime140_1d.dll from a random DLL download website and copy it into a Windows folder.

That approach can fail because:

• The DLL may be the wrong x86, x64, or ARM64 architecture.
• It may belong to a different MSVC toolset.
• It may be corrupted or modified.
• It may be bundled with malware.
• It may only hide the missing installer or package dependency.
• It may cause a bad-image error instead of the original missing-file error.
• It does not fix a vendor shipping a Debug build when it should have shipped Release.

Use Visual Studio or Build Tools for development, the application’s official installer for consumer software, and Microsoft’s official Release Redistributable packages only for Release runtime dependencies.

Prevention for developers and software vendors

Before distributing a C++ application:

1. Build the final package using the Release configuration.
2. Use /MD for the normal Release runtime where appropriate.
3. Rebuild every linked library and plugin with compatible runtime settings.
4. Test the installer on a clean machine without Visual Studio installed.
5. Test both x86 and x64 packages when both are supported.
6. Keep debug builds restricted to development and test machines.
7. Do not place debug CRT files in a public installer.
8. Make the installer repair or reinstall its own application-local dependencies.
9. Verify that antivirus does not remove a legitimate packaged file.
10. Test launchers, helpers, crash reporters, and plugins separately from the main executable.

For an application user, the practical prevention step is to keep the original installer or launcher repair option available and avoid manually replacing runtime files.

FAQ

Is vcruntime140_1d.dll part of Windows

No. It is not a normal base Windows component. It is a Microsoft Visual C++ debug runtime DLL normally supplied by Visual Studio, Build Tools, a matching debug framework package, or a development/test deployment.

Is it part of the Visual C++ Redistributable

The ordinary Visual C++ Redistributable packages contain Release runtime files. Microsoft states that debug runtime DLLs are not redistributable, so the normal Redistributable is not the expected fix for vcruntime140_1d.dll.

What does the d mean

It means Debug. The file is intended for software built with debug runtime settings, commonly /MDd.

What is the difference between vcruntime140_1d.dll and vcruntime140_1.dll

vcruntime140_1d.dll is the Debug counterpart. vcruntime140_1.dll is the Release runtime. A Release Redistributable may provide the second file, but not normally the first.

Do I need both x86 and x64 packages

Only when you run applications of both architectures. A 32-bit program needs x86 runtime files even on 64-bit Windows. A 64-bit program needs x64 files. Windows architecture alone does not identify the application architecture.

Should I copy the file into System32 or SysWOW64

No. Copying a debug DLL into either folder can create architecture and toolset problems. Install the matching development environment or repair the application that requested it.

Can SFC or DISM fix it

Usually not. DISM and SFC repair protected Windows components. They do not normally install a Visual Studio debug DLL that was never installed. They are useful when other Windows files are also damaged.

Will regsvr32 fix it

No. This is a runtime library, not a COM or ActiveX server. It does not need registration.

Why are several files ending in d missing

A group containing vcruntime140_1d.dll, vcruntime140d.dll, msvcp140d.dll, or ucrtbased.dll strongly suggests that the program is a Debug C++ build. Install the matching development environment or obtain a proper Release build.

The file exists, but Windows says it is damaged. What now

Check the executable architecture, reinstall the complete toolset or application, and remove only application-local files as part of that documented reinstall. A file from a different toolset or architecture can exist and still be unusable.

What should I tell support if nothing works

Provide the application name, exact error text, Windows version, process architecture, installation source, recent changes, whether the error comes from the main executable or a launcher/helper, and the names of any other missing runtime DLLs. That information lets the developer determine whether the problem is a missing development environment, a bad package, quarantine, corruption, or an architecture mismatch.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.