Extern Debuggen?

[ralfiii]

Hallo!

Eine unserer Anwendungen friert manchmal ein.

Das Einfrieren ist reichlich schwer zu reproduzieren. Nun hat ein Kollege das erstmalig auf einem Testrechner unter Windows7 geschafft. Dort läuft also der Prozess und tut nix mehr. Nun würde ich gern irgendwie rausfinden wo die Anwendung gerade hängt (ein Methodenname wär ein Traum). Auf dem Rechner ist Delphi nicht installiert. Ich muss den Wurm also irgendwie anders lokalisieren.

Ich hab hier zum Probieren eine kleine App gebaut die sich in einer Endlosschleife aufhängt und wollte nun mit irgendwelchen Tools herausfinden wo der Bug sein könnte.

Der ProcessExplorer von SysInternals bietet wohl einen Callstack, aber die Infos die dort geboten werden sind ... sagen wir mal: kryptisch.

Hilfe!
Danke!

[mkinzler]

Man könnte versuchen dort den Remote-Debugger zu installieren

[shmia]

Du kannst es mal mit dem Dependency Walker versuchen.
Du lädst dein Programm und drückst dann auf F7 (=Start Profiling).
Das Programm startet deutlich langsamer, aber dafür bekommst du jede Menge Info.

Interessant wird's dann, wenn du in deinem Programm die Funktion OutputDebugString() verwendest um überall Meldungen auszugeben.
Der Dependency Walker fängt diese auf und zeigt sie an.

[hoika]

Hallo,

warum loggst du die Aufrufe der Parameter nicht in einer Datei mit ?


Heiko

[ralfiii]

Zitat von hoika:

warum loggst du die Aufrufe der Parameter nicht in einer Datei mit ?

Könnte ich die Anwendung ändern wär ja alles kein Problem, dann stopfe ich sie halt nach und nach mit Log-Messages voll, bis ich weiss wo es hakt.

Das ist aber nicht so.

Stell Dir vor du schreibst ein Programm und bei einem Kunden bleibt die Software GANZ SELTEN hängen.

Der Gedanke ist der: Man bittet den Kunden den Task nicht abzustechen wenn das Programm hängt. Und wenn's dann soweit ist geht man hin und versucht an dem Programm - das nicht speziell vorbereitet wurde - herauszufinden wo die Ausführung gerade hakt. Der Process Explorer sieht da schon vielversprechend aus, der liefert dir von einem beliebigen Programm den Call-Stack. Aber leider in einer dermassen blöden Form, dass man wieder nicht weiss was Sache ist.

[BUG]

Vielleicht wäre dieses Buch für dich interessant: First Fault Software Problem Solving

Ohne zusätzliche Debuginformationen oder Logausgaben wirst du dich mit dem zufrieden geben müssen, was du hast. Du kannst nicht mehr Informationen herausholen als drin sind.

[ralfiii]

Zitat von BUG:

Ohne zusätzliche Debuginformationen oder Logausgaben wirst du dich mit dem zufrieden geben müssen, was du hast. Du kannst nicht mehr Informationen herausholen als drin sind.

Es ist aber einiges da an Info.
Hier z.B. der Stack wie ihn der Process Monitor ausgibt.
Wär doch gelacht wenn man mit den Adressen nicht mehr anfangen könnte...

[ralfiii]

Ok, hier noch ein paar Infos:

Der Remote Debugger ist nur eine Option, wenn der Rechner übers Netz vom Entwicklungs-Rechner aus erreichbar ist.
Er erfordert, dass man die Anwendung mit ein paar speziellen Compiler-Optionen erzeugt (map-file, rsm-file, stack-frames...).
Dann startet man am Zielrechner "rmtdbg105.exe -listen". Danach kann man sich mit dem Zielrechner verbinden (Start/Mit Prozess verbinden/Ip eingeben) und mit dem Prozess verbinden.
Man landet dann in einem nichtssagenden CPU-Fenster mit zwei Zeilen
:7c911231 ntdll.DbgBreakPoint + 0x1
:7c9607a8 ntdll.DbgUiRemoteBreakin + 0x2d
Einfach Play drücken und dann wieder Pause, dann ist zumindest der Callstack OK.
Da kann man sich dann schon ganz orientieren, breakpoints setzen und halt normal mit dem Debugger arbeiten.


Wenn eine Anwendung im Feld spinnt wäre der Process Explorer die Wahl der Dinge. Man muss nichts an der Exe ändern, braucht sie nicht neu zu starten, man kann sich einfach in die Anwendung einklinken und den Stack anschauen.
Blöderweise erkennt man da nicht viel. (siehe Screenshot in vorigem Post).
Man kann für die Anwendung ein Map-File erzeugen und das mit map2dbg (http://code.google.com/p/map2dbg/downloads/list) in ein MS-kompatibles Format konvertieren, dann wird der Output vom Process Explorer etwas besser (siehe Anhang) aber so richtig toll ist das noch nicht. Meine Testapplikation bleibt in einer Routine "Hang" hängen, die sieht man im Callstack nicht)


Ich hab mich nun für ein Recompile entschieden und baue einfach madExcept ein. Dort kann man sagen man will einen Callstack wenn die Anwendung z.B: über 5 sec einfriert. Bild im Anhang. Und das neue Exe muss keinerlei Verbindung zum Entwicklungsrechner haben, funktioniert einfach so. Nach der Fehlersuche wirf ich's aber wieder raus.


Ach ja: Will man Log-Ausgaben die mit OutputDebugString gemacht wurden mitlesen, so empfehle ich DebugView von Sysinternals:
http://technet.microsoft.com/en-us/s.../bb896647.aspx


Hier noch ein paar nützliche Links:

http://blog.eurekalog.com/how-to-deb...ications-hang/
http://stackoverflow.com/questions/2...hi-application