Exception in Laufzeitbibliothek einfangen unter Win 2019 server

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

[Jelen]

Das ist richtig, ich hatte vergessen zu erwähnen, es gibt eine weitere Exe, die dieselben BPLs verwendet.
Außerdem ist mein Test-Server ein virtueller, auf den ich per RDP zugreife, der Upload läuft trotz guter Internetverbindung recht langsam. Um überhaupt dahinter zu kommen, was da passiert, habe ich vermutlich 50 Updates aufgespielt, weil bei fehlender Exception-Behandlung nur aus dem Absturzcode 0eedfade ja nicht wirklich viel abzuleiten ist. Wenn man dann fast im Minutentakt Updates hochlädt, freut man sich schon über jedes MB, was gespart werden kann.

[Delphi.Narium]

Such bitte mal mit der Suchmaschine Deiner Wahl nach "0x0eedfade-Exception". Es gibt da so etliches, was für Dich letztlich relevant ist, kann ich nicht sagern. Es scheint aber alles (mehr oder weniger) mit dem Debuggen zusammenzuhängen.

Eine eher mutige Schlussfolgerung meinerseits:

Auf dem Windows-2019-Server ist der Just-In-Time-Debugger aktiv. Der bekommt die Exception mit, kann damit nix anfangen und killt Dein Programm.

Auf Windows 10 und 11 ist der Just-In-Time-Debugger nicht aktiv, deshalb muss sich Dein Programm selbst um die Fehlerbehandlung kümmern, was halt eben funktioniert.

Warum diese "steile" These? Es könnte (eine ggfls. auch fehlerhafte) Schlussfolgerung aus diesem Thread sein: Create 0x0eedfade exception in test project

Wie der Just-In-Time-Debugger zu deaktivieren ist, kannst Du eventuell diesem Artikel Debuggen mit dem Just-In-Time-Debugger in Visual Studio entnehmen.

Keine Ahnung, vielleicht hilft es ja den Grund für die zwei unterschiedlichen Verhaltensweisen einzugrenzen.

[himitsu]

0x0eedfade ist einfach nur der generische Code für eine Delphi-Exception, im Exceptions-Record des Systems/Windows.

Was für ein Exception-Nachfahre es dann ist und welche Message sie hat, das kann Windows nicht wissen.
Es ist einfach nur irgendein Fehlercode, eines ihm unbekannten Programms und es weiß nicht wie es die Parameter des Records auswerten, sicht zum Exception-Objekt druchhangeln und daraus die Infos bekommen kann.





Konnte man nicht auch irgendwie den Delphi-Debugger im Windows registrieren?

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