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.
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.
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.
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.
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.
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.
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.
Try right click the excutable file of VS....and Properties->Compatibility-> Tick "Run this program in compatibilty mode for:" OFF........
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.
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
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.
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?
I changed my intermediate directory from:
%TEMP%\$(ProjectName)\$(Platform)\$(Configuration)\
to
C:\temp\$(ProjectName)\$(Platform)\$(Configuration)\
It works now. NO idea why.
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.
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
)
)
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
I am using Juno (downloaded today). I setup a new project with perhaps 10,000 c++ files. I also setup a custom build command that does an ssh out to a remote machine to build the code. (The code is on a drive shared by both machines.) When I build, the console output shows the build command, and it runs and completes pretty quickly. However, after the ssh command is done, it takes perhaps 2-5 minutes before the "Build Project" dialog goes away. In the details section it just says "Building Project...", and the progress bar does not move beyond 25%. The back and forth animation in the lower right of eclipse is moving back and forth.
Does anyone know what Eclipse is actually doing during this time?
Does anyone know how to make it stop whatever it is doing?
Basically, yesterday I could program in C++ and today I cannot.
I'm trying to write a simple hello world program in Eclipse Helios using the MinGW C/C++ compiler and I'm running into several problems, and I believe this one to be the root of it.
At first the program compiled and built, but when I tried to run it, an error dialogue said the FirstProject.exe file could not be found/does not exist in the launch configuration. However, I got no errors building and I could clearly see the binaries in Debug/FirstProject.exe in my project explorer. I tried refreshing my project explorer and alas, the file disappeared before my eyes.
I tried building the program again, and that's when I get this error:
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe: final link failed: No space left on device
I don't know what device it's talking about. I have more than 1TB left on this hard drive, so it can't be that. I tried emptying my %Temp% folder and recycling bin (suggestions I found trying to search for a solution for this problem) but to no avail.
It may be worth noting that C++ programs I have written in the past are still running. I'm very new to programming, so I don't know how much information you need, but I'll gladly add anything you need if you think you can help me out.
I just solved this on one of the computers at work which had the same issue when compiling through Codelite. Moving workspaces, rebooting, and reinstalling Codelite didn't fix the problem. I also checked permissions on the /temp folder which were fine.
It turns out there were permission issues/other issues with the disk. Running a disk check fixed a few issues on the disk and that allowed the program to compile. If this doesn't solve your issue you may also want to try disabling any anti-virus/spyware programs and try again.
I just solved this problem on my PC. Actually what the problem in my case was that my windows defender (or any antivirus in someone's case) was blocking ld.exe from accessing the protected folder that is the source code folder. You can correct this by going into the Virus and threat protection settings of your PC and then find there for blocked history. You will definitely find there a history record of that blockage. Then just go and allow on this device it. And boom 😁
Edit: This problem only occurs on windows 7 and vista from what I've heard.
I have a very simple app developed with an external graphics library. If I install this app into a program files directory and run it, it will crash immediately but it works fine normally, with exactly the same files. I have realised it is because you need to run the application as administrator for it to work.
I appreciate if this is a problem directly related to the graphics engine I am using, but I don't really think so (but I'm clueless). Can anyone help me?
Edit for more detail:
The application executable and files that are needed to run it are installed into the default program directory - for me, C:\Program Files (x86). If you try and run with without clicking run as administrator, it will simple freeze and say "App has stopped working. Windows is checking for a solution to the problem..." My question is basically, how can I make it so run as administrator isn't necessary?
When a program cannot perform an operation, it (the operation) should fail gracefully. My guess is your application is attempting to do something that it cannot do as a normal user and then fails to check for a return code, and then subsequently crashes. You need to identify what it is your program is doing that it should not be able to do as a normal user. For example (off the top of my head):
Write a file to Program Files (x86)
Write to HKLM
(Without more details) The problem is most likely related to the fact that your program tries to write into the directory and then excepts the file creation/modification to actually have an effect. UAC prevents applications from writing the Program Files directories without administrator privilages. The solution is to redesign your application to not rely on such behavior or store the files in question in one of the intended locations (AppData, etc. folders).
If you right-click on the EXE and go to Properties -> Compatibility there are some options that might help. You could try running the app in compatibility mode for a previous Windows version or if that doesn't work at least mark the EXE to run as administrator by default.
Working on a Win32 DLL using Visual Studio 2008 SP1 and, since yesterday, whenever I try to right click on code, to go to a variable definition for example, VS completely locks up and I have to manually kill the process. To make it even weirder, whenever this happens the devenv.exe process uses exactly 25% of the CPU. And I mean exactly, never 24%, never 26%, always 25%
Also, I've run ProcMon to see if devenv is actually doing something, but it's doing absolutely nothing external of the process. No disk, network, registry access. Nothing.
This is getting really aggravating because I have a large code base to deal with and the only other way of jumping to the definition is to first search for it.
Has anyone run into a similar issue? And, better yet, know a fix?
Edit: More info. Other projects (even an older version of the same one) work fine. I diffed the project file and the only differences is added source files and a /D define in the command line params.
Edit 2: So, it seems that now it's actually because intellisense is stuck updating. For some reason the status bar was disabled, but when getting it back I say "Updating Intellisense... (186)" and from what I've read, that 186 means that there are 186 background threads working. 186?! But, procmon still shows no IO whatsoever.
Try deleting all .sbr .bsc and .pdb files.
For the 25% CPU load: I guess it uses one core on your quad core machine.
If you have Visual Assist installed, try disabling it.
On connect, a submitted bug: Visual Studio Hang, seems to closely resemble your issue:
At random times, when I right click in the text editor, in this case C/C++ editor, Visual Studio will just hang. And if I wait it out, it still hangs.
It seems the workaround is to exit Visual Studio and delete the intellisense (.ncb) file in your project directory and reopen it.
The issue you are seeing is an intermittent failure in prior versions of Visual C++ that is hard to diagnose, and has a relatively simple workaround, as you have discussed, which is to delete your NCB. In order to get proper intellisense for header files, they would need to be included by a .cpp file in your project (directly, or indirectly through another header.)