Debugger für Unterwegs?

Plotter

Hallo zusammen

Ist vielleicht eine merkwürdige Frage, aber gibt es so was wie einen Debugger für Unterwegs? Ich programmiere in Visual Studio 2003. Es kann vorkommen, dass ich eine Debug-Version rausgebe, und dann, bei einem Absturz, halt die Informationen abfragen möchte, die ich sonst bei meinem Arbeitsplatz auch habe. Nur bei einem Kunden oder im Haus bei den durchlaufenden Maschinen immer Visual Studio installieren, um einen Effekt erklärt zu bekommen, ist meistens nicht möglich oder zu umständlich. Einfacher wäre es, einen USB-Stick anzuschliessen und dann zu debuggen.

Gibt es so etwas?

Danke für eure Hilfe!

estartu

Es gibt wohl die Möglichkeit, per Fernsteuerung zu debuggen - aber außer der vagen Ahnung habe ich dazu keine Infos.

Ich baue in mein Programm einen Loggingmechanismus ein, dann kann man zur Laufzeit gleich gucken, was ist. Muss allerdings orgentlich gepflegt werden und ein nachträglicher Einbau ist eine Höllenarbeit.
Das Teil funktioniert zum Teil wie filterbare TRACEs.

Plotter

Danke für deinen Beitrag. Ich versuche gerade auch noch, mich über Remote Debugger schlau zu machen. Scheint von VS 2003 aus die einzige Möglichkeit zu sein.

Was meinst du mit deinem Logginmechanismus? Wie machst du das und was kannst du damit machen?

estartu

Trace kennst du?

Ich trace eben mit ein paar Zusatzdaten (Zeitstempel, Aktionsnummer, Benutzer) in ein anderes Programm, was mit dem eigentlichen Programm zusammen gestartet und auch beendet wird. Das Log-Programm bekommt die einzelnen Traces per Message, so geht im eigentlichen Programm nur unmerklich Zeit verloren.

An interessanten Stellen gebe ich dann also Meldungen aus:

void CErgebnisView::OnBtnGemHeuteLi() 
{
	CLog::Log(LOG_NR_FUNKTION_BEGINN, _T("CErgebnisView::OnBtnGemHeuteLi()  Anfang"));
	m_edtGemDatLi.SetNow();
	CLog::Log(LOG_NR_FUNKTION_ENDE, _T("CErgebnisView::OnBtnGemHeuteLi()  Ende"));
}

Das CLog ist das Tracen. Das kann auch noch Meldungen an den Benutzer rausgeben UND gleichzeitig loggen.

Ich mache das zwar auch an Stellen, wo es etwas überflüssig ist, aber unsere Benutzer (ist ein firmeninternes Programm) haben GRUNDSÄTZLICH nichts gemacht.
Die sind sich nie einer Schuld bewußt, und dann kann man eben in den Dateien (die kann man auf Wunsch erstellen), nachgucken und man sieht, welche Funktionen mit welchen Parametern usw. aufgerufen wurden.

Nach der Testphase kann man die Meldungen über eine Konfigurationsoberfläche einschränken, so, dass z.b. nur noch schreibende Datenbankzugriffe protokolliert werden.

Ich habe mit einem ähnlichen Verfahren aus einem anderen Projekt sehr gute Erfahrungen.
Dieses Projekt ist noch nicht so weit, dass es vom Endnutzer getestet wird.

Wenn du einen Screenshot haben magst, sag was - ich muss nur vorher noch einen gerade gefunden Fehler ausmerzen...

Plotter

An so was habe ich natürlich auch schon gedacht, nur ist der Aufwand, wie du schreibst, recht enorm, vor allem, wenn noch gar nichts existiert. Und die Software hat halt schon einen ordentlichen Umfang, da ist es fast unmöglich, das noch geschickt nachträglich einzubauen

Unix-Tom

Du hast eh schon selbst gefunden. Remotedebug.
Man sollte aber eigentlich keine Debug-Version rausgeben.
Und wenn man etwas einem Kunden gibt dann sollte das eigentlich schon getestet sein. Fehler sollte man abfangen und wie schon beschrieben sollte ein TRACE möglich sein.
Ich frage ich welche Firma sich eine DEBUG-Version andrehen läßt.

Plotter

Och weisst du, die Kunden haben meist keine Ahnung, ob es eine DEBUG oder RELEASE Version ist, sie wundern sich manchmal höchstens über die grösse und denken, die Version könne dann mehr. Aber hast recht, normal verschicke ich auch keine DEBUG-Versionen, aber wenn das Feuer brennt, ist es egal, womit man es löscht.

Aber ich danke euch jedenfalls für eure Inputs. So etwas, wie ich es mir wünschte, existiert offenbar nicht. Also heisst es Remote-Debugging.

peterchen

Du kannst eine Menge Infos von den Systemen einsammeln, auch wenn du nicht "vor Ort" bist.

(1) Remote Debuggen
Dazu muß auf dem remote server zumindest eine Unterstützung intalliert sein, geht nicht "vom USB Stick". dann kannst du dich mit einem beliebigen Prozeß per Intranet verbinden. Ich hab das mal mit VC6 durchgezogen, war aber eine Schinderei.
WinDbg (SDK Tools) brauchst du nicht zu installieren, ist aber halt... sehr rudimentär.

(2) Du kannst für einen Release-Build auch Debug-Informaitonen generieren.
Dazu für den Compiler DebugInfo:Programmdatenbank einstellen, und im Linker "DebugInfo generieren" einschalten. Dann bekommst du separate .pdb-Dateien für deine binaries. Die .pdb's behältst du (zusammen mit den binaries des compile-laufs), nur die binaries lieferst du aus.

(3) Crash-Info einsammeln
Auf allen Systemen bekommst du die zumindest die Basis-Crashinfo (Crash-Adresse, Exception, Stack Trace, Register). Mit den entsprechenden Tools (MSDN) kommst du damit an die Crash-Adresse, und bekommst ziemlich gut raus,
was passiert ist.

Auf einem neueren System bekommst du außerdem einen 64K "MiniDump". Normalerweise wird angeboten, diesen an MS zu senden (wo halt jeder "Don't send" klickt), kannst du in deiner Anwendung aber auch umleiten. Unter VS7 und aufwärts kannst du diesen Minidump importieren, um an die Stelle des Crash zu kommen.

http://www.google.com/custom?q=MiniDump+site%3Acodeproject.com&sitesearch=

Je nach Optimierungseinstellungen brauchst du zwar ein wenig Assemblerkenntnisse, aber das geht oftmals gut. Man kann auch für Testfälle einen "checked build" ohne Optimierungseinstellungen in Reserve halten.

(4) MS gibt dir normalerweise keine Redistribution Licence für die Debug-Laufzeitbibliotheken (nur mal so als Hinweis...)