C++ 调试：MSVCP140D.dll 未设计为在 Windows 上运行

Question

我正在尝试调试我在 Visual Studio 2017 Professional 中接管源代码的 C++ 程序。我可以在“Release x64”配置中构建应用程序，并且它执行得很好。

即使我在 Release 模式下执行它，它也会注意断点。但在逐步执行期间，尽管条件计算结果为

if

，指标仍会进入

false

分支的一行，然后继续按预期在分支后面运行（具有讽刺意味的是，指标假定将执行的行是

exit

语句，所以它肯定是不执行）。我猜想一些自动缩进导致调试符号与源代码不同步。这就是为什么我想刷新符号或在实际的“调试”配置中执行代码。

但是，当我将启动配置切换为“调试 x64”并尝试运行该项目时，它给了我一个“错误图像”错误：

C:\WINDOWS\SYSTEM32\MSVCP140D.dll 要么不适合在 Windows 上运行，要么包含错误。尝试使用原始安装介质再次安装该程序，或者联系您的系统管理员或软件供应商以获得支持。错误状态 0xc000012f。

据我所知，“MSVCP140D”代表该 dll 的“Microsoft Visual C++ v140 Debug”版本。该 dll 并没有丢失，事实上我的机器上有 6 个位置：

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Redist\MSVC\14.16.27012\debug_nonredist\x64\Microsoft.VC141.DebugCRT\msvcp140d.dll
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Redist\MSVC\14.16.27012\debug_nonredist\x86\Microsoft.VC141.DebugCRT\msvcp140d.dll
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Redist\MSVC\14.16.27012\onecore\debug_nonredist\x64\Microsoft.VC141.DebugCRT\msvcp140d.dll
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Redist\MSVC\14.16.27012\onecore\debug_nonredist\x86\Microsoft.VC141.DebugCRT\msvcp140d.dll
C:\Windows\System32\msvcp140d.dll
C:\Windows\SysWOW64\msvcp140d.dll

“使用 C++ 进行桌面开发”工作负载据说是由 VS Installer 完全安装的（声称自己是最新版本 1.18.1100.314）。我通常使用 C# 进行编程，所以我不熟悉项目设置交互的方式，并且我注意到了几件事，但我不确定其中是否与我的问题有关：

1. 平台工具集是“Visual Studio 2017 (v141)”。
2. 唯一包含看起来像上面提到的 4 个“redist”路径之一的路径的宏是

   $(DebugCppRuntimeFilesPath)

   宏，它不属于“VC++ 目录”设置中任何条目的一部分。
3. 当 dll 位于“.. ..16.270

   12

   \...”。目录“14.16.27023”不存在。 第3点对我来说似乎是最有希望的提示，但我不知道更高的版本号来自哪里，在项目或安装中如何更改或影响它，等等。

更新：

我现在还尝试下载 VS 2019 安装程序（版本 2.0.3297.403），看看是否为 VC++ 工作负载提供任何更新，但显然没有。

Hans Passant 表示该错误代码表示

$(DebugCppRuntimeFilesPath)

Answer 1

我检查了

C:\Windows\System32\

中的dll（981,552字节，未签名，仅填充了文件属性详细信息选项卡上的一些条目）与VS分发的DLL（981,744字节，签名，文件属性详细信息选项卡上的完整信息）确实不同）。因此，我决定将

System32

中当前的“msvcp140d.dll”重命名为“msvcp140d_orig.dll”，然后将

System32

中的“msvcp140d_orig.dll”复制过来。现在调试工作了。我并不是 100% 相信 VS 应该使用

that

文件，而不是首先随工作负载分发的文件，但至少我的问题得到了解决，并且我可以调试代码。