Vor Jahren habe ich dazu bereits mal einen Artikel für VC6 veröffentlicht: Remote Debugging for Dummies! BTW: Es war überhaupt mein erster Artikel!
Also Zeit für ein kleines Upgrade.
Anmerkung: Mir geht es hier nur um natives Debuggen von C++ (also unmanaged Code), wen wird es wundern ? 😉
Für mich das ultimative Mittel der Qualitätssicherung und die beste Waffe für die Jagd auf den gemeinen Software-Bug ist und bleibt Remote Debugging.
Remote Debugging ist seit es Visual Studio 2002 gibt so einfach geworden wie noch nie. Und seit es Visual Studio 2005 ist es noch einen Tick einfacher geworden. Einziger Wermuthstropfen: Remote Debugging ist erst ab der Professional Version verfügbar.
Um so erstaunlicher wie wenig Entwickler dieses Werkzeug einsetzen.
Nehmen wir einfach mal den Fall, wir haben auf einer Maschine einen Crash, oder wir haben einen Zustand, den wir sofort Debuggen wollen. Geht das On-the-fly?
JA ❗
Wenn die Rechner in einer Domäne sind, gibt es meistens gar keine Probleme und man kann einfach wie folgt vorgehen.
- Wir kopieren die Datei MSVSMON.EXE auf den Rechner auf dem wir Debuggen wollen:
„C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe“
Ja! Erstaunlich, mehr ist nicht notwendig. - Beim ersten Start erhalten wir eine Warnung, dass wir die Firewall von XP SP2 oder Vista noch freischalten müssen. Gesagt getan.
- Nun wählen wir einfach die schnelle etwas unsichere Methode:
Menü Tools -> Options
In dem entsprechenden Dialog, wählen wir nun einfach:
No Authentication (native only)
Allow any user to Debug
Port 4015 bleibt unverändert.
Am Besten jetzt noch die Maximum idle time (seconds) von 900 auf was Brauchbares hoch setzen, sonst wird die Session einfach beendet nach 15 Minuten. - Ja ❗ Das wars. Nun einfach im Visual Studio Tools -> Attach to Process wählen (Strg+Alt+P)
Transport: Remote (Native only with no authentication)
Qualifier: <Name des PCs den es zu debuggen gilt, oder IP-Adresse>
Refresh - WOW! Und schon sieht man seinen Prozess den man debuggen möchte.
- Jetzt nur noch auswählen und Attach
So einfach geht es.
Wenn man die passenden PDB Dateien in Reichweite hat, kann man sofort Breakpoints setzen und am „lebenden Patienten“ operieren, als nur „post-mortem“ mit Crashdumps zu arbeiten.
Wie man gezielt auch die Projekteinstellungen nutzen kann, habe ich mir für einen späteren Artikel vorgemerkt. 😉
Siehe auch:
How to: Set Up Remote Debugging
Hallo Martin,
das hört sich zwar alles schön an, aber das (schöne) gilt leider nur für die Release-Version (wenn Du gegen die DLL-Version der CRT/MFC linkst). Dann ist es wirklich einfach.
Sobald Du aber gegen die Debug-Version linkst und diese auch debuggen willst, dann kann das ganze zu (manifest) Chaos werden!
Ich habe hier ein Fall, dass ich eine große Verteilte Anwendung habe (verteilt meint damit, dass es „globale DLLs“ gibt, welche in einem PATH-Verzeichnis liegen) und die Anwendung diese DLLs benötigt. Jetzt ist sogar das Starten der Debug-Version kaum möglich, da die CRT-DLLs nicht korrekt gefunden/geladen werden können. Es kommt sogar vor, dass *dieselbe* Version der CRT-DLL *zweimal* in den gleichen Prozess geladen wird, was natürlich zum kompletten Chaos führt.
Also: Zuverlässig geht es nur in simplen Fällen oder in der Release-Version.
Ich verstehe noch nicht ganz, was Dein Einwurf mit Remote Debugging zu tun hat. Dass die einzelnen Komponenten zueinander passen müssen ist klar… Wie ändert das Remote Debugging, das Verhalten der Anwendung? Das habe ich noch nicht erlebt. Zudem wemn man sich gerade verspätet (also per Attach) in den Prozess einklinkt.
Deine Schilderung hört sich nach einem Mix von Release und Debug Versionen an… Das kann nur gut gehen, wenn die Module autark arbeiten
Hallo Martin,
Du hast natürlich recht, es hat prinzipiell nichts mit Remote-Debugging zu tun. Es geht auch ohne Remote-Debugging nicht 😉
Und es ist wirklich kein Mix aus Release und Debug, sondern alles gegen due gleiche VS-version und alles enthält das gleiche Manifest… aber ich muss es mal genau nachvollziehen…
Hab es aber trotzdem noch nicht zuverlässig geschafft eine Debug-version zum Laufen zu bekommen.
Greetings
Jochen
Martin, vielleicht solltest Du noch darauf hinweisen, dass es für x86 und x64-Anwendungen verschiedene Versionen des Remote Debuggers gibt. Deine Anleitung dürfte nur bei 32-bit Anwendungen funktionieren.
Das Debuggen von Debug-Versionen funktioniert bei mir problemlos mit VPC-Systemen, allerdings verwende ich generell nur manifestlose CRT/MFC-Module. Da reicht es ja, wenn sich die Dlls alle in einem Verzeichnis befinden. Mit dem Remote-Debugger geht es wesentlich fixer, als VS 2008 im VPC laufen zu lassen.
Hi,
ich weiss der Beitrag ist ein paar Tage alt, trotzdem stoß ich immer wieder auf ihn, wenn ich Infos zum Remote Debugging such, daher frag‘ ich einfach mal munter drauf los in der Hoffnung auf Hilfe.
Ich finde leider keine Infos ob und wieweit die msvsmon.exe aus der Kommandozeile zu steuern ist. Ist hierzu was bekannt?
Relevant wäre hierbei:
– Starten (okay, aufruf msvsmon.exe)
– Permission f. Domänenkonto erteilen
– Aufruf ohne Authentication (auf $Port bzw. 4015 ist mir eigentlich egal)
Gedanke ist: Ich hab ein 2tes System, an dem aber fgw. jemand fremdes arbeitet – und statt dem jedesmal zu erklären „bitte klicke hier, bitte klicke da, okay nun können wir testen“ würde ich gern eine batch/eine Verknüpfung ablegen die das automatisch übernimmt.
Ansonsten danke für die Anleitung – waren meine ersten Schritte mit dem Remote Debugger und ich bin grenzenlos begeistert. So macht entwickeln im Netz Spaß.
Ruf mal MSVSMON.EXE mit /? auf. Alles was man in den Optionen einstellen kann, geht auch über Befehlszeilenschalter.
Also ein Batch ist garkein Problem.
Das. Ist. Mir. Jetzt. Peinlich.
Vielen dank dir. -.-