有道翻译下载后提示 VCRUNTIME140.dll 或 MSVCP140.dll 缺失：Visual C++ 运行库修复

有道翻译启动时直接提示 VCRUNTIME140.dll 或 MSVCP140.dll 缺失，先别去网上找单个DLL。我处理这种报错时，会先把完整弹窗留下来，再检查Windows当前安装的Microsoft Visual C++运行库。真正需要解决的通常不是“找一个同名文件塞进去”，而是对应架构的运行时没有正常安装、现有组件损坏，或者软件目录里残留了以前人工复制的DLL。

这类错误和“安装程序双击没反应”“客户端打开后白屏”“窗口一闪就退出”不是同一条故障链。Windows已经明确点名VCRUNTIME140.dll或MSVCP140.dll时，先围绕运行库和应用架构排查，范围越小，越容易判断到底哪一步有效。

快速通道

👉 弹窗已经明确写出VCRUNTIME140.dll或MSVCP140.dll？先打开【程序和功能】检查现有Visual C++运行库。已有对应组件就先修复；确实缺少时，再从Microsoft官方页面安装正确架构的v14 Redistributable。不要单独下载DLL，也不要直接复制进System32、SysWOW64或有道翻译安装目录。

先确认现在真的是运行库报错

现在看到的情况	更可能是哪一层	先做什么
明确提示VCRUNTIME140.dll缺失	Visual C++运行时加载异常	继续本文检查运行库
明确提示MSVCP140.dll缺失	Visual C++ C++标准库运行时加载异常	继续本文
出现0xc000007b，但没有点名VCRUNTIME或MSVCP	可能是架构或其他依赖加载问题	先记录完整错误，再看事件日志
窗口一闪就退出，没有DLL弹窗	启动崩溃	转查事件ID 1000/1001
窗口正常出现，但中间内容一直白屏	更接近WebView2渲染问题	转入白屏排查
安装程序双击后完全没有窗口	安装器启动或安全执行问题	不要先修Visual C++

如果连问题发生在哪个阶段都还不能确定，可以先看有道翻译安装失败或打不开的分阶段判断。需要重新确认Windows客户端入口时，再回到有道翻译下载页面。

第一步：先把完整错误弹窗留下来

别只记住“缺DLL”。先截一张完整弹窗，至少确认下面几项：

• 报错的是哪个程序；
• 具体点名VCRUNTIME140.dll、MSVCP140.dll还是其他DLL；
• 有没有0xc000007b、0xc000012f之类附加错误码；
• 有没有“无法继续执行代码”“找不到指定模块”“不是为在Windows上运行而设计”等文字；
• 发生错误的大概时间。

明确写着“找不到VCRUNTIME140.dll”或“找不到MSVCP140.dll”，Visual C++运行库当然应该优先检查。但0xc000007b本身不能证明一定是Visual C++运行库缺失。它只是说明应用启动时的依赖加载没有正常完成，后面还需要结合实际故障模块判断。

先把原始错误保存下来再动系统。否则处理以后错误表现发生变化，就很难知道到底是哪一步改变了结果。

第二步：确认Windows架构，但别只看“64位”三个字

打开【设置 → 系统 → 系统信息】，查看“系统类型”。

这里最容易犯的错误是：

电脑是64位Windows，所以只安装x64运行库。

实际上，64位Windows仍然可以运行32位程序。一个桌面软件也可能包含不同架构的组件，因此系统位数和应用组件位数不能直接画等号。

当前环境	正确理解
32位Windows	只能运行对应的x86应用和运行库
64位Windows上的64位应用	需要x64运行库
64位Windows上的32位应用或组件	仍然需要x86运行库
ARM64 Windows	先确认应用实际架构，不要因为设备是ARM64就直接套用DLL修复

如果ARM64设备当前没有出现VCRUNTIME140.dll或MSVCP140.dll弹窗，而是直接提示“此应用无法在你的电脑上运行”，说明当前问题已经不属于本文的明确DLL缺失现场，应先回到系统架构和安装兼容性方向排查。

第三步：看看电脑里已经装了哪些Visual C++组件

按Win + R，输入：

appwiz.cpl

进入【程序和功能】，查找Microsoft Visual C++ Redistributable。

一些电脑的列表里仍可能看到类似：

Microsoft Visual C++ 2015-2022 Redistributable (x64)

Microsoft Visual C++ 2015-2022 Redistributable (x86)

不要为了名称里的年份和网上截图不一样就卸载。Microsoft的v14 Redistributable会持续更新，真正要看的不是标题是否完全一致，而是：

• 对应架构的Redistributable是否存在；
• 能不能正常进入维护界面；
• 维护程序有没有提供“修复”；
• 修复过程能不能正常完成。

Microsoft当前最新受支持的v14 Redistributable覆盖Visual Studio 2017、2019、2022和2026工具链，而且会持续更新，所以没有必要为了VCRUNTIME140.dll这个文件名，专门寻找多年以前的旧版运行库。

第四步：已经有运行库，先尝试修复

如果对应Visual C++ Redistributable已经存在，我不会第一步就卸载。

选中对应项目，点击【更改】或【修改】。维护程序如果提供Repair / 修复，先执行修复。

完成以后重启Windows，再测试有道翻译。

如果Windows是64位，可以同时查看x64和x86组件是否存在，但不要因为“两个都看见了”就机械地全部重装。当前错误明确和哪个架构有关，就优先处理哪一个；暂时无法判断时，先保留现状，再结合应用自身架构和事件日志确认。

更不要为了“彻底干净”，把2010、2012、2013以及其他Visual C++运行库全部卸载。同一台电脑同时存在多个年代和多个架构的Redistributable很正常，其他程序可能仍然依赖它们。

第五步：确实缺少组件，再从Microsoft安装

如果对应运行库完全不存在，或者现有维护程序无法正常修复，再进入Microsoft当前的Visual C++ Redistributable下载页面。

官方目前提供的v14安装程序主要有：

应用目标架构	对应安装程序
x86	vc_redist.x86.exe
x64	vc_redist.x64.exe
ARM64	vc_redist.arm64.exe

Microsoft当前要求Redistributable架构与应用目标架构匹配。最新x64安装包在ARM64设备上还同时包含ARM64和x64二进制文件，但这也不等于所有ARM64设备上的应用都应该不分情况安装同一个包。

这一篇最重要的禁区，就是不要单独下载VCRUNTIME140.dll或MSVCP140.dll。

同一个DLL文件名可能存在不同架构和不同内部版本。把来源不明的同名文件手工复制到：

C:\Windows\System32

C:\Windows\SysWOW64

有道翻译安装目录

都有可能让原来的“缺少文件”变成新的模块加载错误。

使用Microsoft官方Redistributable安装完整运行时，文件版本、架构、维护和后续更新才会保持在正常机制里。

第六步：处理完成后重新验证

修复或安装完成以后，重启Windows。

重新登录后，只启动一次有道翻译，先看原来的DLL弹窗有没有消失。

如果正常进入主窗口，我会这样再确认一次：

1. 正常退出客户端；
2. 等待几秒；
3. 重新启动；
4. 确认原DLL弹窗没有再次出现。

这里的两次启动只是为了排除一次偶然成功，并不是Microsoft或有道规定的固定验证次数。

如果DLL错误已经消失，但客户端打开以后变成内容区域白屏，就不要继续折腾Visual C++运行库，直接转到有道翻译白屏与WebView2排查。

运行库已经正常，错误还在，再看事件日志

如果对应运行库已经存在，也完成了修复，但启动错误完全没有变化，再按Win + R输入：

eventvwr.msc

进入【Windows日志 → 应用程序】，按照刚才启动失败的时间查看记录。

PowerShell也可以快速筛最近10分钟的相关事件：

Get-WinEvent -LogName Application -MaxEvents 100 |
Where-Object {
    $_.TimeCreated -gt (Get-Date).AddMinutes(-10) -and
    $_.ProviderName -in 'SideBySide','Application Error'
} |
Select-Object TimeCreated,ProviderName,Id,Message

重点不是看到哪个DLL名字就去替换，而是看故障模块的实际路径。

日志里看到什么	接下来怎么判断
仍然明确指向Visual C++或SideBySide相关组件	重新核对应用架构和运行库维护状态
指向有道翻译安装目录中的VCRUNTIME或MSVCP文件	检查是不是以前人工复制进去的副本
故障模块是有道翻译自身文件	停止继续修改系统DLL，转查客户端自身
只剩0xc000007b，但没有明确VC运行库证据	根据实际故障模块继续排查，不再默认运行库就是根因

官方运行库已经修好，弹窗却完全没变

先检查软件目录里有没有人工放进去的同名DLL

这是很容易漏掉的一步。

Windows里已经装好官方Redistributable，不代表程序一定会使用系统里的正确副本。如果有道翻译安装目录里以前被人工放进了一个旧版或错误架构的VCRUNTIME140.dll、MSVCP140.dll，程序仍然可能优先加载那个文件。

如果发现这种来源不明的副本，先记录文件名、路径和来源。确认确实是以前人工添加的文件以后，再移除人工副本，并使用完整客户端恢复程序目录。

不要把这个动作扩展到Windows系统目录。 系统原有文件不要凭感觉删除。

DLL缺失没了，却变成0xc000007b

这种变化说明错误表现已经变了，不能继续按“缺DLL”原样重复修复。

先确认：

• 有没有手工放过第三方DLL；
• 对应架构的Redistributable是否正常；
• 事件日志指向哪个具体模块；
• 是不是只有有道翻译出错，还是多个软件同时异常。

如果只有有道翻译失败，而且故障模块始终位于它自己的安装目录，优先检查客户端文件，不要继续批量修改Windows运行库。

两个最容易把问题修复杂的操作

从DLL下载站直接找VCRUNTIME140.dll

这是最容易让问题变复杂的做法。

真正需要的是完整运行时依赖，不是一只孤立的同名文件。DLL版本或架构放错以后，后续错误反而更难判断。

把所有Visual C++ Redistributable一次全部卸载

也不建议。

其他软件可能仍然依赖不同年代和不同架构的Visual C++组件。处理一个有道翻译错误时，只动当前故障真正需要的部分，后面才知道到底是哪一步起作用。

最后检查一遍

• ☐ 已保存完整错误弹窗和DLL名称。
• ☐ 已确认Windows系统类型，但没有直接把系统位数等同于应用架构。
• ☐ 已检查本机现有Visual C++ Redistributable。
• ☐ 已优先尝试修复现有对应组件。
• ☐ 确实缺少时，只从Microsoft获取官方v14 Redistributable。
• ☐ 没有从第三方网站单独下载DLL。
• ☐ 没有把未知DLL复制进System32、SysWOW64或软件目录。
• ☐ 处理完成以后已经重启并重新测试。
• ☐ 错误表现改变以后，已经按新的弹窗和日志重新判断。

常见问题

64位Windows为什么还可能看到x86运行库？

因为64位Windows能够运行32位程序。操作系统位数和应用组件位数并不是一回事，所以看到x86 Redistributable并不代表装错了。

可以直接下载VCRUNTIME140.dll放到有道翻译目录吗？

不建议。单个DLL可能存在架构或版本不匹配，也不受正常Redistributable维护。正确方式是修复或安装Microsoft官方Visual C++ v14运行库。

Visual C++已经安装，为什么仍然提示MSVCP140.dll缺失？

先确认对应架构的组件是否正常，再尝试维护程序的“修复”。如果完全没有变化，检查有道翻译目录里有没有以前人工加入的同名DLL，并按启动时间查看SideBySide或Application Error记录。

需要专门下载安装很老的Visual C++ 2015吗？

不要只因为文件名里有“140”就去寻找一个多年前的旧安装包。Microsoft当前建议使用最新受支持的v14 Redistributable；当前v14覆盖Visual Studio 2017、2019、2022和2026工具链。

参考来源

• 
  网易有道翻译桌面端下载与更新记录
  
• 
  Microsoft Learn：最新支持的 Visual C++ 可再发行程序包下载