【问题标题】:Compilation fails randomly: "cannot open program database"编译随机失败:“无法打开程序数据库”
【发布时间】:2010-09-12 17:00:38
【问题描述】:

在使用 Visual Studio 2005(版本 8.0.50727.762)进行长时间编译期间,有时在某些项目的几个文件中会出现以下错误:

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

(提到的文件是项目临时目录中的vc80.pdbvc80.idb。)

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

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

【问题讨论】:

  • 也可能是您的项目在 Dropbox\Google Drive 或类似产品中。
  • 我在使用 Visual Studio 2019+ninja 工具链在 Windows 上构建的 cmake 项目中随机遇到此错误。

标签: c++ visual-studio visual-studio-2005 compiler-errors nightly-build


【解决方案1】:

在我的情况下,问题出在 Google Drive:我忘记了该项目位于同步文件夹下,而 G Drive 可能锁定了该文件。暂停同步并没有帮助,因为无论如何都会抛出错误。

将项目文件夹移动到 Google Drive 未同步的另一个位置解决了我的问题。

顺便提一下,一开始我以为是我的防病毒软件,因为当使用procexp 检查文件时,它显示该文件已被我的一个防病毒程序使用。从我的防病毒扫描中排除文件夹项目对我没有帮助。

【讨论】:

    【解决方案2】:

    如果我 Ctrl+Break 取消构建(vs2015),这种情况一直发生在我身上。有一些进程没有正确关闭。我进行了狂暴的“结束任务” ms/vs 相关流程(查找重复项),并且我的构建再次工作。重新启动可能也会起作用。就像迁移到 gnu binutils 一样。

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

    【讨论】:

      【解决方案3】:

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

      场景

      我有两个 dll 的 parent.dllchild.dll。我在尝试构建parent.dll 项目,产生错误C1033: cannot open program database

      解决方案

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

      【讨论】:

        【解决方案4】:

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

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

        【讨论】:

        • 在经历了几天的挫折之后,它奏效了。祝福你。一种解决方法,而不是试图找出 为什么 mspdbsrv.exe 崩溃。
        【解决方案5】:

        我将中间目录更改为:

        %TEMP%\$(ProjectName)\$(Platform)\$(Configuration)\
        

        C:\temp\$(ProjectName)\$(Platform)\$(Configuration)\
        

        现在可以了。不知道为什么。

        【讨论】:

          【解决方案6】:

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

          【讨论】:

            【解决方案7】:

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

            【讨论】:

            • 这是有道理的 - 这也适用于我并在构建期间暂停同步修复它。
            【解决方案8】:

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

            【讨论】:

              【解决方案9】:

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

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

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

              【讨论】:

                【解决方案10】:

                你在使用 LinqToSql 吗?也许它类似于我在这个问题中偶尔会遇到的奇怪错误:What causes Visual Studio to fail to load an assembly incorrectly?

                【讨论】:

                  【解决方案11】:

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

                  【讨论】:

                    【解决方案12】:

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

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

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

                    【讨论】:

                    • 通常,防病毒读写扫描程序通过安装文件系统过滤器来工作。用户模式程序应该没有区别。更有可能是搜索索引器或类似人员。
                    • 关闭杀毒软件有帮助!
                    • 由于我的文件同步服务 Sugarsync(就像 Dropbox),我遇到了同样的问题。我只需要关闭那个文件夹。
                    • 我在 Qt IDE 中使用 msvc2010 32 位编译器进行调试构建并收到相同的错误。我关闭了我的防病毒软件,当 Qt 提示时,接受了“使用本地符号缓存”和“使用微软符号服务器”@C:\Users\Me\AppData\LocalTemp\symbolcache 的设置,并选择了“不再询问”。项目现在构建。我假设在 MSVS 中有一个等效的符号缓存设置。我还创建了一个新的构建目录/清除了旧的。
                    • 我在发生电源故障后执行此操作。第一个要点对我有帮助,谢谢。
                    【解决方案13】:

                    我们在我的网站上也经常看到这种情况。 This explanation,来自 Peter Kaufmann,根据我们的设置,似乎是最合理的:

                    在 Visual Studio 2005 中构建解决方案时,出现致命错误 C1033:无法打开程序数据库“xxx\debug\vc80.pdb”等错误。但是,在第二次运行构建时,通常会成功。

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

                    【讨论】:

                    • 谢谢,但两者都不是我的情况(除非 TSVN 在不执行更新时在后台执行某些操作)。
                    • 只是想说我以前见过这个错误并将并行构建的数量设置为 1 为我修复了它......虽然很明显,OP 经历了一些不同的事情。
                    • 谢谢。从昨天开始,我在每次编译时都遇到相同的错误,我每次都必须清理构建以使其正确编译。就我而言,目前卸载 Tortoise SVN 似乎已经解决了这个问题。
                    • 在“工具”>“选项”>“项目和解决方案”>“构建和运行”中设置最大并行构建数在头疼了 2 天后为我解决了问题。非常感谢。
                    猜你喜欢
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 2019-02-26
                    • 2015-09-30
                    • 1970-01-01
                    • 1970-01-01
                    相关资源
                    最近更新 更多