Warum werden keine Symbole geladen, wenn Remote-Debugging?

https://stackoverflow.com/questions/151966

02-07-2019
|

Frage

Ich möchte Remote-Debugging verwenden. Das Programm, das ich zu debuggen läuft auf Maschine b. Visual Studio läuft auf der Maschine.

Beim Einschalten der Maschine b ich einen Ordner mit den folgenden Dateien:

msvcr72.dll
msvsmon.exe
NatDbgDE.dll
NatDbgDEUI.dll
NatDbgEE.dll
NatDbgEEUI.dll

Wenn Sie denken, einige Dateien fehlen, können Sie auch beschreiben, wo sie sind in der Regel liegt

Im nächsten Schritt begann ich die msvsmon.exe und mein Programm auf der Maschine b. Auf der Maschine, begann ich Visual Studio 2008 und meine Lösung, in der das Programm geschrieben wurde. Dann habe ich "Debug - Attach to Process" wählen. Ich entschied mich für „Remote Transport (Muttersprache nur ohne Authentifizierung)“. Früher habe ich die richtige IP als Qualifier und nahm den richtigen Prozess (program.exe). Nach einer Weile kam die folgende Meldung in einem Popup-Fenster:

Nicht behandelte Ausnahme bei 0x7c812a7b in program.exe: 0xE0434F4D: 0xe0434f4d

Ich fahre fort oder brechen kann; Wenn weiterhin, tritt die Ausnahme wieder und wieder und wieder. So drückte ich Pause und die folgende Meldung aufgetreten:

Keine Symbole werden für jeden Anruf Stapelrahmen geladen. Der Quellcode kann nicht angezeigt werden.

Lösung

Stellen Sie sicher, dass Sie die PDB-Datei kopieren, die mit Ihrer Assembly in demselben Ordner auf dem Remote-Computer erzeugt wird. Dies wird dem Debugger, um Pickup die Debug-Symbole ermöglichen.

Andere Tipps

Fügen Sie einen freigegebenen Ordner auf Ihrem dev Maschine, die an die Stelle der PDB-Dateien verweist
Stellen Sie eine Umgebungsvariable aufgerufen _NT_SYMBOL_PATH auf dem Remote-Computer, die auf Ihrer dev Maschine auf den freigegebenen Ordner verweist

Der Remote-Debugger wird nun Ihre Dev-Maschine für Symbole suchen. Keine Notwendigkeit, sie für jeden Build kopieren über.

Siehe MS Video hier .

Starten Sie beobachten 8-9 Minuten. Er zeigt, wie die Remote-Debugger-Setup-Symbole von einem Laufwerksfreigabe auf dem Entwicklungscomputer zu laden.

Viel Glück!

Im Menü Extras in Visual Studio 2010 auf Optionen.
Im Dialogfeld Optionen öffnen Sie das Debuggen von Knoten und dann General klicken.
Überprüfen Sie zeigen alle Einstellungen, wenn nötig, und suchen Sie Aktivieren Just My Code (Verwalteter nur)
Deaktivieren Sie es und klicken Sie auf OK

Nachdem Sie den Remote-Prozess anhängen

Remote-Debugging in .NET wird nicht funktionieren, wenn Sie nicht legen Sie die PDB-Dateien in das gleiche Verzeichnis , wo der debuggt Code vorhanden ist.

Wenn VS noch nicht Quelle für die Fehlersuche finden, der debuggt-Code und die VS-Projekt Quelle ist nicht die gleiche Version . Die Lösung wird wieder aufzubauen und das Projekt Umschichtung.

0xE0434F4D ist eine Ausnahme von der CLR (das heißt, verwalteten Code). Sie müssen Remote-Debugging mit der Authentifizierung zu tun, und wählen Sie verwalteten Code debuggen. Alternativ dazu ist es möglich, die verwaltete Ausnahme info mit einigen Debugger-Erweiterungen zu extrahieren, aber es ist ein bisschen mehr harte Arbeit.

Referenzen:

Wenn gebrochen ist ...

1800 INFORMATION richtig ist, haben Sie Remote-Debugging mit dem Windows-Authentifizierung, um zu tun, um Debug-Code verwaltet werden, sonst werden Sie nicht in der Lage sein, die Symbole für verwaltete Assemblys zu laden. Immer diese mit Authentifizierung zu arbeiten ist ziemlich heikel, da es lokale Konten auf beiden Maschinen mit identischen Passwörtern unter anderem erfordert. Diese Frage aller Antworten sind sehr nützlich für diese Arbeiten zu bekommen.

Remote-Debugging in Visual Studio (VS2008), Windows Forms Anwendung

Ich hatte die gleichen Probleme. Konnten Sie die Antwort auf die Msdn Foren ich werde kopieren / gerade hier die richtige Antwort ein:

Stellen Sie sicher, dass Sie verwenden die korrekte Version von msvsmon.exe !!! Das ist alles, es war! Ich hatte das gleiche Problem, während Remote eine C # Debuggen Anwendung. Ich war mit x64 msvsmon.exe, da der Server läuft Windows Server 2008 64-Bit, aber die Anwendung wurde für x86 geschrieben, so dass ich hatte die x86-Version von ausführen msvsmon.exe um loszuwerden diese lästigen Fehler. Nichts anderes war erforderlich. Führen Sie einfach die Version von msvsmon.exe dass entspricht der Zielarchitektur Ihre Anwendung ^ _ ^

Während die oben genannten Antworten sind richtig, ich in Fällen lief, wo die PDBs, die mit Montage gebaut wurden am entfernten Standort an Ort und Stelle ausgetestet wurden, und abgeholt wurden nicht eingehalten. Wenn Sie TFS oder einen anderen Build-Mechanismus verwenden, die Symbole der Veröffentlichung Ihrer Debug unterstützt, würde ich empfehlen, es zu tun. Dann in Visual Studio Optionen> Debuggen> Symbole Sie diese Position auf der Symbol-Server-Option hinzufügen, können diese Symbole, wann immer sie gefunden zu laden sind entsprechen.

Das hat mir in der Nähe etwas gestopft debug erlaubt, die, dass ich laufen, selbst geschrieben, wenn es dich um eine dynamisch genannt Baugruppe (etwas, das ich nicht für das Leben von mir bekommen könnte zu arbeiten, wenn nur Symbole mit der Montage Veröffentlichung) ist. Nutzen Sie diese sehr praktische Funktion!

Ich konnte diese Arbeit bekommt von Eigenschaften gehen Projekt, Kompilieren Registerkarte und den Build-Ausgabepfades zu meinem Remote-Rechner zB Einstellung \ Myserver \ myshare \ myappdir

In der Debug-Register Ich habe Sie auf Remote-Maschine überprüft und auf MYSERVER

Ich lief auch in dieser, wenn eine benutzerdefinierte Build-Konfiguration mit . ( DEV statt Debug )

Um dies zu korrigieren, ich geändert, um die Projekteigenschaften -> Build -> Ausgabe -> Erweiterte Einstellungen und gewährleistet die Output -> Debug Info Einstellung war voll oder pdb- nur . Der Standard Freigabe Konfiguration wird in der Regel auf keine .

Gehen Sie auf Tools-> Optionen-> Debugging-> Symbole und fügen Sie den Pfad zu den PDB-Dateien für die ausführbare Datei. Der Weg auf meinem lokalen Rechner funktionierte gut.

Laut Dokumentation für verwaltete (habe ich versucht, auf einen verwaltetes Windows-Dienst Befestigung (gebaut gegen .net 4.5) auf Remote-Computer mit Visual Studio 2012) die Symbole sollten sein auf der Fernbedienung Maschine.

Also, ich habe gerade gehalten Symbole (stellen Sie sicher, sie passen die Module / Baugruppen der Anwendung auf Remote-Rechner) auf Remote-Rechner, sie teilen und bezeichneten über Symbol Einstellungen von lokalem System, um es (wo vs läuft).

. Hinweis: der Service und die Symbole müssen nicht auf demselben Verzeichnis wie seine Arbeits für mich mit 2k12 + .net 4.5 Windows-Dienst

für Details:

http://msdn.microsoft. com / en-us / library / bt727f1t (v = VS.100) aspx

Auszug aus dem Link:

Lokalisierung Symbol (PDB) Dateien

Symboldateien enthalten die Debug-Informationen kompiliert ausführbare Dateien. Die Symboldateien der Anwendung werden müssen die Dateien auf Fehler, die erstellt wurden, wenn die Anwendung ausführbare Dateien erstellt wurden. Die Symboldateien müssen auch entfernt werden, wenn der Debugger sich finden kann.

• Die Symboldateien für native Anwendungen müssen auf dem Visual Studio Host-Computer befinden.

• Die Symboldateien für verwaltete Anwendungen müssen auf dem Remote-Computer befinden.

• Die Symboldateien für gemischte (verwaltet und unkomprimiert) Anwendungen müssen sowohl auf den Visual Studio Host-Computer und den Remote-Computer.

Viele Grüße!

Ich lief in dieser Frage und die oben genannten Lösungen hat es nicht für mich zu beheben. In meinem Fall hatte meine VS2010-Lösung viele Projekte in ihm. Das Projekt, das ich versucht wurde remote debug war nicht in meiner VS2010-Lösung als Startprojekt festgelegt, weil mein Make-Skripte war nicht ganz richtig.

I Rechtsklick auf dem Projekt in meiner Lösung wurde ich zu debuggen versuchen und Set as StartUp Project ausgewählt und dann geladen meinen Symbolen richtig und mein Haltepunkt getroffen wurde.

Ich hatte das gleiche Problem beim Remote-Debugging, es mit den folgenden Schritten auf VS 2008 aufgelöst wurde:

Sie kopieren die lokale PDB-Datei zusammen mit Ihren Binärdateien
Führen Sie die gleiche Version von msvmon wie Ihre Anwendung für gebaut wurde, Wenn Ihre Anwendung für x86-Architektur aufgebaut ist, müssen Sie die x86-Version von msvmon laufen, auch wenn Sie es auf x64-Maschine ausgeführt werden. Es wird Warnung ausgeben, wenn Sie ausführen versuchen, aber es sollte laufen.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow