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.

[Kas Ob.]

Zitat von Jelen:

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!

[Kas Ob.]

Zitat von Jelen:

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.