Exception in Laufzeitbibliothek einfangen unter Win 2019 server

[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.

[himitsu]

70 MB für eine Single-EXE ist jetzt noch nicht soooooo groß.
Es ist lange her, als ich für einen Bugfix mit einem alten WinXP mal unser Projekt versuchte ohne Packages/DLLs zu kompilieren.

4-14 MB die EXEn
685 MB inkl. allen eigenen BPL/DLL
256 MB fremd-DLL/BPL + 115 MB Debuginfos (ohne DevExpress)
42 MB die Delphi-Packages
...

macht insgesamt, inkl. DevExpress
1,58 GB + 900 MB an DebugInfos (Delphi 11)



Eigentlich sollte es mit BPLs weniger Problemengeben,
aber bei DLLs, gibt es nerviges Verhalten, leider im einfachen TestCode nicht nachvollziehbar.

Irgendwo versteckt sich in System/SysUtils/... eine Funktion, welche beim Verlassen einer DLL-Funktion die Delphi-Exception in eine Systemexception zurückkonvertiert (vor allem EExternal ala EAccessViolation, EDivByZero usw)
Leider fand ich ihn nicht wieder.

Ist prinzipiell dafür gedacht, wenn eine Exception aus einer Delphi-DLL z.B. in ein C++-Programm durchrauscht.


Grundsätzlich würde dann auf der anderen Seite, wenn es wieder in ein Try-Except läuft, daraus wieder eine neue Delphi-Exception.

Drum ist auch ein Code ala

Delphi-Quellcode:

try
  ...
except
  on E: Exception do begin
    E.Message := E.Message + ' irgendwas';
    raise
  end;
end;

keine gute Idee, weil hier der geänderte Text wieder verschwinden würde, wenn sowas passiert.



Mit hart verlinkten Packages über einen WebShare .... boar, dank eines Bugs im Windows/Samba, haben wir grade wieder einen Kunden, wo es pro BPL 1-3 Sekunden zum Laden dauert und bei 355 BPLs macht das dann ............... bis der SplashScreen nacht knapp der Hälfte aufgeht.
Und wer bei Mikrosoft auf die schwachsinnige Idee kam, die PE-Flags für Caching von DLLs aus Netzlaufwerken/Wechseldatenträgern für JEDE einzelne DLL, anstatt einmal aus der EXE zu nehmen ..... (bei Fremd-DLL/BPL das Flag/Bit zu ändern ... bähhhhhhhh)