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.

Scifi

Could also be you have your project in Dropbox\Google Drive or similar product. – Knowle

I've experienced this error randomly on cmake projects building on Windows with the Visual Studio 2019+ninja toolchain. – Causerie

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

Bowfin

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. – Van

Turning off the antivirus helped! – Scifi

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

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. – Teide

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

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

Ed

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

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. – Denicedenie

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. – Fit

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. – Gymnastics

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

Tetragon

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

Answer 4

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.

Lindbergh

Answer 5

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

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

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

Rego

Answer 6

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.

Inward

Answer 7

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

Norbert

Answer 8

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.

Cherimoya

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

Answer 9

I have same problem C1033: cannot open program database,

Scenario

I have two dll's parent.dll and 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

Solution

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

Emersonemery

Answer 10

This happens to me consistently if I Ctrl+Break to 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.

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

Squirt

Answer 11

Are you using LinqToSql at all? Perhaps it is similar to the odd error I will experience occasionally as I asked in this question: What causes Visual Studio to fail to load an assembly incorrectly?

Coleorhiza

Answer 12

I changed my intermediate directory from:

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

to

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

It works now. NO idea why.

Farber

Answer 13

In my case the problem was Google Drive: I forgot that the project was under a synced folder and G Drive probably locked that file. Pausing the sync didn't help since the error was throwed anyway.

Moving the project folder to another location not synced by Google Drive solved my issue.

Just to mention, at the beginning I thought it was my anti-virus, since when examinating the file using procexp it showed that the file was used by one of my anti-virus process. Excluding the folder project from my anti-virus scan didn't help in my case.

Realtor

Answer 14

the simplest solution is "build one more time":

BuildConsole abc.sln /rebuild /cfg="release|Win32"
if %errorlevel% neq 0 (
    BuildConsole abc.sln /cfg="release|Win32"
    if %errorlevel% neq 0 (
        rem process error
        exit 1
    )
)

Annmarieannnora

Answer 15

I just ran into this problem and Google led me here. For me, it was Google Drive syncing my project files while I'm trying to run. Pausing Google Drive sync temporarily solved it, but I'd rather there was a way for Google Drive to keep its hands off while Visual Studio is doing its stuff. If anyone knows how I can configure that, please let me know

Kamerun

This post seems to be a "thanks" for https://mcmap.net/q/380149/-compilation-fails-randomly-quot-cannot-open-program-database-quot with a description of what else you want solved. If I am mistaken please edit to get this more according to How to Answer. Because if you click the "Post Your Answer" button, you should post an answer and not another question. – Born

Answer 16

I just had this problem. Except it didn't occur sporadically but everytime I tried to build any project with Plattform Toolset v120_xp. I solved the problem by unsinstalling and reinstalling Visual Studio 2013.

Evin