0

There are many questions on the Internet for "missing mspdb140.dll", and other similar questions about missing "mspdb*" DLLs. There are a few different solutions posted about it, including:

  • reinstall Visual Studio
  • Remove mspdb140.dll, it should be included with the PATH variable
  • Add mspdb140.dll (and other files) to <msvc-install-dir>\<subpath>

In my case, I have used the build tools for msvc 2019 installer in a docker container, and then installed both build tools for msvc 2017 and 2019. If I then go to C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64, there are two folders: x64 and x86. If I write the powershell command ls -Recurse -Filter "*mspdb*", I get the following output:

Directory: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64
  mspdb140.dll
  mspdbcmf.exe
  mspdbcore.dll
  mspdbsrv.exe
  mspdbst.dll

Directory: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\1033
  mspdbcmfui.dll

There is none of these files in the HostX64\x86 directory though. If I build with x64 as target everything goes fine, but with x86 as target, both the release and debug build gets error. The release build has:

ERROR: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x86\cl.exe
...
c1xx: fatal error C1356: unable to find mspdbcore.dll

and the debug build has:

ERROR: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x86\cl.exe
...
c1xx: fatal error C1356: unable to find mspdb140.dll

These builds are using Qt and Qbs, and Qbs uses vcvarsall.bat to find the environment variables needed. There is a bug in Qbs when having multiple installed msvc toolchains, which makes Qbs always choose the newest one. To work around this, I manually move vcvarsall.bat and replace it with this in each build job:

call %~dp0vcvarsall_real.bat %1 store 10.0.17134.0 -vcvars_ver=14.16.27023 || exit /b 1

This forces vcvarsall to choose the toolchain 14.16.27023 that I want.

I managed to fix both of the compilation errors by simply copying the DLL and EXE files that exists for the x64 target, except mspdbcmfui.dll. There is no reason for not copying that last DLL, as I am just experimenting. Even though the program compiles, I don't really know what I'm doing, where these files are used, or why they are missing for some targets! It would feel better to not have to manually copy files in my build environment.

I also checked my local installation of Visual Studio 2017 Professional, and then I have the same name of the files for HostX64\x64, but for HostX64\x86 I get this output:

C:\Program Files (x86)\Microsoft Visual Studio\2017\WDProfesional\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x86
...
mspdb140.dll
mspdbcore.dll

Only two of the DLLs!

In the docker image, I also have the build tools for MSVC 2019, and there all of the host and target combinations have all of the DLLs and EXEs.

To summarize:

  • Why are there missing DLLs in some cases
  • What is the correct way of fixing this?
  • How does Visual Studio compile differ from using vcvarsall.bat and external tools, as it is clearly able to compile without copying DLLs/EXEs!
MrBerta
  • 2,457
  • 12
  • 24
  • Might be relevant: https://developercommunity.visualstudio.com/content/problem/325122/c1356-unable-to-find-mspdbcoredll.html – Richard Critten Oct 21 '19 at 12:13
  • Thanks, it looks like they might have fixed it then. I checked my version of Visual Studio 2017, and I am running 15.9.13. In the link that you posted, they say that this should have been fixed in version 15.8. It is either some trouble with my installation or it is not properly fixed. – MrBerta Oct 21 '19 at 12:49

1 Answers1

0

I still hope that someone can explain more about why these files exist, how to use them properly, why they are missing in some places, and how Visual Studio seems to be able to compile even with the missing files. In the mean time, I found this:

I have installed the build tools for MSVC 2019, so I went to the folder C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64 and ran the following powershell command:

(ls -Recurse "mspdb*").FullName | % { Get-FileHash $_ } | Sort-Object -Property Hash

And got this output:

Hash                                                                   Path
--------------------------------------------------------------------------------------------------------------------------------------------
658D21DF98781D7C137FA213C3F3C2222C5D20A0F75BEB4929703406241379FA       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbcmf.exe
658D21DF98781D7C137FA213C3F3C2222C5D20A0F75BEB4929703406241379FA       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbcmf.exe
9664EE9A457B444E0D5A2F6A73A896375966BCF3864BBCD6B76AFEF496EC954C       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbcore.dll
9664EE9A457B444E0D5A2F6A73A896375966BCF3864BBCD6B76AFEF496EC954C       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbcore.dll
A056C5CC109CB6BFABBA3982E5739B57C2C6AEBEBDF41FB6DD17586ED4FA7F13       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbsrv.exe
A056C5CC109CB6BFABBA3982E5739B57C2C6AEBEBDF41FB6DD17586ED4FA7F13       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbsrv.exe
C48FC0A0BE36C70974CD180DD0DB22BB1EA84585BBE0B23583C6FEDCAEA0C76F       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\1033\mspdbcmfui.dll
C48FC0A0BE36C70974CD180DD0DB22BB1EA84585BBE0B23583C6FEDCAEA0C76F       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\1033\mspdbcmfui.dll
E6F6DF7DAD04699078D14D02BA57A19E332367507B860E03356AF2EEA86C3D68       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdb140.dll
E6F6DF7DAD04699078D14D02BA57A19E332367507B860E03356AF2EEA86C3D68       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdb140.dll
ECC40C0574AC6B93E3ACFC3EB95882D5391A2AC10E9ACC4444D418E5D5014135       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbst.dll
ECC40C0574AC6B93E3ACFC3EB95882D5391A2AC10E9ACC4444D418E5D5014135       C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbst.dll

All of the files that start with mspdbare exactly the same between x86 and x64 as the target. If I try the same in the Hostx86 folder, the files are also exactly the same between the targets, but different compared to the other host.

I think that it should be safe to re-use these files for different targets for the same host for MSVC 2017 as well. My compilation succeeds after copying these files, so it can't be completely wrong!

MrBerta
  • 2,457
  • 12
  • 24