C++ 编译随机失败：“无法打开程序数据库”

Compilation fails randomly: "cannot open program database"

提问by Lev

During a long compilation with Visual Studio 2005 (version 8.0.50727.762), I sometimes get the following error in several files in some project:

在使用 Visual Studio 2005（版本 8.0.50727.762）进行长时间编译期间，我有时会在某些项目的多个文件中收到以下错误：

fatal error C1033: cannot open program database 'v:\temp\apprtctest\win32\release\vc80.pdb'

(The file mentioned is either vc80.pdbor vc80.idbin the project's temp dir.)

（提到的文件是vc80.pdb或vc80.idb在项目的临时目录中。）

The next build of the same project succeeds. There is no other Visual Studio open that might access the same files.

同一项目的下一个构建成功。没有其他打开的 Visual Studio 可能访问相同的文件。

This is a serious problem because it makes nightly compilation impossible.

这是一个严重的问题，因为它使夜间编译变得不可能。

采纳答案by Laur

It is possible that an antivirus or a similar program is touching the pdb file on write - an antivirus is the most likely suspect in this scenario. I'm afraid that I can only give you some general pointers, based on my past experience in setting nightly builds in our shop. Some of these may sound trivial, but I'm including them for the sake of completion.

防病毒软件或类似程序可能会在写入时接触 pdb 文件 - 在这种情况下，最有可能是防病毒软件。根据我过去在我们商店设置夜间构建的经验，恐怕我只能给你一些一般性的建议。其中一些可能听起来微不足道，但我将它们包括在内是为了完成。

• First and foremost: make sure you start up with a clean slate. That is, force-delete the output directory of the build before you start your nightly.
• If you have an antivirus, antispyware or other such programs on your nightly machine, consider removing them. If that's not an option, add your obj folder to the exclusion list of the program.
• (optional) Consider using tools such as VCBuild or MSBuild as part of your nightly. I think it's better to use MSBuild if you're on a multicore machine. We use IncrediBuild for nightlies and MSBuild for releases, and never encountered the problem you describe.

• 首先也是最重要的：确保你从一个干净的石板开始。也就是说，在每晚开始之前强制删除构建的输出目录。
• 如果您的夜间计算机上装有防病毒软件、反间谍软件或其他此类程序，请考虑将其删除。如果这不是一个选项，请将您的 obj 文件夹添加到程序的排除列表中。
• （可选）考虑使用 VCBuild 或 MSBuild 等工具作为夜间活动的一部分。我认为如果您使用的是多核机器，最好使用 MSBuild。我们将 IncrediBuild 用于 nightlies，将 MSBuild 用于发布，从未遇到过您描述的问题。

If nothing else works, you can schedule a watchdog script a few hours after the build starts and check its status; if the build fails, the watchdog should restart it. This is an ugly hack, but it's better than nothing.

如果没有其他效果，您可以在构建开始几个小时后安排一个看门狗脚本并检查其状态；如果构建失败，看门狗应该重新启动它。这是一个丑陋的黑客，但总比没有好。

回答by SCFrench

We've seen this a lot at my site too. This explanation, from Peter Kaufmann, seems to be the most plausible based on our setup:

我们在我的网站上也经常看到这种情况。根据我们的设置，来自 Peter Kaufmann 的这个解释似乎是最合理的：

When building a solution in Visual Studio 2005, you get errors like fatal error C1033: cannot open program database 'xxx\debug\vc80.pdb'. However, when running the build for a second time, it usually succeeds.

在 Visual Studio 2005 中构建解决方案时，您会收到类似致命错误 C1033：无法打开程序数据库 'xxx\debug\vc80.pdb' 之类的错误。但是，当第二次运行构建时，它通常会成功。

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 - Bild 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. UPDATE: There is a chance that Tortoise SVN accesses 'vc80.pdb', even if the file is not under versioning control, which could also result in the error described above (thanks to Liana for reporting this). However, I cannot confirm this, as I couldn't reproduce the problem after making sure different output directories are used for all projects.

原因：解决方案中的两个项目可能将其输出写入同一目录（例如“xxx\debug”）。如果 Tools - Options, Projects and Solutions - Bild and Run 中的最大并行项目构建数设置为大于 1 的值，这意味着两个编译器线程可能会尝试同时访问相同的文件，从而导致文件共享冲突。解决方案：检查您的项目设置并确保没有两个项目使用相同的目录作为输出、目标或任何类型的中间文件。或者将并行项目构建的最大数量设置为 1 以快速解决。我在使用 CLAPACK 库附带的 VS 项目文件时遇到了这个问题。更新：Tortoise SVN 有可能访问“vc80.pdb”，即使文件不受版本控制，这也可能导致上述错误（感谢 Liana 报告此问题）。但是，我无法确认这一点，因为在确保所有项目都使用不同的输出目录后，我无法重现该问题。

回答by M.H.

Switch the debug info to C7 format instead of using the PDB.

将调试信息切换为 C7 格式，而不是使用 PDB。

Project Options -> C/C++ -> General -> Debug Information Formatand set it to C7.

Project Options -> C/C++ -> General -> Debug Information Format并将其设置为C7.

回答by M.H.

This generally happens when your previous attempts at debugging have not killed the debugger fully. In Task manager look for a process called vcjit, kill it and try again. Worst option restart visual studio, this should solve your problem.

当您之前的调试尝试没有完全杀死调试器时，通常会发生这种情况。在任务管理器中查找名为 vcjit 的进程，将其杀死并重试。最糟糕的选择是重新启动 Visual Studio，这应该可以解决您的问题。

回答by Julian Mann

I had this problem today and it turned out to be non-ansi characters in the path to the pdb that caused it.

我今天遇到了这个问题，结果是导致它的 pdb 路径中的非 ansi 字符。

I'm using windows through vmware, and my project was in a shared location: \vmware-host\Shared Folders\project

我通过 vmware 使用 windows，我的项目位于共享位置：\vmware-host\Shared Folders\project

When I moved it to \Users\julian\project it resolved the issue.

当我将它移动到 \Users\julian\project 时，它解决了这个问题。

回答by Vin.X

Try right click the excutable file of VS....and Properties->Compatibility-> Tick "Run this program in compatibilty mode for:" OFF........

尝试右键单击 VS 的可执行文件....和属性->兼容性->勾选“在兼容模式下运行此程序：”关闭........

回答by Logan

I had a similar problem while working on a project which I had located in my Dropbox folder. I found that it would throw this error when the little "syncing" icon was going on the Dropbox icon in the system tray, since Dropbox was accessing the files to upload them to their server. When I waited to build until Dropbox finished syncing, it worked every time.

在处理我位于 Dropbox 文件夹中的项目时，我遇到了类似的问题。我发现当系统托盘中的 Dropbox 图标上出现小“同步”图标时，它会抛出此错误，因为 Dropbox 正在访问文件以将它们上传到他们的服务器。当我等待构建直到 Dropbox 完成同步时，它每次都有效。

回答by Tejas Sharma

I just ran into this problem. Visual studio was complaining about not being able to open vc100.pdb. I looked for open file handles to this file using procexpand found out that the process mspdbsrvhad an open file handle to it. Killing this process fixed the issue and I was able to compile.

我刚刚遇到了这个问题。Visual Studio 抱怨无法打开vc100.pdb. 我使用该文件查找打开的文件句柄procexp，发现该进程mspdbsrv有一个打开的文件句柄。终止这个进程解决了这个问题，我能够编译。

回答by CLIFFORD P Y

I have same problem C1033: cannot open program database,

我有同样的问题 C1033: cannot open program database，

Scenario

设想

I have two dll's parent.dlland child.dll.I just attached child.dll project with visual studio debugger at the same time i am trying to build the parent.dll project,produces error C1033: cannot open program database

我有两个 dll 的parent.dll和child.dll。我只是在尝试构建 parent.dll 项目的同时将 child.dll 项目附加到 Visual Studio 调试器，产生错误 C1033: cannot open program database

Solution

解决方案

Stop debugging and kill the process attached with the debugger.Rebuild the project

停止调试并终止调试器附带的进程。重新构建项目

回答by jozxyqk

This happens to me consistently if I Ctrl+Breakto cancel a build (vs2015). There's some process that isn't shut down properly. I went on a rampage "End Tasking" ms/vs related processes (look for duplicates) and my build worked again. A restart would probably work too. As would moving to gnu binutils.

如果我Ctrl+Break取消构建（vs2015），这会一直发生在我身上。有一些进程没有正确关闭。我进行了横冲直撞的“结束任务”ms/vs 相关进程（查找重复项），我的构建再次运行。重新启动也可能有效。就像迁移到 gnu binutils 一样。

Annoyingly unlocker tools don't report any processes locking the file, windows doesn't let me delete the .pdbbut I can rename it. My guess is two processes jump in at the same time during a build.

恼人的解锁工具不会报告锁定文件的任何进程，Windows 不允许我删除它，.pdb但我可以重命名它。我的猜测是在构建过程中两个进程同时进入。