Во время длинной компиляции с Visual Studio 2005 (версия 8.0.50727.762) иногда я получаю следующую ошибку в нескольких файлах в каком-то проекте:
fatal error C1033: cannot open program database ‘v:tempapprtctestwin32releasevc80.pdb’
(Файл указан как vc80.pdb или vc80.idb в файле temp dir.) Следующая сборка того же проекта завершается успешно. Нет другой открытой Visual Studio, которая может обращаться к тем же файлам. Это серьезная проблема, потому что она делает невозможным компиляцию в ночное время.
Lev 24 сен. 2008, в 14:51
Поделиться
Возможно, у вас есть проект в Dropbox Google Drive или аналогичный продукт.
Viktor Sehr 08 сен.
2015, в 15:42
Поделиться:
visual-studio
compiler-errors
visual-studio-2005
nightly-build
12 ответов
Лучший ответ
Возможно, что антивирус или аналогичная программа касается файла pdb при записи — в этом случае наиболее вероятным может быть антивирус. Боюсь, что я могу дать вам общие рекомендации, основанные на моем прошлом опыте в создании ночных сборок в нашем магазине. Некоторые из них могут показаться тривиальными, но я включаю их ради завершения.
Работа с базами данных sqlite в редакторе VS Code #Shorts
- Прежде всего, убедитесь, что вы запустили чистый лист. То есть, принудительно удалите выходной каталог сборки до того, как вы начнете свой ночной.
- Если у вас есть антивирус, антишпион или другие подобные программы на вашей ночной машине, подумайте об их устранении. Если это не вариант, добавьте свою папку obj в список исключений программы.
- (необязательно). Используйте инструменты, такие как VCBuild или MSBuild, как часть вашей ночи. Я думаю, что лучше использовать MSBuild, если вы работаете на многоядерной машине. Мы используем IncrediBuild для ночных и MSBuild для релизов и никогда не сталкивались с проблемой, которую вы описываете.
Если ничего не работает, вы можете запланировать сторожевой таймер script через несколько часов после начала сборки и проверить его статус; если сборка не выполняется, сторожевой таймер должен перезапустить ее. Это уродливый взлом, но это лучше, чем ничего.
Laur 24 сен. 2008, в 15:07
Поделиться
Я думаю, что это проблема.
Lev 24 сен.
2008, в 14:37
Обычно антивирусные сканеры работают при установке фильтра файловой системы. Программы пользовательского режима не должны видеть никакой разницы. Скорее всего, будет поисковый индекс или аналог.
Mike Dimmick 24 сен. 2008, в 15:17
Отключение антивируса помогло!
Lev 25 сен. 2008, в 06:24
У меня была такая же проблема из-за моей службы синхронизации файлов, sugarsync (это как dropbox). Я просто должен был отключить эту папку.
speedplane 24 фев. 2013, в 04:52
tmighty 12 май 2013, в 18:00
Rachael 30 янв. 2015, в 16:10
Мой сделал это после сбоя питания.
Первый пункт пули помог мне, спасибо.
Darksaint2014 10 фев. 2015, в 21:04
Показать ещё 5 комментариев
Error c1033 cannot open program database
Whenever i try to compile a program in VS it gives me this error in the output field.
Подключение базы данных Access к приложению Visual Studio
fatal error C1033: cannot open program database Are there any solutions to the problem? If so i have not found any. Any help is appreciated!
Answers
Check your Visual Studio version first. Visual Studio 2005 and 2008 do not list Windows 7 as a supported platform, though it may be safe to assume you need to have a version supported on Windows Vista first, that means you need to have VS2005 Sp1 with Vista update or VS2008. Reboot your machine to make sure no other program is using the file. If you still have this problem, run chkdisk. If chkdisk can not solve your problem, you may need to find another hard drive. Please mark the post answered your question as the answer, and mark other helpful posts as helpful.
This posting is provided «AS IS» with no warranties, and confers no rights. Visual C++ MVP
- Marked as answer by Friday, June 26, 2009 10:45 AM
Cannot retrieve contributors at this time
Learn more about: Fatal Error C1033
Fatal Error C1033
cannot open program database pdb
This error can be caused by a disk error, a temporary lock created by an anti-virus program, a previous debugger instance that has not fully shut down, or parallel build mspdbsrv.exe processes that attempt to access the same file, among other possible causes.
После долгого перерыва в C ++ я пытаюсь скомпилировать очень простой проект C ++ в VS2010. Я создал консольный проект Win32 C ++, я выбрал «Нет предварительно скомпилированных заголовков и никаких других библиотек MS». Я добавил следующий файл main.cpp:
#include #include using namespace std; class A < public: string name; >; int main(int argc, char** argv)
Когда я компилирую, я получаю печально известную ошибку:
1>—— Build started: Project: TestGetline, Configuration: Debug Win32 —— 1> main.cpp 1>main.cpp : fatal error C1033: cannot open program database » ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Вот несколько фактов:
- Я использую 64-битную Windows 7 в качестве виртуальной машины с Desktop Parallels: версия 6.1.7601 с пакетом обновления 1 (SP1), сборка 7601. Виртуальная машина имеет проверенный общий профиль, что означает, что папки «Документы», «Загрузки» и т. Д. Являются общими для OSX. Target «ClCompile» in file «C:Program Files (x86)MSBuildMicrosoft.Cppv4.0PlatformsWin32Microsoft.Cpp.Win32.Targets» from project «C:projectscppTestGetLineTestGetlineTestGetline.vcxproj» (target «_ClCompile» depends on it): Using «Delete» task from assembly «Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a». Task «Delete»Done executing task «Delete». Task «CL» skipped, due to false condition; (‘%(ClCompile.PrecompiledHeader)’ == ‘Create’ and ‘%(ClCompile.ExcludedFromBuild)’!=’true’) was evaluated as (» == ‘Create’ and »!=’true’).
Using «CL» task from assembly «Microsoft.Build.CppTasks.Win32, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a». Task «CL»Forcing recompile of all source files due to missing PDB «Debugvc100.pdb».
Environment Variables passed to tool: VS_UNICODE_OUTPUT=1328 c:Program Files (x86)Microsoft Visual Studio 10.0VCbinCL.exe /c /Zi /nologo /W3 /WX- /Od /Oy- /D WIN32 /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo»Debug» /Fd»Debugvc100.pdb» /Gd /TP /analyze- /errorReport:prompt main.cpp Tracking command: C:Program Files (x86)Microsoft SDKsWindowsv7.0AbinNETFX 4.0 ToolsTracker.exe /d C:WindowsMicrosoft.NETFrameworkv4.0.30319FileTracker.dll /i C:projectscppTestGetLineTestGetlineDebug /r C:PROJECTSCPPTESTGETLINETESTGETLINEMAIN.CPP /b MSBuildConsole_CancelEvent7f4b09d9e64d472facf5c417755b2cdd /c «c:Program Files (x86)Microsoft Visual Studio 10.0VCbinCL.exe» /c /Zi /nologo /W3 /WX- /Od /Oy- /D WIN32 /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo»Debug» /Fd»Debugvc100.pdb» /Gd /TP /analyze- /errorReport:prompt main.cpp main.cpp 1>main.cpp : fatal error C1033: cannot open program database » The command exited with code 2. Done executing task «CL» — FAILED. 1>Done building target «ClCompile» in project «TestGetline.vcxproj» — FAILED.
1>Done Building Project «C:projectscppTestGetLineTestGetlineTestGetline.vcxproj» (build target(s)) — FAILED.
Решение
Чтобы решить эту проблему, я удалил файл pdb (после того, как создал его резервную копию), а затем собрал его.
Другие решения
Я получаю эту ошибку все время, когда я запускаю проект в папке Dropbox. Кажется, что Dropbox создает резервную копию файла .pdb в то время, когда я пытаюсь создать.
Обычно это работает после одной или двух попыток.
Я снял флажок «Запустить эту программу в режиме совместимости для Windows XP (Service Pack 3)», и теперь он работает. Первоначально я играл с другими вариантами, но не с этим!
Я просто столкнулся с проблемой, и это было из-за нехватки места на диске. Когда я вычистил каталог, все было нормально.
Космос был красной селедкой. Получается, что проблема случайная. Кажется, что при сборке многих файлов VS2010 не освобождает файл vc100.pdb быстро. Мы поместили 1 секунду ожидания между последовательными компиляциями, и это помогло большинству людей. Некоторым пришлось увеличить время ожидания до 3 секунд.
Похоже, MS исправила эту проблему в VS2012, поэтому, если у вас есть возможность обновить, это, вероятно, лучше.
Я решил это, переместив папку проекта в другую папку. Тогда компилятор не жаловался на это.
Я столкнулся с той же проблемой, но в Visual Studio 2005. Отмена сборки до ее завершения привела к повреждению файла, удалению файла .idb, а затем к повторной сборке исправила проблему.
У меня тоже была эта проплема
filename.cpp: фатальная ошибка C1051: файл базы данных программы, ‘e: a b c d filename.pdb
Я решил эту проблему, удалив filename.pdb файл и все работает.
После удаления будет автоматически генерировать * .pdb файл путем создания, а также вызвать этот файл
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 ‘xxxdebugvc80.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. ‘xxxdebug’). 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.
Comments
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:tempapprtctestwin32releasevc80.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.
Источник: oshibochki.ru
Компиляция происходит случайно: «не удается открыть базу данных программы»
Во время долгой компиляции с Visual Studio 2005 (версия 8.0.50727.762) я иногда получаю следующую ошибку в нескольких файлах в каком-то проекте:
fatal error C1033: cannot open program database ‘v:tempapprtctestwin32releasevc80.pdb’
(Упомянутый файл либо vc80.pdb или же vc80.idb в временном каталоге проекта.)
Следующая сборка того же проекта завершается успешно. Нет других открытых Visual Studio, которые могли бы получить доступ к тем же файлам.
Это серьезная проблема, потому что она делает невозможной ночную компиляцию.
user7224 24 сен ’08 в 12:15 2008-09-24 12:15
2008-09-24 12:1515 ответов
Возможно, что антивирус или аналогичная программа касается файла pdb при записи — антивирус наиболее вероятен в этом сценарии. Боюсь, что я могу дать вам только некоторые общие указания, основанные на моем прошлом опыте установки ночных сборок в нашем магазине. Некоторые из них могут показаться тривиальными, но я включаю их ради завершения.
- Прежде всего: убедитесь, что вы начинаете с чистого листа. То есть принудительно удалите выходной каталог сборки, прежде чем начинать работу ночью.
- Если на вашем ночном компьютере есть антивирус, антишпионское ПО или другие подобные программы, рассмотрите возможность их удаления. Если это не вариант, добавьте папку obj в список исключений программы.
- (необязательно) Рассмотрите возможность использования таких инструментов, как VCBuild или MSBuild, как часть вашей ночной. Я думаю, что лучше использовать MSBuild, если вы работаете на многоядерной машине. Мы используем IncrediBuild для ночных развлечений и MSBuild для релизов, и никогда не сталкивались с проблемой, которую вы описали.
Если больше ничего не работает, вы можете запланировать сторожевой скрипт через несколько часов после начала сборки и проверить его состояние; если сборка не удалась, сторожевой таймер должен перезапустить ее. Это безобразный хак, но лучше, чем ничего.
user7134 24 сен ’08 в 13:26 2008-09-24 13:26
2008-09-24 13:26