Perché non vengono caricati simboli durante il debug remoto?
-
02-07-2019 - |
Domanda
Voglio usare il debug remoto. Il programma di cui voglio eseguire il debug viene eseguito sulla macchina b. Visual Studio funziona sulla macchina a.
Sulla macchina b ho una cartella con i seguenti file:
- msvcr72.dll
- Msvsmon.exe
- NatDbgDE.dll
- NatDbgDEUI.dll
- NatDbgEE.dll
- NatDbgEEUI.dll
Se ritieni che manchino alcuni file, potresti anche descrivere dove si trovano di solito?
Nel passaggio successivo ho avviato msvsmon.exe
e il mio programma sulla macchina b. Sulla macchina a, ho avviato Visual Studio 2008 e la mia soluzione in cui è stato scritto il programma. Quindi scelgo " Debug - Allega al processo " ;. Ho scelto " Trasporto remoto (solo nativo senza autenticazione) " ;. Ho usato l'IP corretto come qualificatore e ho preso il giusto processo (program.exe). Dopo un po 'si è verificato il seguente messaggio in una finestra popup:
Eccezione non gestita su 0x7c812a7b in program.exe: 0xE0434F4D: 0xe0434f4d
Posso continuare o interrompere; Continuando, l'eccezione si verifica ancora e ancora e ancora. Quindi ho premuto break e si è verificato il seguente messaggio:
Nessun simbolo viene caricato per alcun frame di stack di chiamate. Il codice sorgente non può essere visualizzato.
Soluzione
Assicurarsi di copiare il file .PDB che viene generato con il proprio assieme nella stessa cartella sul computer remoto. Ciò consentirà al debugger di prelevare i simboli di debug.
Altri suggerimenti
- Aggiungi una cartella condivisa sul tuo computer di sviluppo che punta alla posizione dei file .pdb
- Imposta una variabile di ambiente chiamata
_NT_SYMBOL_PATH
sul computer remoto che punta alla cartella condivisa sul tuo computer di sviluppo
Il debugger remoto ora cercherà i simboli nella tua macchina di sviluppo. Non è necessario copiarli per ogni build.
Vedi MS Video qui .
Inizia a guardare 8-9 minuti. Dimostra come configurare il debugger remoto per caricare i simboli da una condivisione di unità sulla tua macchina di sviluppo.
Buona fortuna!
- Nel menu Strumenti in Visual Studio 2010, selezionare Opzioni.
- Nella finestra di dialogo Opzioni, aprire il nodo Debug e quindi fare clic su Generali.
- Seleziona Mostra tutte le impostazioni se necessario e individua Abilita solo il mio codice (Solo gestito)
- Deselezionalo e fai clic su OK
Dopo aver collegato il processo remoto
Il debug remoto in .NET non funzionerà se non posizioni i file .PDB nella stessa directory in cui esiste il codice di debug.
Se VS non riesce ancora a trovare l'origine per il debug, il codice di debug e l'origine del progetto VS non sono non la stessa versione . La soluzione sta ricostruendo e ridistribuendo il progetto.
0xE0434F4D è un'eccezione dal CLR (ovvero, codice gestito). È necessario eseguire il debug remoto con autenticazione e scegliere di eseguire il debug del codice gestito. In alternativa, è possibile estrarre le informazioni sull'eccezione gestita utilizzando alcune estensioni di debugger, ma è un po 'più difficile.
References:
1800 INFORMAZIONI è corretto, è necessario eseguire il debug remoto con l'autenticazione di Windows per eseguire il debug del codice gestito, altrimenti non sarà possibile caricare i simboli per gli assembly gestiti. Far funzionare questo con l'autenticazione è piuttosto complicato, in quanto richiede account locali su entrambe le macchine con password identiche, tra le altre cose. Questa domanda e le risposte di tutti sono molto utili per farlo funzionare.
Debug remoto in Visual Studio (VS2008), Windows Forms applicazione
Ho avuto gli stessi problemi. Trovata la risposta nei msdn forum Copierò / incollerò la risposta corretta qui:
Assicurati di utilizzare il versione corretta di msvsmon.exe !!! Questo è tutto! ho avuto lo stesso problema durante il debug remoto di un C # applicazione. Stavo usando x64 msvsmon.exe perché il server è in esecuzione Windows Server 2008 a 64 bit, ma il l'applicazione è stata scritta per x86, quindi io dovuto eseguire la versione x86 di msvsmon.exe per sbarazzarsi di questo fastidioso errore. Nient'altro era necessario. Basta eseguire la versione di msvsmon.exe che corrisponde all'architettura di destinazione dell'applicazione ^ _ ^
Mentre le risposte di cui sopra sono corrette, mi sono imbattuto in casi in cui i PDB creati con l'assembly in fase di debug si trovavano nella posizione remota e non venivano prelevati. Se stai usando TFS o un altro meccanismo di compilazione che supporta la pubblicazione dei simboli di debug, ti consiglio di farlo. Quindi in Opzioni di Visual Studio > Debugging > Symbols puoi aggiungere quella posizione all'opzione Symbol Server per caricare quei simboli ogni volta che vengono trovati corrispondenti.
Questo mi ha permesso di eseguire il debug maledettamente vicino a tutto ciò che è in esecuzione che ho scritto anche se si tratta di un assembly chiamato dinamicamente (qualcosa che non sono riuscito a lavorare per la vita di me quando pubblicavo solo simboli con l'assembly). Approfitta di questa funzionalità molto utile!
Sono stato in grado di farlo funzionare andando su Proprietà progetto, scheda Compila e impostando il percorso di output Build sul mio computer remoto, ad es. \ Myserver \ condivisione \ myappdir
Nella scheda debug ho selezionato Usa macchina remota e impostato su myserver
Mi sono anche imbattuto in questo quando ho usato una configurazione di build personalizzata. ( DEV anziché Debug )
Per correggerlo, ho modificato le proprietà del progetto - > Build - > Output - > Impostazioni avanzate e ho assicurato che l'output - > Impostazione informazioni di debug fosse completo o < strong> PDB-only . La configurazione predefinita Rilascio è in genere impostata su nessuno .
Vai a Strumenti- > Opzioni- > Debugging- > Symbols e aggiungi il percorso ai file .pdb per l'eseguibile. Il percorso sulla mia macchina locale ha funzionato bene.
Secondo la documentazione, per i simboli gestiti (ho provato a collegarmi a un servizio Windows gestito (costruito contro .net 4.5) su una macchina remota con Visual Studio 2012) i simboli dovrebbero essere sulla macchina remota .
Quindi, ho appena mantenuto i simboli (assicurati che corrispondano ai moduli / assiemi dell'applicazione sulla macchina remota) sulla macchina remota, condividendola e riferendomi ad essa tramite le impostazioni dei simboli dal sistema locale (dove vs è in esecuzione).
Nota: il servizio e i simboli non devono necessariamente trovarsi nella stessa directory in cui funziona per me con il servizio windows 2k12 + .net 4.5.
per dettagli:
http://msdn.microsoft. com / it-it / library / bt727f1t (v = VS.100) aspx
Estratto dal link:
Individuazione dei file dei simboli (.pdb)
I file dei simboli contengono le informazioni di debug per gli eseguibili compilati. I file dei simboli dell'applicazione da sottoporre a debug devono essere i file creati durante la compilazione degli eseguibili dell'applicazione. I file dei simboli devono inoltre trovarsi dove possono trovarli il debugger.
• I file dei simboli per le applicazioni native devono trovarsi sul computer host di Visual Studio.
• I file dei simboli per le applicazioni gestite devono trovarsi sul computer remoto.
• I file dei simboli per applicazioni miste (gestite e native) devono trovarsi sia sul computer host di Visual Studio che sul computer remoto.
Saluti!
Ho riscontrato questo problema e le soluzioni precedenti non mi hanno risolto il problema. Nel mio caso, la mia soluzione VS2010 aveva molti progetti. Il progetto che stavo cercando di eseguire il debug in remoto non era non impostato nella mia soluzione VS2010 come Progetto StartUp, perché i miei script di creazione non erano del tutto giusti.
Ho fatto clic con il pulsante destro del mouse sul progetto all'interno della mia soluzione che stavo provando a eseguire il debug e ho selezionato Imposta come progetto di avvio
, quindi i miei simboli sono stati caricati correttamente e il punto di interruzione è stato raggiunto.
Ho avuto lo stesso problema durante il debug remoto, è stato risolto con i seguenti passaggi su VS 2008:
- copi il file pdb locale insieme ai tuoi binari
- Esegui la stessa versione di msvmon per cui è stata creata l'applicazione, Se l'applicazione è stata creata per l'architettura x86, devi eseguire la versione x86 di msvmon, anche se la stai eseguendo su una macchina x64. Avviserà quando si tenta di eseguire, ma dovrebbe funzionare.