سؤال

أثناء التحويل البرمجي الطويل باستخدام Visual Studio 2005 (الإصدار 8.0.50727.762)، أحصل أحيانًا على الخطأ التالي في عدة ملفات في بعض المشاريع:

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

(الملف المذكور هو إما vc80.pdb أو vc80.idb في درجة حرارة المشروع.)

نجاح البناء التالي لنفس المشروع.لا يوجد Visual Studio آخر مفتوح يمكنه الوصول إلى نفس الملفات.

هذه مشكلة خطيرة لأنها تجعل التجميع الليلي مستحيلاً.

هل كانت مفيدة؟

المحلول

من الممكن أن يكون برنامج مكافحة فيروسات أو برنامج مشابه يلمس ملف pdb عند الكتابة - برنامج مكافحة الفيروسات هو المشتبه به على الأرجح في هذا السيناريو.أخشى أنه لا يمكنني إلا أن أقدم لك بعض المؤشرات العامة، بناءً على تجربتي السابقة في إعداد التصميمات الليلية في متجرنا.قد يبدو بعض هذه الأشياء تافهًا، لكنني أدرجتها من أجل الاستكمال.

  • اولا في المقام الاول اولا قبل كل شي:تأكد من البدء بسجل نظيف.وهذا يعني فرض حذف دليل الإخراج الخاص بالبناء قبل أن تبدأ ليلتك.
  • إذا كان لديك برنامج مكافحة فيروسات أو برنامج مكافحة تجسس أو برامج أخرى مماثلة على جهازك الليلي، ففكر في إزالتها.إذا لم يكن هذا خيارًا، أضف مجلد obj الخاص بك إلى قائمة الاستثناءات الخاصة بالبرنامج.
  • (اختياري) فكر في استخدام أدوات مثل VCBuild أو MSBuild كجزء من ليلتك.أعتقد أنه من الأفضل استخدام MSBuild إذا كنت تستخدم جهازًا متعدد النواة.نحن نستخدم IncrediBuild للصحف الليلية وMSBuild للإصدارات، ولم نواجه أبدًا المشكلة التي وصفتها.

إذا لم ينجح أي شيء آخر، فيمكنك جدولة البرنامج النصي للمراقبة بعد ساعات قليلة من بدء الإنشاء والتحقق من حالته؛إذا فشل البناء، يجب على الوكالة الدولية للطاقة إعادة تشغيله.هذا اختراق قبيح، لكنه أفضل من لا شيء.

نصائح أخرى

لقد رأينا هذا كثيرًا في موقعي أيضًا. هذا التفسير, ، من بيتر كوفمان، يبدو أنه الأكثر قبولًا بناءً على إعدادنا:

عند إنشاء حل في Visual Studio 2005، تحصل على أخطاء مثل الخطأ الفادح C1033:لا يمكن فتح قاعدة بيانات البرنامج 'xxx\debug\vc80.pdb'.ومع ذلك، عند تشغيل الإنشاء للمرة الثانية، ينجح عادةً.

سبب:من الممكن أن يقوم مشروعان في الحل بكتابة مخرجاتهما في نفس الدليل (على سبيل المثال."xxx\تصحيح").إذا تم تعيين الحد الأقصى لعدد إنشاءات المشروع المتوازية في الأدوات - الخيارات والمشاريع والحلول - Bild and Run على قيمة أكبر من 1، فهذا يعني أن اثنين من سلاسل التحويل البرمجي قد يحاولان الوصول إلى نفس الملفات في وقت واحد، مما يؤدي إلى ملف صراع المشاركة.حل:تحقق من إعدادات مشروعك وتأكد من عدم استخدام مشروعين لنفس الدليل للإخراج أو الهدف أو أي نوع من الملفات الوسيطة.أو قم بتعيين الحد الأقصى لعدد إصدارات المشروع المتوازية على 1 للحصول على حل سريع.لقد واجهت هذه المشكلة بالذات أثناء استخدام ملفات مشروع VS المرفقة مع مكتبة CLAPACK.تحديث:هناك احتمال أن يصل Tortoise SVN إلى "vc80.pdb"، حتى لو لم يكن الملف تحت التحكم في الإصدار، مما قد يؤدي أيضًا إلى الخطأ الموضح أعلاه (شكرًا لـ Liana على الإبلاغ عن هذا).ومع ذلك، لا يمكنني تأكيد ذلك، حيث لم أتمكن من إعادة إنتاج المشكلة بعد التأكد من استخدام أدلة إخراج مختلفة لجميع المشاريع.

قم بتبديل معلومات التصحيح إلى تنسيق C7 بدلاً من استخدام PDB.

Project Options -> C/C++ -> General -> Debug Information Format وتعيينه على C7.

يحدث هذا بشكل عام عندما لا تؤدي محاولاتك السابقة لتصحيح الأخطاء إلى إنهاء مصحح الأخطاء بشكل كامل.في مدير المهام، ابحث عن عملية تسمى vcjit، قم بإيقافها وحاول مرة أخرى.الخيار الأسوأ هو إعادة تشغيل الاستوديو المرئي، وهذا من شأنه أن يحل مشكلتك.

لقد واجهت هذه المشكلة اليوم وتبين أنها أحرف غير ansi في المسار إلى pdb التي تسببت في حدوثها.

أنا أستخدم windows من خلال برنامج vmware، وكان مشروعي في موقع مشترك:\vmware-host\المجلدات المشتركة\المشروع

عندما قمت بنقله إلى \Users\julian\project قام بحل المشكلة.

حاول النقر بزر الماوس الأيمن فوق الملف القابل للتنفيذ لـ VS....وخصائص->التوافق-> حدد "تشغيل هذا البرنامج في وضع التوافق من أجل:" إيقاف........

لقد واجهت مشكلة مماثلة أثناء العمل في مشروع قمت بتحديد موقعه في مجلد Dropbox الخاص بي.لقد وجدت أنه سيؤدي إلى ظهور هذا الخطأ عندما تظهر أيقونة "المزامنة" الصغيرة على أيقونة Dropbox في علبة النظام، نظرًا لأن Dropbox كان يصل إلى الملفات لتحميلها على الخادم الخاص به.عندما انتظرت البناء حتى انتهى Dropbox من المزامنة، كان يعمل في كل مرة.

لقد واجهت هذه المشكلة للتو.كان الاستوديو المرئي يشكو من عدم القدرة على الفتح vc100.pdb.لقد بحثت عن مقابض الملفات المفتوحة لهذا الملف باستخدام procexp واكتشفت أن هذه العملية mspdbsrv كان لديه مقبض ملف مفتوح لذلك.أدى قتل هذه العملية إلى حل المشكلة وتمكنت من التجميع.

هل تستخدم LinqToSql على الإطلاق؟ولعله يشبه الخطأ الغريب الذي سأواجهه أحيانًا كما سألت في هذا السؤال: ما الذي يسبب فشل Visual Studio في تحميل التجميع بشكل غير صحيح؟

لقد قمت بتغيير الدليل الوسيط الخاص بي من:

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

ل

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

انه يعمل الان.لا فكرة لماذا.

لدي نفس المشكلة C1033: cannot open program database,

سيناريو

لدي اثنين من دلل parent.dll و Child.dll.لقد قمت للتو بإرفاق مشروع Child.dll باستخدام مصحح أخطاء الاستوديو المرئي في نفس الوقت الذي أحاول فيه إنشاء مشروع Parent.dll، مما ينتج عنه خطأ C1033: cannot open program database

حل

أوقف تصحيح الأخطاء وأوقف العملية المرفقة مع مصحح الأخطاء. أعد بناء المشروع

يحدث هذا لي باستمرار إذا كنت كنترول+استراحة لإلغاء البناء (vs2015).هناك بعض العمليات التي لم يتم إيقافها بشكل صحيح.لقد انطلقت في حالة هياج من العمليات ذات الصلة بـ "إنهاء المهام" ms/vs (ابحث عن التكرارات) وعمل البناء الخاص بي مرة أخرى.من المحتمل أن تعمل إعادة التشغيل أيضًا.كما هو الحال مع الانتقال إلى gnu binutils.

لا تقوم أدوات إلغاء القفل بشكل مزعج بالإبلاغ عن أي عمليات تقوم بتأمين الملف، ولا يسمح لي Windows بحذف الملف .pdb ولكن يمكنني إعادة تسميته.أعتقد أن عمليتين تقفزان في نفس الوقت أثناء الإنشاء.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top