Exception in Laufzeitbibliothek einfangen unter Win 2019 server

[Jelen]

Hallo,
seit einiger Zeit knabbere und google ich jetzt schon zu diesem Problem, ohne Erfolg :wall:, 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? :gruebel:

[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

Delphi-Quellcode:

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:

Zitat von Jelen (Beitrag 1526177)

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:

Zitat von Jelen (Beitrag 1526182)

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.

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

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

[Delphi.Narium]

Zitat:

Zitat von himitsu (Beitrag 1526192)

0x0eedfade ist einfach nur der 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.

Und deshalb killt der Just-In-Time-Debugger (vermutlich) das Programm.

[Jelen]

@Delphi.Narium:
An dem JIT-Debugging liegt es wohl auch nicht. Mein Win 2019 Server Testsystem ist neu aufgesetzt und hat außer meiner Anwendung und einer MySQL Datenbank noch nicht viel gesehen. Die Registry- und .config-Einträge für jitDebugging gibt es darauf nicht, deshalb gehe ich davon aus, dass so etwas nicht aktiv ist.
Ich bin weiter auf der Suche und für jede Anregung dankbar :idea: !

[Kas Ob.]

Zitat:

Zitat von Jelen (Beitrag 1526161)

Hallo,
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.

Why not to fix the exception in Windows 10 and 11 ? this will remove the Server 2019 exception for good.

Now to my 2 cents, 0x0eedfade is generic and almost useless in this case, the only advantage of having it, is the exception generated by Delphi code, this is great to follow.
There many reason for the application to disappear, but to my experience i can point the two most popular reasons for this:
1) The stack is corrupted beyond usage for the system or to be exact to the system debugger to unwind after a raised exception.
2) the stack is there but while unwinding the system debugger find it pointing to a critical section in memory like somewhere where it should not be pointing to, here the system will see this as malicious code and will terminate the application, it will refuse to unwind beyond that point, many malicious code use the stack to attack the system.

My suggestion to catch and solve this:
1) Make sure you building your application with Stack frames enabled in code generation, this will build better stack header to unwind.
2) Enable Range checking and Overflow checking, to help detecting buffers overflow on the stack.

both steps will help you find it, while (2) might be very annoying for you if you never build with them enabled and your code missing hundreds of these exception, but you really should fix them or at least handle them right, also check for warnings.

My diagnose for the cause of the stack corruption is that your application is either:
1) there is an un-initialized variable on the stack, while it is harder to cause such fuss with Delphi because it does use the heap, it you might have local record with missed to fill/initialize elements or assumed zero content, this might worked for Windows 10,11 but on Server 2019 the stack was already have different values, or you are using inline variables and they are overflowing.
2) There is a unreferenced pointer, aka miss use a pointer, you are writing to it, may be most the times small amount and it does work, but some times with big writes it does overflow and remove an SEH structure frmo the stack or the worse case it does fill it with carbage addresses.

Hope that helps and good luck.

[Kas Ob.]

Off-topic question:

I am new here and might be missing something, I posted to this thread "Wie Speicher ich den Schlüssel für verschlüsselte Datenbanken oder Dateien" two days ago, in fact tried few times and every time there was fast page redirection to with some text that my post should be approved by an administrator, tries also yesterday and it just doesn't go, now my post here above went from the first time.
Why this is happening?


ps: I am refraining from adding links because this is what i am suspecting the cause of such ban, but even when i tried to post without links, same message kept appearing.

[Jelen]

Hi Kas Ob,
welcome to Delphi-Praxis and thanks for your answer!
Regarding your off-topic question, I don't know, never had problems like that, maybe someone else might answer that.
Let me tell you a bit about my intension in that thread.
My App is still "under construction" and shurely, I intend to avoid exceptions. But, in this early phase of development you can't avoid them, since there's always still something wrong with the code.
I'm testing my App on Win 10, 11 and 2019 server. The server system is the one where the final App should be running, but my IDE is on Win 11.
The whole thing started with a simple error, the server system was set to region "US" and my development system is region "germany". This caused a StrToFloat call to throw an exception on converting a string like "1,5". Usually this is really easy to fix, but it turned into a skill issue since the App disappeared without any trace except the useless exit code. Without debugger on the server system it took me quite a long time to figure out what happened.
Once I got this fixed, I wondered why this simple error caused the whole App to crash that way. I build in a simple raise statement in one of my BPL and saw the same behavior: On Win 10 and 11 the exception was shown, on 2019 server the App crashed. Further on I tried to catch the exception, but try ... raise ... except worked fine on win 10 and 11, but on 2019 server the App still crashed. It looks to me like my code doesn't see the exception at all, it rushes straight to the system causing it to kill my App. This happens only with exceptions in the BPLs, exceptions in the exe are shown also on win 2019 server.
I experimented also with safecall (no effect) and using an installer for my App on the server to tell him which libraries belong to my App (also no effect).
Meanwhile, to continue with development (I'm running out of time), I'm linking the App without BPLs (70 MB exe).
By the way, all the research on this issue lead me to madExcept - that's really a great help for developers since the bug report for every uncaught exception gives you a complete call stack with procedure names and even line numbers of your source code. Unfortunately even madExcept doesn't see the exceptions in my BPLs on win 2019 server.
I will reflect your idea with the corrupted stack. Maybe there's something wrong with my BPLs and the server system is more sensitive for this special misbehavior. If I find something I will surely post it here.
But I really appreciate any further ideas for this!

[Uwe Raabe]

Zitat:

Zitat von Kas Ob. (Beitrag 1526482)

my post should be approved by an administrator

We have had some problems with spam recently, so new users are currently treated with suspicion. It's not something personal.

[Kas Ob.]

Zitat:

Zitat von Jelen (Beitrag 1526486)

By the way, all the research on this issue lead me to madExcept - that's really a great help for developers since the bug report for every uncaught exception gives you a complete call stack with procedure names and even line numbers of your source code. Unfortunately even madExcept doesn't see the exceptions in my BPLs on win 2019 server.

I use EurekaLog and not really familiar with madExcept, both i think should do the job fine, both tools are like old habit, hard to die or change.

Now to the hardcore part:
Among developers there is slight lack of knowledge on how exception works, how the OS handle this, how your code should behave, in this case the compiler does most of the job by installing the SEH in specific OS works, and you know what, most developer doesn't need that much deep understanding, a simple or simplified version will help a lot, i am not pretending to know-all-man, neither i will go in great detail here but will try to explain in very simple way how your application might be behaving.

there is few sorts of exception, hardware triggered or software intentionally triggered, the place where did they triggered also play a great role, like did the exception raised by hardware (like accessing protected page) in virtual mode or protected mode ?!
Protected mode where the kernel reside, virtual mode is where the user application and most of the OS reside.

in both cases the System behavior will be different, if accessed protected page triggering AV on hardware level, the kernel debugger in protected mode will intervene and take handle of it, it will decide how, what, and from where, if it is from virtual mode like you application it go a head and classify it, few examples, is it writing to a write protected page ?, is it reading from un allocated virtual address ?, is it accessing a protected page with specific address!!!!, in this case it might be accessing the last protection page in a stack, here OS will rename the exception to stack overflow !... and so on many many example and they are irrelevant for us now.

On side note: not every access to protected page will trigger user mode exception(like accessing the pages protecting the stack) the protected mode will check if there is another pages in the stack, if there is then it will adjust the stack with lower protected pages as page triggered the exception in first place will automatically changed to read/write and no exception will be raised, the protected mode will trigger the CPU to execute the last assembly instruction that trigger the hardware exception in first place and this will continue like nothing happen, meaning you application will not know it did tripped a hardware exception, and you only can get to know such thing did happen by watching the soft Page Fault.

Along this process in the protected mode the kernel debugger will check few context of this exception, and then will forward it to.. (long story).. until it reach the virtual mode and if there is a debugger then it will be triggered, if not then the OS in user mode still have a debugger, that will forward it to your application in case there is SEH trap,..
Here the except part in an application will receive the execution from the same thread that triggered the exception, but to find the according SEH, it will start with a process called stack unwinding, in very simplified words (half wrong) it will search(just go back) the stack for the last valid SEH, from there it will grab an address which in Delphi case will be pointing to the except part/clause in try..except..end

so after all of the above, what might be went wrong with that exception ?, can't be sure 100% but for me it sounds like the two options i wrote in the last post, the stack either corrupted and the system couldn't find a valid SEH, or through the unwinding process it find an address that marked as dangerous and decided to stop the process.

Windows have zero tolerance with many exception, like, try to start a background thread with CreateThread API and raise an exception without catching it!, the application should be gone.

My example about threads also might be a cause for your problem.


Hope that give you some insight to solve your problem.

[Kas Ob.]

Zitat:

Zitat von Uwe Raabe (Beitrag 1526489)

Zitat:

Zitat von Kas Ob. (Beitrag 1526482)

my post should be approved by an administrator

We have had some problems with spam recently, so new users are currently treated with suspicion. It's not something personal.

Personal never came my mind, but again my long post is stopped.

[Kas Ob.]

I am getting this, see the attachment when i post the other attachment

Hope they are readable.

[Uwe Raabe]

That looks like a similar post has been done before which may still wait for approval.

[Jelen]

Hello Kas Ob,
thanks for your tutorial regarding exception handling. By now I'm shure you're right, there's something wrong with my BPLs. I created an empty test project of the same structure (EXE and 2 BPLs). This is running fine and on win 2019 server it shows the correct exception handling, uncaught exceptions are shown as a message and the app continues, no crash. Even madExcept works fine within that.
I still wonder why I don't get the same error on win 10 and 11, but anyway, it's up to me to figure out what I did wrong within my crashing BPLs.

[Kas Ob.]

Zitat:

Zitat von Jelen (Beitrag 1526745)

I still wonder why I don't get the same error on win 10 and 11, but anyway

Are you sure that the EXE and BPL's compiled with Stack Frames ?

Also, I think it might shed some light if you capture and record or simply show the result of GetLastError in the error message.

[TUhr]

Mich würde mal interessieren ob die Software unter 2019 läuft, wenn Du die Datenausführungsverhinderung für dieses Programm deaktivierst.....

[Jelen]

Hallo TUhr,
was meinst du mit "Datenausführungsverhinderung"?
Das Programm an sich läuft ja weitgehend problemlos. Es ist aber noch in Entwicklung und problematisch für mich wird es erst, wenn auf dem Win 2019 Server System eine bislang nicht berücksichtigte Situation eintritt, die zu einer Exception in einer der BPLs führt. Dann ist das Programm einfach futsch und ich darf raten, was da passiert ist. Derzeit verzichte ich halt auf die Laufzeit-BPLs, um dieses Problem zu umgehen.
Immerhin ist ja inzwischen klar, dass es an irgendeinem strukturellen Problem in meinen BPLs liegt, denn bei einem leeren Testprojekt gab es ja auch keine Probleme.

[himitsu]

lmdmfdg Datenausfuehrungsverhinderung :wink:

https://support.microsoft.com/de-de/...8-512419135817
https://www.dell.com/support/kbdoc/d...rhinderung-dep

[Jelen]

Oups, dieses Unwort kam mir so komisch vor, dass ich nicht mal auf die Idee gekommen bin, danach zu googeln ... Asche auf mein Haupt :oops:.
Wenn ich DEP deaktiviere, hat das keinen Einfluss, dass Programm wird weiterhin bei Exceptions gekillt.
:idea: Aber: Wenn ich SEHOP deaktiviere (validate exception chains), dann ist das Problem weg. Das stützt die Vermutung von Kas Ob.
Ist aber letztlich auch keine Lösung, denn der Kunde wird wohl kaum die Sicherheitseinstellungen auf seinem Server reduzieren wollen.
Was ich mir nur nach wie vor nicht erklären kann, warum dasselbe Problem nicht auf meinen anderen Testsystemen (Win 10 und 11) auftritt, wo DEP und SEHOP aktiv sind, und unter Win 2019 Server wird meine App bei jeder Art von Exception in den BPLs gekillt.

[himitsu]

Projektoptionen > Erzeugen > DelphiCompiler > Compilieren
* Bereichsprüfung
* Überlaufprüfung
die Beiden sind seit Kurzem in neuen Delphiprojekten standardmäßig aktiv

Projektoptionen Erzeugen > DelphiCompiler > Linken
* ASLR (Address Space Layout Randomization)
* Datenausführungsverhinderung kompatibel
* Terminal-Server
"neue" Flags im PE-Header oder vielleicht teilweise auch Parameter im WindowsManifest, für Kompatibilitätsangaben deines Programmes.