Hallo!

Bei meinem Progamm handelt es sich um einen recht einfach aufgebauten TCP-Server, der permanent große Mengen an Daten (bis zu 200 Datenzätze pro Sekunde) von einem Webservice geliefert bekommt und diese Daten dann an die verbundene Clients weiter verteilt. Das Programm soll auf einem gemietetet Windows-Server im Dauerbetrieb laufen. Es gibt aber ein Problem. Tritt zwar sehr selten auf, aber trozdem ärgerlich. Und zwar stürzt das Programm plötzlich ab. Es erscheint die typiscge Windows-Meldung "Programm funktioniert nicht mehr, Windows kann online nach einer Lösung suchen".

Was ist das für ein Fehler?
Ist das ein AV oder was ist das?
Was ist die häufigste Ursache für ein solches Problem?

Im Debugmodus kann ich das Programm zwar starten, diese dauerhaft im Debugmodus laufen zu lassen ist leider nicht möglich. Sobald der Webservice-Client beginnt die Daten zu saugen friert im Debugmodus alles ein, so viele Datensätze sind es.

Wie kann ich die Stelle (Zeile oder wenigstens die Funktion) im Code finden, die das Problem verursacht?

Im Voraus vielen Dank!

Probiere mal einen Handler mit TApplicationEvents für OnException. Wenn du darin landest, kannst du mit JclDebug aus der JEDI Code Library auch einen Stacktrace erstellen.

Alternativ gibt es mit MadExcept und EurekaLog kommerzielle Alternativen, die dir zeigen wo die entsprechende Exception (die es sein wird und nicht abgefangen wird) auftritt.

Das Einfrieren im Debug-Modus könnte aber auch schon ein guter Hinweis sein. Wenn ich nicht irre, gibt Windows eben diese Meldung aus, wenn ein Programm seine Message-Queue nicht mehr zeitnah verarbeitet - sprich: Es ist zu beschäftigt / überlastet. Einfach zu provozieren mittels einer Dauerschleife im Hauptthread ohne Application.ProcessMessages darin.

Ich würde daher fast darauf tippen, dass dein Programm die Hardware schlicht und einfach überfordert. Man könnte zwar daher gehen und die Verarbeitung der lange dauernden Dinge in einen anderen Thread werfen, damit der Hauptthread brav weiterhin seine Messages bedient, jedoch wird der Thread dann irgendwann seinen Jobs weit hinter her laufen und ggf. den Speicher mit seiner Job-Queue füllen.

Lösungsideen: Wenn der PC eine Multicore CPU hat, und die Verarbeitung parallelisierbar ist, wären mehrere Threads ein Weg. Allerdings auch nur, wenn die CPU-Zeit der Flaschenhals ist (eher selten der Fall). Herauszubekommen, indem du dir mal den Taskmanager beguckst während dein Programm läuft, in dem Register "Leistung". Wenn dort ein Kern voll ausgelastet ist, dann wäre das eine Option (wenn die Aufgabe eben parallelisierbar ist). Sonst nicht.
Eine andere Option wäre schlicht schnellere Hardware. Als erstes würde ich aber versuchen zu gucken, ob sich innerhalb der Verarbeitungsfunktionen nicht einige Geschwindigkeitsfallen befinden, oder gar schon das Kommunikationsprotokoll auf Performance optimieren.

Fazit: Diese Art von Fehler würde ich weniger in einer Exception suchen, als viel mehr ein Performanceproblem vermuten. Ob und wo da die geeigneten Stellschrauben sind dies zu eliminieren ist höllisch individuell.

Vielen Dank für die schnelle Reaktion!

Zitat von jaenicke:

Probiere mal einen Handler mit TApplicationEvents für OnException. Wenn du darin landest, kannst du mit JclDebug aus der JEDI Code Library auch einen Stacktrace erstellen.

Habe das mit Stacktrace noch nie gemacht. Jedi (Jcl und Jvcl) sind bei mir installiert, finde JclDebug aber nicht. Wie genau soll ich vorgehen?

Zitat von jaenicke:

Alternativ gibt es mit MadExcept und EurekaLog kommerzielle Alternativen, die dir zeigen wo die entsprechende Exception (die es sein wird und nicht abgefangen wird) auftritt.

Zeigt mir z.B. EurekaLog genau die Stelle im Code, die das Problem verursacht oder bekomme ich wieder irgendwelche Adressen angezeigt? Wenn das so ist, dann kaufe ich gleich das Programm und spare die Zeit.

Zitat von Medium:

Das Einfrieren im Debug-Modus könnte aber auch schon ein guter Hinweis sein. Wenn ich nicht irre, gibt Windows eben diese Meldung aus, wenn ein Programm seine Message-Queue nicht mehr zeitnah verarbeitet - sprich: Es ist zu beschäftigt / überlastet. Einfach zu provozieren mittels einer Dauerschleife im Hauptthread ohne Application.ProcessMessages darin.

Ich würde daher fast darauf tippen, dass dein Programm die Hardware schlicht und einfach überfordert. Man könnte zwar daher gehen und die Verarbeitung der lange dauernden Dinge in einen anderen Thread werfen, damit der Hauptthread brav weiterhin seine Messages bedient, jedoch wird der Thread dann irgendwann seinen Jobs weit hinter her laufen und ggf. den Speicher mit seiner Job-Queue füllen.

Lösungsideen: Wenn der PC eine Multicore CPU hat, und die Verarbeitung parallelisierbar ist, wären mehrere Threads ein Weg. Allerdings auch nur, wenn die CPU-Zeit der Flaschenhals ist (eher selten der Fall). Herauszubekommen, indem du dir mal den Taskmanager beguckst während dein Programm läuft, in dem Register "Leistung". Wenn dort ein Kern voll ausgelastet ist, dann wäre das eine Option (wenn die Aufgabe eben parallelisierbar ist). Sonst nicht.
Eine andere Option wäre schlicht schnellere Hardware. Als erstes würde ich aber versuchen zu gucken, ob sich innerhalb der Verarbeitungsfunktionen nicht einige Geschwindigkeitsfallen befinden, oder gar schon das Kommunikationsprotokoll auf Performance optimieren.

Fazit: Diese Art von Fehler würde ich weniger in einer Exception suchen, als viel mehr ein Performanceproblem vermuten. Ob und wo da die geeigneten Stellschrauben sind dies zu eliminieren ist höllisch individuell.

Es ist ein Multicore CPU und natürlich wird nicht alles im Hauptthread erledigt. Genauer gesagt es wird praktisch nichts im Hauptthread erledigt. Jeder Datensatz wird von einem neuen Thread für die "Weiterverarbeitung" übernommen. Das verarbeitete Ergebnis landet dann in einem Container. Die Client-Threads (TIdTCPServer) beobachten den Container und greifen sich die neue Daten. Das ganze wird so geregelt, dass eine bestimmte max. Anzahl der Threads gleichzeitig ausgeführt werden.

Die CPU-Auslastung klettert kaum über 15%.

@Medium: Vielleicht verstehe ich dich falsch, aber es geht nicht um die Meldung "Programm reagiert nicht mehr" bzw. "Keine Rückmeldung" sondern um ein Wegschmieren der Anwendung mit der Meldung "Programm funktioniert nicht mehr" der Fehlerberichterstattung bzw. Dr. Watson. Wenn ein Programm nicht mehr reagiert, läuft es trotzdem weiter (eben ohne ProcessMessages & Konsorten), aber wenn es nicht mehr funktioniert, wurde es (aufgrund einer nicht gefangenen Exception) geschlossen.

MfG Dalai

Zitat von romber:

Zeigt mir z.B. EurekaLog genau die Stelle im Code, die das Problem verursacht oder bekomme ich wieder irgendwelche Adressen angezeigt? Wenn das so ist, dann kaufe ich gleich das Programm und spare die Zeit.

Wenn es eine Exception ist, wird die in der Regel von diesen Tools abgefangen (durch mit einkompilierten Code) und du bekommst den Stacktrace aller laufenden Threads, Memorydumps an den Exceptionstellen usw., auch per Mail senden kannst du aktivieren (wenn der Benutzer selbst dir den Bericht schicken können soll).

Auch ein hängendes Programm wird durch Eurekalog durch einen zusätzlichen Thread gut erkannt.

Alternative wäre .dbg Dateien aus den Debuginfos von Delphi zu generieren und diese mitzuliefern, dann bekommst du den Stacktrace auch direkt in den Dr. Watson Logs von Windows.

Schon mal in die Log-Files geguckt?
Ereignisanzeige: eventvwr.msc

Zitat von hathor:

Schon mal in die Log-Files geguckt?
[/B]

Ja, die Meldung bringt mich aber nicht wirklich weiter.

markieren

Code:

Name der fehlerhaften Anwendung: verteiler.exe, Version: 3.0.0.307, Zeitstempel: 0x519431bf
Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 6.1.7601.18015, Zeitstempel: 0x50b83c8a
Ausnahmecode: 0x0eedfade
Fehleroffset: 0x0000c41f
ID des fehlerhaften Prozesses: 0x53d8
Startzeit der fehlerhaften Anwendung: 0x01ce52269adfa062
Pfad der fehlerhaften Anwendung: D:\Projekte\DSA\Verteiler\verteiler.exe
Pfad des fehlerhaften Moduls: C:\Windows\syswow64\KERNELBASE.dll
Berichtskennung: 9b18c2c7-be1a-11e2-95cb-08606e44cb44

Wenn Du im Haupthread auf Nachrichten wartest und das in einer Schleife, dann funktioniert das:

Zitat:

Das Einfrieren im Debug-Modus könnte aber auch schon ein guter Hinweis sein. Wenn ich nicht irre, gibt Windows eben diese Meldung aus, wenn ein Programm seine Message-Queue nicht mehr zeitnah verarbeitet - sprich: Es ist zu beschäftigt / überlastet. Einfach zu provozieren mittels einer Dauerschleife im Hauptthread ohne Application.ProcessMessages darin.

markieren

Code:

Inc(Counter)
If (Counter mod 5)=0 then Application.Processmessages;