Kommentare zu: HOWTO:Remote Debugging fast and easy

Von: Klischeepunk

Klischeepunk — Tue, 01 Mar 2011 20:34:48 +0000

Das. Ist. Mir. Jetzt. Peinlich.
Vielen dank dir. -.-

Von: Martin Richter

Martin Richter — Tue, 01 Mar 2011 18:21:52 +0000

Ruf mal MSVSMON.EXE mit /? auf. Alles was man in den Optionen einstellen kann, geht auch über Befehlszeilenschalter.
Also ein Batch ist garkein Problem.

Von: Klischeepunk

Klischeepunk — Tue, 01 Mar 2011 08:55:34 +0000

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ß.

Von: Sven

Sven — Sun, 30 Nov 2008 18:15:39 +0000

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.

Von: Jochen Kalmbach

Jochen Kalmbach — Mon, 24 Nov 2008 06:57:29 +0000

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

Von: Martin Richter

Martin Richter — Sun, 23 Nov 2008 21:01:39 +0000

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

Von: Jochen Kalmbach

Jochen Kalmbach — Sun, 23 Nov 2008 20:13:29 +0000

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.