Fehlersuche - Suchbereich eingrenzen?

[romber]

Hallo!

Folgendes Problem: mein Programm stürzt ab und zu komplett ab. Dabei erscheint die allgemein bekannte Windows-Fehlermeldung, das Programm hat aufgrund eines Problems nicht richtig funktioniert usw. (s. Bild im Anhang). Die wochenlange Fehlersuche hat dem Programm zwar gutgetan, da Unmenge an Denk- und Programmierfehlern korrigiert wurden, das eigentliche Problem wurde aber nicht gelöst. MadExcept hat mich auch nicht weitergebracht, da es nicht mehr ausgelöst wird, wenn das Programm abgestürzt ist.

Gibt es die Möglichkeit, bei der Fehlersuche den Suchbereich anhand des Fehlertyps etwas einzugrenzen? Ich meine, es gibt verschiedene Fehlertypen, oder besser gesagt Fehlermeldungen, die dabei entstehen. Es gibt z.B. Access Violations, die meistens relativ einfach zu beheben sind. Oder das Programm kann sich einfach aufhängen mit der Meldung "Das Programm reagiert nicht". In diesem Fall könnte neben anderen Ursachen z.B. unsychronisierten Zugriff auf die GUI oder hängende Threads sein. Gibt es vielleicht für den von mir beschriebene Fehlertyp irgendwelche ganz typische Ursachen?

Zusätzlich würde mich natürlich interessieren, wie Ihr, die erfahrenen Programmierer, in so einer Situation machen würdet.

Vielen Dank im Voraus!

[Luckie]

Da ist doch die Schaltfläche "Debuggen".

[Gruber_Hans_12345]

würd mal zwei Sachen berücksichtigen
wenn MultiThread dann schauen ob da irgendwo eine Konflikt zwischen den Thread exisitert und lieber mal mehrere Sachen per CriticalSection sichern.
und auf jeden Fall sowas wie FastMM4 mit FullDebug reinhängen und schaun ob Speicherlöcher bzw in deinem Fall, ein Zugriff auf einen bereits freigegebene Speicherstelle, oder co passieren

[a.def]

Wenn bei mir der Debugger absolut nicht mehr weiterhilft, dann setze ich an verschiedensten Stellen im Programmablauf Message-Boxen.
Wenn ich 10 Boxen setze durchnummeriert von 1 bis 10 und bei 5 das Programm abschmiert weiß ich, das Problem ist eventuell zwischen 1 und 5.

[EWeiss]

Zitat:

Da ist doch die Schaltfläche "Debuggen".

Bringt überhaupt nix es sei denn man hat sehr gute ASM Kenntnisse.

Wenn dein Programm keine Fehlermeldung ausgibt und trotzdem abstürzt
dann schaue mal unter

Computerverwaltung/Ereignisanzeige/Windows Protokolle/Anwendungen.. nach welcher Fehler Aufgetreten ist.

gruss

[hoika]

Hallo,
MadExcept hat mich auch nicht weitergebracht, da es nicht mehr ausgelöst wird, wenn das Programm abgestürzt ist.

Das kann ich so nicht stehen lassen.
MadExcept würde ja vor dem Absturz eine Meldung bringen.

mein Programm stürzt ab und zu komplett ab.
Hier musst du ansetzen.
Stürzt es bei dir oder beim Kunden (?) ab?.
Ist es nachvollziehbar?

und hier alles angeknippst?
Bereichsprüfung
IO-Prüfung
Überlaufprüfung

[a.def]

Alleine schon durch das Abklären von "ab und zu" hat man eigentlich schon die grobe Richtung und weiß wo man ansetzen muss.
Stell dir einfach mal die Frage "Was habe ich als letztes gemacht?".

[Zacherl]

Zitat von EWeiss:

Zitat:

Da ist doch die Schaltfläche "Debuggen".

Bringt überhaupt nix es sei denn man hat sehr gute ASM Kenntnisse.

Wenn man beim Builden eine Map-Datei erstellt, werden in fast jedem externen Debugger die Symbole daraus angezeigt. Anhand der Methodennamen und des Callstacks kann man sich dann auch ohne großartige Assembler-Kentnisse oft ziemlich gut orientieren.

[stahli]

Es wären sicher einige Konkretisierungen sinnvoll.

Ist der Abbruch so unter Debug-Kontrolle durch die IDE?
Hast Du eigene Threads erzeugt? Wie viele? Was tun die grundsätzlich?
Hast Du eine try...except-Behandlung in den Execute-Methoden?

Wenn man das nicht wirklich debuggen kann, kann man sich mit Logs heran tasten.
Komfortabel ist CodesiteLogging, aber das kann die Abläufe der Threads schon stören.

Manchmal ist es daher sinnvoller, in Stringlisten oder Textfiles zu loggen.

[EWeiss]

Zitat von Zacherl:

Zitat von EWeiss:

Zitat:

Da ist doch die Schaltfläche "Debuggen".

Bringt überhaupt nix es sei denn man hat sehr gute ASM Kenntnisse.

Wenn man beim Builden eine Map-Datei erstellt, werden in fast jedem externen Debugger die Symbole daraus angezeigt. Anhand der Methodennamen und des Callstacks kann man sich dann auch ohne großartige Assembler-Kentnisse oft ziemlich gut orientieren.

Danke.
Muss ich mal testen.

Habe mir meine Infos immer aus den Windows Logs geholt.
Kam bisher gut damit zurecht.

gruss