Exception in Laufzeitbibliothek einfangen unter Win 2019 server

[Jelen]

Hallo,
seit einiger Zeit knabbere und google ich jetzt schon zu diesem Problem, ohne Erfolg , ich hoffe jemand hat eine Idee dazu.
Ich habe eine Anwendung mit 2 Laufzeitbibliotheken (bpl). Wenn in einer der Laufzeitbibliotheken eine Exception auftritt und das Programm unter Windows 2019 Server läuft, verabschiedet es sich kommentarlos und hinterlässt nur den nichtssagenden 0x0eedfade-Exception Code im Event Viewer.
Unter Windows 11 und Windows 10 verhält es sich erwartungskonform, zeigt die Exception an und läuft weiter.
Exceptions in der EXE des Programms werden auch unter Win 2019 Server angezeigt.
Nachdem an mehreren Stellen madExcept empfohlen wurde, habe ich das ins Projekt aufgenommen, für das Hauptprogramm und beide Laufzeitbibliotheken aktiviert, das funktioniert nett unter Win 10 und 11, aber unter 2019 Server schmiert es weiterhin kommentarlos ab.
Es hilft auch nicht, den kritischen Programmteil in try ... except einzupacken, unter win 2019 server sieht meine Anwendung die Exception nicht und wird abserviert.
Wie komme ich unter Win 2019 Server an die Exceptions im bpl heran?

[himitsu]

Na erstmal schon das Erstellen der Exception loggen lassen (Eurekalog und bestimmt auch madExcept sollten das können)
Normal wird sonst nur die "Anzeige" geloggt, also das Ende und nicht der Anfang der Exception.

[Jelen]

Ich denke, madExcept tut genau das normalerweise. Wenn ich mir den Bug Report von madExcept unter Win 11 ansehe, habe ich darin den Namen der procedure, in der die Exception auftrat, und auch die Zeile im Quellcode.
Doch leider kommt es dazu nicht unter Win 2019 Server.
Es sieht mir irgendwie so aus, als würde Win 2019 Server (im Gegensatz zu Win 10 und 11) das BPL nicht als Bestandteil meiner Anwendung betrachten.

[himitsu]

Gibt es Threads? (nicht der TThread aus der RTL)



Wenn eine Exception bis zum Windows durchrausch, dann raucht das Programm ab,
das WindowsErrorReporting übernimmt und erstellt im EreignisLog einen/zwei Einträge.


Ja, beim Auftreten der Exception wird erstmal alles Wichtige aufgenommen,
aber das Loggen geschieht meistens erst am Ende.

Es kann ja auch sein, dass über ein Try-Except das abgefangen wird (im Try-Except die Exception nicht neu auslöst),
oder durchgereicht (Re-Raise, ala raise; ), umgewandelt (neue Exception erstellt) oder fortgesetzt (RaiseOuterException) wird,
wobei Letzteres schön wäre, wenn das der Standard sei, auch wenn man eine neue Exception erstellt, bzw. ausversehn in eine Folgeexception läuft usw.

[harfes]

Zunächstmal ist ein WinSrv2019 ein Win10Pro V. 1809, d.h. es ist zwar eine "alte" Version von Win10 aber bis auf die Erweiterungen identisch. Was nicht identisch ist, ist der mitgelieferte Virenschutz (=Defender) - dieser schein beim Server umfangreicher zu sein als beim Win10. Daher habe ich diesen schon öfter mal killen müssen bzw. Ausnahmen hinzufügen müssen, damit dieser Programme nicht abschiesst (natürlich ohne weitere Meldung...). Vielleicht schaust Du da mal hin - ob's die Lösung für Dein Problem ist, kann ich natürlich nicht sagen, aber bei mir hat's häufig geholfen, wenn mein Programm unter Win10 läuft, aber nicht auf dem Server.

Hartmut

[Jelen]

Moin moin!
Danke für eure Tipps.

@himitsu: Keine Threads, es geht um Exceptions im Main Thread.

@harfes: Leider Negativ. Ausnahme hinzugefügt oder defender abgeschaltet löst das Problem nicht.

[Jelen]

Noch ein Nachtrag von mir zu dem Problem.
Es hängt tatsächlich an der BPL Laufzeitbibliothek. Wenn ich die Option "Mit Laufzeitbibliotheken linken" herausnehme, ist das Problem weg, ich erhalte die Exception angezeigt und auch den vollständigen Bug Report von madExcept auch unter Win 2019 Server.
Als Lösung sehe ich das aber nicht an, eine Exe von 70 MB ist nicht wirklich das, was ich mir vorgestellt habe ...

[Uwe Raabe]

Zitat von Jelen:

eine Exe von 70 MB ist nicht wirklich das, was ich mir vorgestellt habe ...

Wie groß sind denn die Exe und alle BPLs zusammen?

[Jelen]

Da wären 26 BPLs plus meine Exe, macht zusammen 77 MB, entspricht also der Größe der Exe ohne BPL-Verwendung.
Rund 50 MB davon entfallen auf die weitergebbaren Delphi-Bibliotheken wie RTL250 usw., die normalerweise nur einmal beim Kunden installiert werden müssen und bei späteren Updates ignoriert werden können. Das ist halt der Vorteil, den ich gerne mitnehmen würde.

[Uwe Raabe]

Zitat von Jelen:

Rund 50 MB davon entfallen auf die weitergebbaren Delphi-Bibliotheken wie RTL250 usw., die normalerweise nur einmal beim Kunden installiert werden müssen und bei späteren Updates ignoriert werden können. Das ist halt der Vorteil, den ich gerne mitnehmen würde.

Das entwickelt sich aber schnell zum Nachteil, wenn sich deine Delphi-Version ändert - und sei es nur mit einem Update-Release (z.B. 11.1 oder 11.3).

Eigentlich spielen Delphi-Packages ihren Vorteil erst dann aus wenn mehrere Exe sie nutzen oder man ein Plugin-System verwendet (klassisches Beispiel neben der IDE selbst ist FinalBuilder). Dafür ist das Deployment halt etwas aufwändiger.

Weniger häufig aber manchmal doch relevant, verhindern Packages die Verwendung speziell angepasster Versionen von Standard-Units.

Man muss halt immer abwägen. Die kleinere Exe beim Update wäre für mich jedenfalls kein Grund.