c++ visual-studio visual-studio-2005 compiler-errors nightly-build

c++ - La compilación falla al azar: "no se puede abrir la base de datos del programa"



visual-studio visual-studio-2005 (12)

Haga clic derecho en el archivo ejecutable de VS .... y Propiedades-> Compatibilidad-> Marque "Ejecutar este programa en modo compatible para:" OFF ........

Durante una larga compilación con Visual Studio 2005 (versión 8.0.50727.762), a veces obtengo el siguiente error en varios archivos en algún proyecto:

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

(El archivo mencionado es vc80.pdb o vc80.idb en el directorio temporal del proyecto).

La siguiente compilación del mismo proyecto tiene éxito. No hay otro Visual Studio abierto que pueda acceder a los mismos archivos.

Este es un problema serio porque hace que la compilación nocturna sea imposible.

Es posible que un antivirus o un programa similar esté tocando el archivo pdb en escritura: un antivirus es el sospechoso más probable en este escenario. Me temo que solo puedo darte algunos consejos generales, basados ​​en mi experiencia previa en la creación de versiones nocturnas en nuestra tienda. Algunos de estos pueden parecer triviales, pero los incluyo para completarlos.

  • Lo primero y más importante: asegúrese de comenzar con un borrón y cuenta nueva. Es decir, fuerza: elimine el directorio de salida de la construcción antes de comenzar su actividad nocturna.
  • Si tiene un antivirus, antispyware u otros programas similares en su máquina nocturna, considere eliminarlos. Si esa no es una opción, agregue su carpeta obj a la lista de exclusión del programa.
  • (opcional) Considere usar herramientas como VCBuild o MSBuild como parte de su actividad nocturna. Creo que es mejor usar MSBuild si estás en una máquina multinúcleo. Usamos IncrediBuild para nightlies y MSBuild para lanzamientos, y nunca encontramos el problema que describes.

Si nada más funciona, puede programar un script de vigilancia unas horas después de que se inicie la compilación y verificar su estado; si la construcción falla, el perro guardián debería reiniciarla. Este es un hack feo, pero es mejor que nada.

También hemos visto esto mucho en mi sitio. Esta explicación , de Peter Kaufmann, parece ser la más plausible basada en nuestra configuración:

Cuando construyes una solución en Visual Studio 2005, obtienes errores como el error fatal C1033: no se puede abrir la base de datos del programa ''xxx / debug / vc80.pdb''. Sin embargo, al ejecutar la compilación por segunda vez, generalmente tiene éxito.

Motivo: Es posible que dos proyectos en la solución escriban sus salidas en el mismo directorio (por ejemplo, ''xxx / debug''). Si el número máximo de configuraciones de proyecto paralelas en Herramientas - Opciones, Proyectos y Soluciones - Bild and Run se establece en un valor mayor que 1, esto significa que dos hilos del compilador podrían estar intentando acceder a los mismos archivos simultáneamente, lo que da como resultado un archivo compartiendo conflicto. Solución: compruebe la configuración de su proyecto y asegúrese de que no haya dos proyectos que utilicen el mismo directorio para la salida, el destino o cualquier tipo de archivo intermedio. O establezca el número máximo de configuraciones de proyectos paralelos en 1 para una solución rápida. Experimenté este mismo problema al usar los archivos del proyecto VS que venía con la biblioteca CLAPACK. ACTUALIZACIÓN: Existe la posibilidad de que Tortoise SVN acceda a ''vc80.pdb'', incluso si el archivo no está bajo control de versiones, lo que también podría provocar el error descrito anteriormente (gracias a Liana por informar esto). Sin embargo, no puedo confirmarlo, ya que no pude reproducir el problema después de asegurarme de que se usan directorios de salida diferentes para todos los proyectos.

Esto generalmente ocurre cuando tus intentos previos de depuración no mataron al depurador completamente. En el Administrador de tareas, busque un proceso llamado vcjit, finalícelo y vuelva a intentarlo. La peor opción es reiniciar Visual Studio, esto debería resolver su problema.

Tuve este problema hoy y resultó ser caracteres no ansi en el camino al pdb que lo causó.

Estoy usando Windows a través de vmware, y mi proyecto estaba en una ubicación compartida: / vmware-host / Shared Folders / project

Cuando lo moví a / Users / julian / project resolvió el problema.

Tuve un problema similar mientras trabajaba en un proyecto que había localizado en mi carpeta de Dropbox. Descubrí que arrojaría este error cuando el pequeño ícono de "sincronización" estaba en el ícono de Dropbox en la bandeja del sistema, ya que Dropbox estaba accediendo a los archivos para subirlos a su servidor. Cuando esperé para construir hasta que Dropbox terminó la sincronización, funcionó todo el tiempo.

Me encontré con este problema. Visual Studio se quejaba de no poder abrir vc100.pdb . Busqué archivos abiertos para este archivo usando procexp y descubrí que el proceso mspdbsrv tenía un control de archivo abierto. Matar este proceso solucionó el problema y pude compilarlo.

Cambié mi directorio intermedio de:

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

a

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

Ahora funciona. NO tengo idea por qué.

Cambie la información de depuración al formato C7 en lugar de usar el PDB.

Project Options -> C/C++ -> General -> Debug Information Format y C7 en C7 .

Tengo el mismo problema C1033: cannot open program database

Guión

Tengo dos dll''s parent.dll y child.dll . Acabo de adjuntar el proyecto child.dll con visual studio depurador al mismo tiempo que estoy tratando de construir el proyecto parent.dll, produce el error C1033: cannot open program database

Solución

Detenga la depuración y elimine el proceso adjunto con el depurador. Reconstruya el proyecto

Esto me sucede constantemente si Ctrl + Break para cancelar una compilación (vs2015). Hay algún proceso que no se cierra correctamente. Fui en un alboroto "End Tasking" ms / vs procesos relacionados (busque duplicados) y mi compilación funcionó de nuevo. Un reinicio probablemente también funcionaría. Al igual que mudarse a gnu binutils.

Las molestas herramientas de desbloqueo no informan ningún proceso que bloquee el archivo, Windows no me permite eliminar el .pdb pero puedo cambiarle el nombre. Mi suposición es que dos procesos entran al mismo tiempo durante una compilación.