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. 

  1. 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.
  2. Beim ersten Start erhalten wir eine Warnung, dass wir die Firewall von XP SP2 oder Vista noch freischalten müssen. Gesagt getan.
  3. 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.
  4. 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
  5. WOW! Und schon sieht man seinen Prozess den man debuggen möchte.
  6. 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