We are seeking ideas on resolving a problem with linking/pdb generation when running multiple devenv.com using Visual Studio 2005.
We are getting the following intermittently errors when doing parallel builds using devenv.com.
I.e. when the following get run at the same time on the same build server:
devenv.com master.sln /build "Release|Win32"
devenv.com master.sln /build "Debug|x64"
fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006BA)'
error C2471: cannot update program database
We want the pdb files, so turning them off isn't realy an option.
Running the builds serially doesn't cause the issue, but of course slows down the build process.
References found so far indicate
that there are issues with length of file names exceeding the 256 file path limit, this doesn't seem to be our problem as we can build individually, and the path+filename length is around 160 chars.
there are issues with incremental builds (but mainly in Visual Studio 2008) and we have incremental linking turned off.
We are looking for input on resolving this multiple process issue, if possible.
How do we resolve it?
Try enabling source-code parallel builds instead. That will efficiently use all cores on your server, unless you have more cores than source files in your solution. Here is more information on how you have enable source-code parallel builds: http://vagus.wordpress.com/2008/02/15/source-level-parallel-build-in-visual-studio-2005/
this may be a related problem&solution, because it produces
Unexpected PDB error; RPC (23) '(0x000006BA)'
https://software.intel.com/en-us/articles/unexpected-pdb-error-rpc-23-0x000006ba/
Related
We have a large solution (~200 projects) that is being built on an on-premise build agent (TFS 2015) and are seeing some random build failures at the msbuild step with an error like this:
C:\Program Files (x86)\Microsoft Visual
Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets
(4384, 5) Unable to copy file
"C:\Work\100\s\Code\packages\MSTest.TestFramework.2.1.1\lib\net45\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.xml"
to
"..\bin\Debug\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.xml".
Access to the path
'..\bin\Debug\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.xml'
is denied.
The error seems to occur randomly and typically if we run the build again it completes without error. As this is a continuous integration build we'd like to resolve the problem so it only fails for legitimate reasons. Developers on the team are getting too used to seeing build failures and are starting to miss legitimate failures with tests not passing!
The file itself is not being held open by any other process before the build starts (we are performing a clean get so it does not exist prior to the build starting) or after the build completes (have logged on to the server after a failed build and confirmed it is not held open by anything) so it appears to be the build process itself that is transiently holding the file open. My assumption is that, as we have multiple test projects in the solution referencing the test framework and all projects are set to use a common output folder, when they are being built in parallel there is a race condition and one project being built is holding open/writing to the file at the same time another wants to copy the file over.
We don't want to disable parallel builds if possible as this will add a significant amount of time to the build process, which is already a lot longer than I'd like.
I had considered turning off the copy local option on all but one of the projects but the error is related to an XML file rather then the DLL file that is being referenced.
So my questions would be:
Is my assumption correct that this would be caused by parallel builds or is there another reason it might be happening?
Why are the XML files being copied to the output folder in the first place?
Can the copying of the XML files be suppressed in any way as I don't think we actually need them there?
If we are unable to suppress copying the XML files are there any alternative ways that we could stop the error from occurring?
Thanks in advance for any help/advice.
I have a couple of build definitions for continuous integration running on VSO using an on-premises server. The thing is that sometimes they fail because Microsoft.WindowsAzure.targets was not able to copy some files when building the Azure projects (while building locally, both using VS or MSBuild, works always).
The basic structure of my solution is as follows:
Solution
|_Azure.Web.App
| |_Roles
| |_Web.App
|_Web.App
|_Controllers
|_Models
|_Resources
| |_File1.csv
| |_File2.csv
|_Startup
| |_File3.cmd
| |_File4.xml
| |_File5.msi
|_Views
And the problem is that files from Resources and Startup folders are not copied to the output directory when building Azure.Web.App, showing this error:
[error]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure Tools\2.7\Microsoft.WindowsAzure.targets(2787,5): Error MSB3030: Could not copy the file "Resources\File1.csv" because it was not found.
All files are set to always copy to output directory and the build actions are as follows:
Content for CSV and XML files.
None for CMD and MSI files.
I haven't been able to pinpoint the circumstances when this happens, and they seem pretty random to me. Generally triggering again the build manually and/or deleting the source files at the agent directory before building again solve the issue, which is not ideal, as continuous integration is unreliable at the moment.
Have had a good look at all existing topics but haven't found one that fits my situation. Sorry if the question has already been asked, and thanks in advance.
EDIT: Forgot to mention I'm talking about new build definitions based on vNext (not XML-based builds).
I've found that in some cases where this particular error occurs, you can stop it from happening by passing a /m:1 option in the "MSBuild arguments" setting for the MSBuild step.
This prevents concurrent builds, forcing MSBuild to process things one project at a time. Sadly, this seems to be a workaround for quite a lot of build problems.
When I try to compile, I get this warning:
Warning 8 warning : The process cannot access the file 'C:\PROGRAMDATA\BROWSER MANAGER\2.2.565.25\{16CDFF19-861D-48E3-A751-D99A27784753}\BROWSEMNGR.SETTINGS' because it is being used by another process. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppClean.targets
followed by this error:
Error 8 error C1033: cannot open program database ''
I already tried uninstlaling and installing the VS 2010 but the problem does not seem to go away.
Reason: It's possible that two projects in the solution are writing their outputs to the same directory (e.g. 'xxx\debug'). If the maximum number of parallel project builds setting in Tools - Options, Projects and Solutions - Build and Run is set to a value greater than 1, this means that two compiler threads could be trying to access the same files simultaneously, resulting in a file sharing conflict.
Solution:
Check your project's settings and make sure no two projects are using the same directory for output, target or any kind of intermediate files. Or set the maximum number of parallel project builds setting to 1 for a quick workaround. I experienced this very problem while using the VS project files that came with the CLAPACK library.
I solved my problem doing these steps:
http://www.explosiveknowledge.net/main/2012/08/19/browsemngr/
And I was executing devenv.exe in compatibility with Windows XP, remove that. I also changed from use to create in the precompiled header menu options in my project.
Working fine now.
We have a large project, recently we've merged two dll into one for some reason. Then we got an Error LNK1318 while linking, and mspdbsrv.exe reached 4063MB of max memory usage,then linker report Fatal Error LNK1318 Unexpected PDB Error, OK(0)
mspdbsrv.exe is the utility program that is launched behind the scenes to create PDB symbols used for debugging your code.
I've read anecdotal reports regarding earlier versions of Visual Studio (e.g., 2005) that this little process has been a source of pain for before in the past, but I haven't run into any with daily dev work in 2010.
It sounds to me like you've built up a cache of PDB files that it's trying to combine into one at build time. Only problem is, that produces a file that's 4 GB (!!) in size. I'd delete all of the temporary files associated with your project and kill the mspdbsrv.exe process (or restart the computer), and then try building again. You might also want to turn off incremental builds, which rebuild only the information that has changed since the last build. That'll force a full rebuild, which should produce a PDB file without any extra bloat.
I have a solution with several projects in it that executes many custom build steps. Some projects depend on other projects, but most of the build steps are independent of each other.
When building inside the VS 2010 IDE, I am getting errors like this:
error MSB6003: The specified task executable "cmd.exe" could not be run. The process cannot access the file 'C:\full\path\Debug\custombuild.write.1.tlog' because it is being used by another process
However, when I build the solution with MSBuild from the command line, all is well, and the log file writing does not seem to cause the same error.
Is this a known issue? Google has not been much help today...
The answer was hinted at in an MSBuild forum thread.
The custom build rule logs are written into the containing project's $(IntDir). We had multiple projects (with no real output being sent to IntDir) that all inadvertently shared the same IntDir value. Giving each project its own IntDir value eliminated the problem.