Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSBuild C++ ... LNK1318: Unexpected PDB error; RPC (23) '(0x000006E7)' #829

Closed
drywolf opened this issue Jun 18, 2017 · 38 comments
Closed

Comments

@drywolf
Copy link

drywolf commented Jun 18, 2017

Expected behavior

Run MSBuild to compile a VC++ project file in windowsservercore

Actual behavior

LNK1318: Unexpected PDB error; RPC (23) '(0x000006E7)'

Information

I am trying to build some C++ programs in windows containers, therefore I'm using the latest windowsservercore image as a base and then I install the VC++ 2015 Build tools from here.

The Dockerfile looks something like this:

FROM microsoft/windowsservercore:latest

# install MSBuild & C++ build tools
RUN Invoke-WebRequest "http://go.microsoft.com/fwlink/?LinkId=691126" \
    -OutFile visualcppbuildtools_full.exe -UseBasicParsing ; \
    Start-Process -FilePath 'visualcppbuildtools_full.exe' -ArgumentList '/quiet', '/NoRestart' -Wait ; \
    Remove-Item .\visualcppbuildtools_full.exe

# MSbuild path
RUN $env:PATH = 'C:\Program Files (x86)\MSBuild\14.0\Bin;'+$env:PATH; \
[Environment]::SetEnvironmentVariable('PATH', $env:PATH, [EnvironmentVariableTarget]::Machine);

When I then try and run MSBuild on a VC++ .sln file...
(I reproduced this with just an empty Win32 Console App template)

msbuild VCppTestApp.sln /t:Rebuild /property:Configuration=Release

then I get the following error:

Microsoft Windows [Version 10.0.14393]
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.

Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 6/11/2017 6:56:42 PM.
Project "C:\j2v8\VCppTestApp\VCppTestApp.sln" on node 1 (Rebuild target(s)).
ValidateSolutionConfiguration:
  Building solution configuration "Release|x64".
Project "C:\j2v8\VCppTestApp\VCppTestApp.sln" (1) is building "C:\j2v8\VCppTestApp\VCppTestApp\VCppTestApp.vcxproj" (2) on node 1 (Rebuild target(s)).
CoreClean:
  Creating directory "x64\Release\".
PrepareForBuild:
  Creating directory "C:\j2v8\VCppTestApp\x64\Release\".
  Creating directory "x64\Release\VCppTestApp.tlog\".
InitializeBuildStatus:
  Creating "x64\Release\VCppTestApp.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe /c /Zi /nologo /W3 /WX- /sdl /O2 /Oi /GL /D NDEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Yc"stdafx.h" /Fp"x64\Release\VCppTestApp.pch" /Fo"x64\Release\\" /Fd"x64\Release\vc140.pdb" /Gd /TP /errorReport:queue stdafx.cpp
  stdafx.cpp
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe /c /Zi /nologo /W3 /WX- /sdl /O2 /Oi /GL /D NDEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Yu"stdafx.h" /Fp"x64\Release\VCppTestApp.pch" /Fo"x64\Release\\" /Fd"x64\Release\vc140.pdb" /Gd /TP /errorReport:queue VCppTestApp.cpp
  VCppTestApp.cpp
Link:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\j2v8\VCppTestApp\x64\Release\VCppTestApp.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:\j2v8\VCppTestApp\x64\Release\VCppTestApp.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /LTCG:incremental /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\j2v8\VCppTestApp\x64\Release\VCppTestApp.lib" /MACHINE:X64 x64\Release\stdafx.obj
  x64\Release\VCppTestApp.obj
  Generating code
  All 5 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
  Finished generating code
LINK : fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006E7)' [C:\j2v8\VCppTestApp\VCppTestApp\VCppTestApp.vcxproj]
Done Building Project "C:\j2v8\VCppTestApp\VCppTestApp\VCppTestApp.vcxproj" (Rebuild target(s)) -- FAILED.
Done Building Project "C:\j2v8\VCppTestApp\VCppTestApp.sln" (Rebuild target(s)) -- FAILED.

Build FAILED.

"C:\j2v8\VCppTestApp\VCppTestApp.sln" (Rebuild target) (1) ->
"C:\j2v8\VCppTestApp\VCppTestApp\VCppTestApp.vcxproj" (Rebuild target) (2) ->
(Link target) ->
  LINK : fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006E7)' [C:\j2v8\VCppTestApp\VCppTestApp\VCppTestApp.vcxproj]

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:09.17
@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@waltronix
Copy link

I have the same issue.
Is there any progress on that topic?

@philippslang
Copy link

/lifecycle frozen

@cowlinator
Copy link

cowlinator commented May 15, 2018

I am experiencing this issue with docker 18.03.1-ce, build 9ee9f40 .
The image was built with a Dockerfile, and is based on microsoft/windowsservercore 10.0.14393.2125.
The dockerfile downloaded VS Build Tools 2017 from https://download.visualstudio.microsoft.com/download/pr/10674754/e64d79b40219aea618ce2fe10ebd5f0d/vs_BuildTools.exe and installed with --quiet --nocache --norestart --wait --addProductLang en-US --locale en-US --add Microsoft.VisualStudio.Workload.VCTools --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add Microsoft.VisualStudio.Component.Windows10SDK.15063.Desktop --add Microsoft.VisualStudio.Component.Windows81SDK --add Microsoft.VisualStudio.Component.VC.140 --add Microsoft.Net.Component.4.6.1.SDK --add Microsoft.Component.VC.Runtime.UCRTSDK.
MSBuild reported Build Engine version 15.6.85.37198
The vc++ project builds correctly outside of a docker container.

@philippslang
Copy link

/remove-lifecycle stale
/remove-lifecycle frozen

@cowlinator
Copy link

cowlinator commented Jun 14, 2018

This bug only appears when using a hyper-v container and building from a bind mount.
I have found 3 workarounds for this bug:

Workaround A:
If your host OS is Windows Server 2016, you can work around this bug by using docker run --isolation=process.

Workaround B:

  1. Change the Debug Information Format to None or C7 compatible (/Z7) in the project properties dialog for each project. (Alternately, in the .vcxproj xml, change the value of the DebugInformationFormat tag to None or OldStyle)
  2. Add the /property:_IsNativeEnvironment=true argument to the build step (e.g. msbuild solution.sln /property:_IsNativeEnvironment=true)

Workaround C:
Move your source code into the container. (no bind mount points / no volumes)

@atomaras
Copy link

atomaras commented Jul 12, 2018

I am experiencing the same issue.

@kfsone
Copy link

kfsone commented Jul 26, 2018

I experience this with VS2017 15.6.7 without using Docker. Each time it seems to be the result of changing one or both of branch and configuration I'm building from (e.g Trunk / Debug -> Live / RelWithDebInfo)

@kfsone
Copy link

kfsone commented Jul 26, 2018

Actually, this appears to be a problem with the behavior of link.exe when mspdbsrv.exe isn't running before hand and parallel links happen.

  1. First link.exe spawns an mspdbsrv,
  2. Other link.exes attach to it,
  3. First link.exe ends and shuts down mspdbsrv,
  4. Other link.exes don't handle this case and fail horribly.

@kaizenman
Copy link

I am experiencing the same issue. Any updates?

@vasokot
Copy link

vasokot commented Oct 2, 2018

I am experiencing the same issue.

1 similar comment
@apetrozzelli
Copy link

I am experiencing the same issue.

@kingofthebongo2008
Copy link

I have the same issue.

@gureedo
Copy link

gureedo commented Dec 26, 2018

Same issue, experiencing only when working in volume directory.

@eckertj
Copy link

eckertj commented Jan 10, 2019

Experiencing the same. If I copy the project from the volume to another folder inside the container, I can successfully compile it.

@sqeezy
Copy link

sqeezy commented Jan 10, 2019 via email

@MrSapps
Copy link

MrSapps commented Jan 21, 2019

I have this issue too, also solved by moving the code into the container, not ideal due to it taking so long to copy over.

@jeking3
Copy link

jeking3 commented Feb 7, 2019

It is definitely the result of trying to link using a bind mount. Just confirmed it.
Version 2.0.0.2 (30215) Engine 18.09.1

@antoxar
Copy link

antoxar commented Feb 14, 2019

Issue reproduces only if build directory is in mounted volume.

Solution is, place your source code and cmake_install_prefix in mounted volume. Build directory must be located inside container.

@mcannall
Copy link

Same issue here, the whole point is to build in the volume. Why would that make a difference?

@jeking3
Copy link

jeking3 commented Mar 11, 2019

Who wants to copy all their code into the container? This is why the ability to mount volumes exists, and it's a serious bug.

@Issafalcon
Copy link

We're migrating our entire CI system at the moment to docker, and this issue is quite a major headache for our cmake and C++ project builds when we need to run certain builds with debug output.

We managed a release build of our C++ projects by ensuring that the project properties in Visual Studio under Configuration Properties > Linker > Debugging had 'Generate Debug Info' set to No. Similar to the workaround mentioned previously.

@cowlinator
Copy link

If it is helpful, here is a means for implementing that workaround without changing the project files: https://gist.github.com/cowlinator/1b6ea106502b1027fe65bd2b11770d9a

@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@mcannall
Copy link

mcannall commented Jun 11, 2019 via email

@MrSapps
Copy link

MrSapps commented Jun 17, 2019

This seems like there is something fundamentally wrong with the underlying file abstraction? Will this ever at least be investigated to figure out what the cause and other possible knock on effects are?

@ssrobins
Copy link

I posted reproduction steps for a LINK : fatal error LNK1318: Unexpected PDB error; UNKNOWN (24) for the Visual Studio team:
https://developercommunity.visualstudio.com/content/problem/607325/lnk1318-unexpected-pdb-error-when-building-from-a.html

Hopefully basic reproduction steps along with a Dockerfile that installs the Visual Studio Build Tools will help someone get to the bottom of this.

If there's anything I can do to help reproduce this, let me know.

@SteffenL
Copy link

SteffenL commented Jun 21, 2019

Haven't seen UNKNOWN (24) before but I started getting the same RPC (23) code after upgrading Windows 10 from 1809 to 1903, and a fresh install didn't help. I build C++ projects with VS 2017 in Windows containers based on a custom image based on AppVeyor's image, orchestrated by AppVeyor Server running on a host machine running Windows 10 Pro. Problem disappeared when I reverted to my backup of Windows 10 1809. Not sure what AppVeyor Server does but at least the container pulls all code and dependencies into itself.

@solvingj
Copy link

solvingj commented Jul 15, 2019

Indeed, this is still a serious issue. I never saw it until I moved to 1903.

@shrgabor
Copy link

I have te same problem with Docker 2.0.0.3, Engine 18.09.2 on Windows 10 version 1903.
Copying everything to the container instead of attaching as volume worked, but a solution would be more than welcomed.

@darkvertex
Copy link

I had the same issue with Docker on Windows 10.

Using --isolation=process "fixed" the issue for me. It would be nice if it just worked out of the box.

@MrSapps
Copy link

MrSapps commented Nov 5, 2019

YongKang Zhu [MSFT]
17 hours ago
We found one Windows File I/O API that mspdbsrv.exe calls doesn't working inside container and have put in a fix to work around that. Could you try VS 2019 16.4 Update release and see whether the problem is gone?

from https://developercommunity.visualstudio.com/content/problem/145618/msbuild-linkexe-hangs-inside-container.html?childToView=806109#comment-806109

@SteffenL
Copy link

SteffenL commented Nov 5, 2019

I am also quite interested to know whether 16.4 solves the problem but I also hope that they can fix the root cause of the problem in Windows (or in Docker) itself so that we can use earlier versions of Visual Studio as well. At least in my case, I had no problems with that before Windows 10 1903.

@MrSapps
Copy link

MrSapps commented Nov 6, 2019

YongKang Zhu mentions a specific API that causes the issue - could be worth asking them what API it is so the root cause can be fixed.

@ssrobins
Copy link

ssrobins commented Dec 6, 2019

I posted reproduction steps for a LINK : fatal error LNK1318: Unexpected PDB error; UNKNOWN (24) for the Visual Studio team:
https://developercommunity.visualstudio.com/content/problem/607325/lnk1318-unexpected-pdb-error-when-building-from-a.html

Hopefully basic reproduction steps along with a Dockerfile that installs the Visual Studio Build Tools will help someone get to the bottom of this.

If there's anything I can do to help reproduce this, let me know.

My similar issue is not solved with 16.4, but the error changed. I posted an update in the quoted link.

@solvingj
Copy link

solvingj commented Feb 19, 2020

This is not fixed for hyperv isolation mode as of MS Build tools 16.4.4

I believe the "PDB-related" error is fixed (potentially as early as 16.4.0). I believe there is a new issue as suggested by @ssrobins

I also believe that this specific issue could be deemed "not a docker issue", but an issue with some programs that use certain file API's which do not work:

  • in docker
  • && on mounted directories only
  • && when docker is in hyperv isolation mode only

Perhaps if these API's could someday be made to work in this scenario, then this entire category of issue might be fixable by windows/docker teams. However, it might be similar to Mapped Network Drives, for which there's a huge number of applications that simply will never work the same as native directories on native volumes (presumably for similar reasons).

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Jun 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests