Perché non vengono caricati simboli durante il debug remoto?

Question

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.

Answer 1

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.

Answer 2

1. Aggiungi una cartella condivisa sul tuo computer di sviluppo che punta alla posizione dei file .pdb
2. 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!

Answer 3

• 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

Answer 4

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.

Answer 5

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:

Se rotto è ...

Answer 6

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

Answer 7

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 ^ _ ^

Answer 8

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!

Answer 9

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

Answer 10

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 .

Answer 11

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.

Answer 12

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!

Answer 13

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.

Answer 14

Ho avuto lo stesso problema durante il debug remoto, è stato risolto con i seguenti passaggi su VS 2008:

1. copi il file pdb locale insieme ai tuoi binari
2. 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.