A Windows application may fail before its main window appears and show a message that VCRUNTIME140.dll or MSVCP140.dll is missing. The filename looks specific enough to invite a quick search and a one-file download.
That is usually the wrong recovery model.
These DLLs belong to the Microsoft Visual C++ runtime family. The safer fix is to identify the failed architecture and repair the supported runtime package, not to copy an unknown DLL into System32 or the application folder.
Start by recording the exact error
Take note of:
- the complete DLL filename;
- whether Windows reports “missing,” “not found,” or “unable to start correctly”;
- the application path;
- whether the failure appeared after an update or a clean install;
- the Windows system type.
VCRUNTIME140.dll, VCRUNTIME140_1.dll, and MSVCP140.dll are related, but they are not interchangeable names for the same file.
Check whether the application is x86, x64, or ARM64
A 64-bit Windows installation can run both 64-bit and 32-bit applications. That means a 64-bit computer may legitimately need both the x64 and x86 Microsoft Visual C++ Redistributable packages.
Do not assume “64-bit Windows” means only the x64 runtime matters. The application architecture determines which runtime it loads.
On ARM64 devices, compatibility introduces another layer. Record the device architecture and obtain the runtime packages through Microsoft's current supported distribution path.
Do not download a standalone DLL from a file archive
Copying a single DLL from an unknown site creates several problems:
- The file may be modified or malicious.
- Its version may not match the rest of the runtime.
- The architecture may be wrong.
- The copied file may hide the original installer or component problem.
- Future updates can leave the machine with an inconsistent set of binaries.
A DLL error is evidence about a dependency. It is not an instruction to source that dependency as an isolated file.
Inspect the installed redistributables
Open Settings → Apps → Installed apps and look for Microsoft Visual C++ Redistributable entries. Record the year/range, architecture, and version.
Do not remove every entry to “start clean.” Different applications can depend on different supported runtime generations. Removing all packages may break unrelated software.
If the required current package is present, use its repair option when available. Restart the affected application and test again before making another change.
Install or repair through Microsoft's supported package
Use Microsoft's current Visual C++ Redistributable page or the affected application's verified installer. Match the package architecture to the application:
- x86 for 32-bit applications;
- x64 for 64-bit applications;
- ARM64 where the application and system require it.
Close the affected program before repair. After installation, restart Windows if the installer requests it.
Verify the failure stage
A runtime error that appears before the main window belongs to the dependency-loading stage. It is different from:
- a blank content area after the window opens;
- a setup wizard that rolls back;
- an application process that remains running but shows no window;
- an installer blocked by Smart App Control or SmartScreen.
Keeping these stages separate prevents unrelated fixes from being applied to the same vague symptom: “the app will not open.”
Check Windows integrity only when evidence points there
If several unrelated applications report missing system components, or runtime repair fails with Windows servicing errors, system integrity may be involved.
Use built-in servicing tools from an elevated terminal only after recording the original error. Avoid third-party “DLL repair” utilities that change many components without producing a clear audit trail.
Retest with a fixed baseline
After repairing one runtime package:
- restart the same application;
- check whether the original DLL message disappears;
- confirm the main window opens;
- close the program normally;
- launch it a second time;
- check Event Viewer only if the error changes or the process still exits.
If the DLL message disappears but a blank window appears, the runtime dependency may be fixed and a separate rendering issue is now visible.
I used Youdao Translate as the concrete Chinese-language case for this diagnostic sequence. The full walkthrough distinguishes x86/x64 packages, repair order, unsafe standalone DLL downloads, and post-repair verification: VCRUNTIME140.dll and MSVCP140.dll troubleshooting on Windows.
The practical rule is simple: repair the package that owns the dependency. Do not treat a missing runtime component as a request to collect individual DLL files from the web.
Top comments (0)