HOWTO: RemoteDebugging for Dummies

Kleine Begriffserklärung:

Debugger Host - der Rechner mit der kompletten Entwicklungsumgebung
Remote Target - der Testrechner auf dem das Programm getestet werden soll

In meiner Installation sieht das so aus:

Debugger Host - PIII 900, 256MB, 40GB Festplatte, W2K
Remote Target - PII 166, 32MB, 4GB Festplatte, alternativ Win95, Win98, Win98SE, WinNT 4.0, W2K (s.u.)

Grundvoraussetzungen:

Host und Target haben bei Netzwerkkarten und TCP/IP ist installiert.
Die IP Adresse oder der Hostname des Targets ist bekannt.
Auf dem Target wird ein Verzeichnis angelegt in dem die folgenden Dateien liegen:
MSVCMON.EXE, MSVCRT.DLL, TLN0T.DLL, DM.DLL, MSVCP6O.DLL, MSDIS110.DLL

Bei einem NT Rechner kommt zusätzlich noch die PSAPI.DLL dazu (wenn nicht sowieso schon vorhanden). Die MSVCRT.DLL sollte man ins SYSTEM/SYSTEM32 Verzeichnis kopieren, jedoch ist diese Datei meistens sowieso schon vorhanden. Nach meinen Infos ist der Remotedebugger auf keine spezielle (neuere) Version der MSVCRT.DLL angewiesen. Ich belasse die Datei meistens nur im Verzeichnis in dem auch die anderen Dateien liegen. Am besten erzeugt man sich eine Diskette mit den entsprechenden Dateien (ja es geht alles auf EINE Diskette) und die hat man immer griffbereit.

Vorgehensweise:

Idealerweise gibt man auf dem Testrechner selbst oder auf einem Server im Netzwerk einen Bereich frei, auf dem sowohl Host, als auch Target Zugriff haben. Dieses Verzeichnis kann das normale Installationsverzeichnis sein in dem die gesamte Programmumgebung installiert ist.
Auf dem Host wird im DevStudio unter "Build->Debugger Remote Connection". Statt "Local", "TCP/IP" ausgewählt. Nicht vergessen unter Settings den Hostnamen oder die IP Adresse des Zielrechners anzugeben.
Im Bereich "Project Settings->Debug->General" wird unter "Remote executable path and file name" Das Zielverzeichnis mit dem kompletten Namen des Programmes angegeben. Alle anderen Einträge dieser Seite bleiben wie man es eben haben möchte.
Im Bereich "Project Settings->Post-build step" wird die folgende Befehlszeile eingefügt:
copy $(TargetPath) $(RemoteTargetPath)
Durch diesen kleinen Trick wird nach jedem Link Vorgang die EXE Datei sofort auch im Debug Ziel aktualisiert.
Allerdings erfordert dies, dass das zu testende Programm von Host und Target gesehen auf dem selben Laufwerk liegt. Entweder man verwendet einen UNC Pfad oder ein identisches Laufwerks-Mapping. In meiner Installation liegt immer alles unter einem speziellen Ordner auf dem Server (Y:\Projekt\ZuTestendesProgramm\Programm.exe).
MSVCMON.EXE auf dem Target-Rechner starten und "Connect" auswählen. Die "Settings" haben keine Bedeutung (oder ich habe deren Bedeutung nicht begriffen).
Und mit einem Go (F5) kann es los gehen.
Beim ersten ersten Start der Debug Session versucht der Debugger auch für DLL's die geladen werden die Symbol-Tabellen des Targetsystem mit denen des Hostrechners zu synchronisieren, das geht natürlich nur wenn die vorhanden oder eben identisch sind, also bei gleichem OS. Für eigene DLL's kann dies aber ohne Probleme gleich mit geschehen. Man kann diese nervige Abfrage aber auch gleich Abbrechen nachdem man den kleinen Schalter "Try to locate other DLL's" ausgeschaltet hat.
Evtl. DLL's die unbedingt in den Debug Vorgang eingeschlossen werden sollen, lassen sich unter dem Karteireiter "Project Settings->Debug->Addiontal DLL's" korrigieren oder vorgeben.
Die Exe Datei wird wie von Geisterhand auf dem Target-System mit der Angabe der Programmparameter gestartet und man kann nun Debuggen wie man es gewohnt ist. Alle Funktionen wie Stacktrace, Register, Watch-Window stehen uneingeschränkt zur Verfügung.

Vorteile:

Das Remotedebugging verfälscht nicht die Systemumgebung durch Komponenten, die durch die Entwicklungsumgebung installiert werden.
Mit einer Diskette un den entsprechenden Dateien, kann man sofort auf jedem Rechner eine RemoteDebugging-Session starten. Ich benötige nur eine TCP/IP Verbindung. Das geht sogar über eine Remote-Verbindung!
Man hat immer gleiche Testvoraussetzungen.
Ein brutaler Crash bringt nur das Target aber nicht den Host aus dem Tritt.
Man kann Fenster Aktivierungen und auch OnPaint/WM_PAINT Nachrichten perfekt testen.
Auch in Testfeldern, in denen an Rechnern nichts mehr verändert werden darf, kann ein Entwickler sofort eingreifen und selbst im "Prerelease-Canidate" noch Bugs finden.
u.v.a. mehr die mir alle nur gerade nicht einfallen...

Schmerzlich vermisst wird:

"Attach to Process" auf dem Remote Computer geht leider nicht!

Tips:

Der Targetrechner kann mit der Hilfe von DriveImage und Norton Ghost über Images schnell auf andere Betriebssysteme umgestellt werden. Testen unter Win95, Win98, WinNT, Win2000 ist eine Sache von 10 Minuten laden eines Images.
Auch die Release Version immer mit einer "Debug Informationen" (also PDB Dateien) erzeugen lassen. Und diese mit dem "Release-Canidate" Archivieren. Im Zusammenspiel mit SourceSafe kann man sogar Bugs in Uralt-Versionen aufspüren.

Weitere Infos:

MSDN Library - January 2001
  Visual Studio 6.0 Documentation
    Visual C++ Documentation
      Using Visual C++
        Visual C++ Programmer's Guide
          Debugging
            Debugging Specific Types of Applications
              Debugging Remote Applications

Ich hoffe nichts vergessen zu haben. Wenn ja einfach ein kurzes Feedback und ich werde den Artikel anpassen.

Martin Richter

Auszug aus dem Original Message-Header:

  From        : "Martin Richter [MVP]" mailto:martin.richter@grutzeck.de
  Organization: Grutzeck-Software GmbH
  Subject     : KNOWHOW: "RemoteDebugging for Dummies"
  Date        : Thu, 25 Jan 2001 11:32:22 +0100
  Newsgroups  : microsoft.public.de.vc
  Message-ID  : <3a7000b6$1@news.grutzeck.de>