Compilation fails randomly: "cannot open program database"

Question

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:

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

(The file mentioned is either vc80.pdb or vc80.idb in the project's temp dir.)

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

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

Solution 1

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.

• 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.

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.

Solution 2

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:

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.

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.

Solution 3

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

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

Solution 4

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

Solution 5

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 procexp and found out that the process mspdbsrv had an open file handle to it. Killing this process fixed the issue and I was able to compile.

View more solutions

Comments

[Lev]

Thanks, but neither of the two is my case (unless TSVN does something in the background when no update is being performed).

[Mike Dimmick]

Generally anti-virus on-access scanners work by installing a file-system filter. User-mode programs should see no difference. More likely to be a search indexer or similar.

[Lev]

Turning off the antivirus helped!

[Nik Reiman]

Just wanted to say that I've seen this error before and setting the number of parallel builds to 1 fixed it for me... though clearly, the OP experienced something different.

[speedplane]

I had the same problem due to my file syncing service, sugarsync (it's like dropbox). I just had to turn off that folder.

[localhost]

Thanks. I was getting the same error on every single compilation since yesterday and I had to clean the build every time for it to compile properly. Uninstalling Tortoise SVN seems to have fixed the problem for now in my case.

[Rachael]

I am using the msvc2010 32-bit compiler for my debug builds in the Qt IDE and received the same error. I turned off my antivirus and when prompted by Qt, accepted the settings of "use local symbol cache" and "use microsoft symbol server" @ C:\Users\Me\AppData\LocalTemp\symbolcache and also selected "do not ask again." Project now builds. I assume there is an equivalent of this symbol cache setting in MSVS. I also created a new build directory/purged the old one.

[Darksaint2014]

Mine did this after a power failure occurred. The first bullet point helped me, thanks.

[Camille Goudeseune]

That worked, after days of frustration. Bless you. A workaround instead of trying to figure out why mspdbsrv.exe was crashing.

[afterxleep]

Setting max number of parallel builds in Tools > Options > Projects & Solutions > Build & Run did the trick for me after 2 days a head-scratching. Many thanks.

[Collin Biedenkapp]

This makes sense - this also applies to me and pausing syncing during the build fixed it.