Domanda

Durante una lunga compilazione con Visual Studio 2005 (versione 8.0.50727.762), a volte ottengo il seguente errore in diversi file in alcuni progetti:

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

(Il file menzionato è vc80.pdb o vc80.idb nella directory temporanea del progetto.

La prossima build dello stesso progetto ha esito positivo. Non esiste nessun altro Visual Studio aperto che possa accedere agli stessi file.

Questo è un problema serio perché rende impossibile la compilazione notturna.

È stato utile?

Soluzione

È possibile che un antivirus o un programma simile stia toccando il file pdb in scrittura - un antivirus è probabilmente il sospetto in questo scenario. Temo di poterti dare solo alcuni consigli generali, basati sulla mia esperienza passata nell'impostare build notturne nel nostro negozio. Alcuni di questi possono sembrare banali, ma li includo per completezza.

  • Innanzitutto: assicurati di iniziare con una lavagna pulita. Cioè, forzare l'eliminazione della directory di output della build prima di iniziare la notte.
  • Se hai un antivirus, un antispyware o altri programmi simili sul tuo computer notturno, prendi in considerazione la possibilità di rimuoverli. Se questa non è un'opzione, aggiungi la tua cartella obj all'elenco di esclusione del programma.
  • (opzionale) Prendi in considerazione l'utilizzo di strumenti come VCBuild o MSBuild come parte della tua serata. Penso che sia meglio usare MSBuild se sei su una macchina multicore. Usiamo IncrediBuild per i nightly e MSBuild per le versioni e non abbiamo mai riscontrato il problema che descrivi.

Se nient'altro funziona, è possibile pianificare uno script watchdog poche ore dopo l'avvio della compilazione e verificarne lo stato; se la compilazione fallisce, il watchdog dovrebbe riavviarlo. Questo è un brutto trucco, ma è meglio di niente.

Altri suggerimenti

Lo abbiamo visto molto anche sul mio sito. Questa spiegazione , di Peter Kaufmann, sembra essere la più plausibile in base alla nostra configurazione:

Quando si crea una soluzione in Visual Studio 2005, si ottengono errori come l'errore irreversibile C1033: impossibile aprire il database del programma 'xxx \ debug \ vc80.pdb'. Tuttavia, quando esegue la build per la seconda volta, in genere ha esito positivo.

Motivo: è possibile che due progetti nella soluzione stiano scrivendo i loro output nella stessa directory (ad esempio "xxx \ debug"). Se l'impostazione del numero massimo di progetti paralleli in Strumenti - Opzioni, progetti e soluzioni - Bild and Run è impostata su un valore maggiore di 1, ciò significa che due thread del compilatore potrebbero tentare di accedere agli stessi file contemporaneamente, risultando in un file condividere il conflitto. Soluzione: controllare le impostazioni del progetto e assicurarsi che non ci siano due progetti che utilizzano la stessa directory per output, destinazione o qualsiasi tipo di file intermedio. Oppure imposta il numero massimo di build di progetti paralleli impostato su 1 per una soluzione rapida. Ho riscontrato questo problema durante l'utilizzo dei file di progetto VS forniti con la libreria CLAPACK. AGGIORNAMENTO: è possibile che Tortoise SVN acceda a "vc80.pdb", anche se il file non è sotto il controllo di versione, il che potrebbe anche causare l'errore sopra descritto (grazie a Liana per averlo segnalato). Tuttavia, non posso confermarlo, poiché non sono riuscito a riprodurre il problema dopo essermi assicurato che vengano utilizzate directory di output diverse per tutti i progetti.

Cambia le informazioni di debug nel formato C7 invece di usare il PDB.

Opzioni progetto - > C / C ++ - > Generale - > Formato informazioni debug e impostarlo su C7 .

Ciò si verifica generalmente quando i precedenti tentativi di debug non hanno interrotto completamente il debugger. In Task manager cerca un processo chiamato vcjit, uccidilo e riprova. La peggiore opzione riavvia Visual Studio, questo dovrebbe risolvere il tuo problema.

Ho avuto questo problema oggi e si è rivelato essere caratteri non ansi nel percorso al pdb che lo ha causato.

Sto usando Windows tramite VMware e il mio progetto era in una posizione condivisa: \ vmware-host \ Shared Folders \ project

Quando l'ho spostato in \ Users \ julian \ project ha risolto il problema.

Prova a fare clic con il pulsante destro del mouse sul file eseguibile di VS .... e Proprietà- > Compatibilità- > Spuntare " Esegui questo programma in modalità compatibilità ford: " OFF ........

Ho avuto un problema simile mentre lavoravo a un progetto che avevo localizzato nella mia cartella Dropbox. Ho scoperto che avrebbe generato questo errore quando la piccola "sincronizzazione" icona stava andando sull'icona di Dropbox nella barra delle applicazioni, poiché Dropbox stava accedendo ai file per caricarli sul loro server. Quando ho aspettato di compilare fino al termine della sincronizzazione di Dropbox, ha funzionato ogni volta.

Ho appena riscontrato questo problema. Visual Studio si lamentava di non poter aprire vc100.pdb . Ho cercato gli handle di file aperti su questo file usando procexp e ho scoperto che il processo mspdbsrv aveva un handle di file aperto. L'uccisione di questo processo ha risolto il problema e sono stato in grado di compilare.

Stai usando LinqToSql? Forse è simile allo strano errore che sperimenterò di tanto in tanto quando mi sono posto questa domanda: Cosa impedisce a Visual Studio di caricare un assembly in modo errato?

Ho cambiato la mia directory intermedia da:

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

a

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

Funziona ora. NON ho idea del perché.

Ho lo stesso problema C1033: impossibile aprire il database del programma ,

Scenario

Ho due parent.dll e child.dll di due dll. Ho appena attaccato il progetto child.dll con il debugger di Visual Studio mentre provo a costruire il progetto parent.dll, produce l'errore C1033: impossibile aprire il database del programma

Soluzione

Interrompi il debug e termina il processo associato al debugger. Crea il progetto

Questo mi succede in modo coerente se Ctrl + Break per annullare una build (vs2015). C'è qualche processo che non viene chiuso correttamente. Sono andato su tutte le furie " End Tasking " ms / vs processi correlati (cerca duplicati) e la mia build ha funzionato di nuovo. Probabilmente funzionerebbe anche un riavvio. Come passare a gnu binutils.

Gli strumenti di sblocco fastidioso non segnalano alcun processo che blocca il file, Windows non mi consente di eliminare il .pdb ma posso rinominarlo. La mia ipotesi è che due processi saltino contemporaneamente durante una build.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top