AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Exception in Laufzeitbibliothek einfangen unter Win 2019 server
Thema durchsuchen
Ansicht
Themen-Optionen

Exception in Laufzeitbibliothek einfangen unter Win 2019 server

Ein Thema von Jelen · begonnen am 27. Aug 2023 · letzter Beitrag vom 13. Sep 2023
Antwort Antwort
Kas Ob.

Registriert seit: 3. Sep 2023
451 Beiträge
 
#1

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 10:18
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
  Mit Zitat antworten Zitat
Kas Ob.

Registriert seit: 3. Sep 2023
451 Beiträge
 
#2

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 10:35
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.
Kas
  Mit Zitat antworten Zitat
Jelen

Registriert seit: 5. Nov 2003
45 Beiträge
 
#3

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 11:56
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!
  Mit Zitat antworten Zitat
Kas Ob.

Registriert seit: 3. Sep 2023
451 Beiträge
 
#4

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 13:42
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
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.731 Beiträge
 
Delphi 12 Athens
 
#5

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 12:29
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Kas Ob.

Registriert seit: 3. Sep 2023
451 Beiträge
 
#6

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 13:45
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
  Mit Zitat antworten Zitat
Kas Ob.

Registriert seit: 3. Sep 2023
451 Beiträge
 
#7

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 13:50
I am getting this, see the attachment when i post the other attachment

Hope they are readable.
Angehängte Grafiken
Dateityp: png 2023-09-05 15_46_08-Window.png (5,7 KB, 11x aufgerufen)
Dateityp: png 2023-09-05 15_46_49-Window.png (116,3 KB, 26x aufgerufen)
Kas
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.731 Beiträge
 
Delphi 12 Athens
 
#8

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 5. Sep 2023, 16:37
That looks like a similar post has been done before which may still wait for approval.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Jelen

Registriert seit: 5. Nov 2003
45 Beiträge
 
#9

AW: Exception in Laufzeitbibliothek einfangen unter Win 2019 server

  Alt 11. Sep 2023, 12:56
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.
  Mit Zitat antworten Zitat
Antwort Antwort

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:30 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz