Kas Ob.

I need to explain the difference between user mode part of the kernel and the real OS kernel, the hidden and protected one, lets take a simple OS API like GetTickCount, put it in Delphi code, stop the debugger on it and use step into, continue until return to Delphi code, the debugger will be able to walk it all, but if you take one of the sensitive OS API let say any of the file handling (or threads...) and tried to trace with step into using the Delphi debugger or any debugger then you will end up with such assembly instruction SYSCALL oe SYSENTER https://www.felixcloutier.com/x86/syscall https://www.felixcloutier.com/x86/sysenter These are the gates for protected mode, what happens on the other side nothing on our (user) side can see or know and predict. Now back to the exception raising and handling (trapping), all exception handlers are chained but will will not cross that protected mode, so no matter where the exception raised it will follow that chain, BUT will not cross that barrier. So if an exception been raised in user mode part of the kernel or in you application or any auxiliary library (DLL) those can be caught or at least can be inspected or hooked (override the SEH traps) by software like EurekaLog, but if the exception being raised in the protected mode then nothing will handle it from here and the only way to handle, inspect or trap it is by software running on that side, like kernel debugger or OS kernel its own exception handling code. Some API does indeed raise an exception on its own, by code (aka software) or hardware exception (eg within a driver), here come how it did implemented to do it or after it, either by mitigating the exception silently (eg. access violation to unallocated memory) then will eat that exception and return to the user mode with simple error code as API return value (saying something like the buffer invalid), but in user mode here no one will know, in other words neither code (exception handling) or debugger will be triggered, or in some very specific situation the exception is that rare, that Microsoft didn't take the time or the effort to mitigate it or it is indeed have some risk factor (security), and let it run through the kernel exception handler (OS layer debugger) calling the WER (which indeed also a debugger), this one can't be handled and will lead to terminating the process and no control will be brought back to user mode, i mean none, all the threads will be terminated after WER paused them and will not be allowed to exist after that, if WER is invoked, it could be risk factor and even WER will be called. Back to EurekaLog, it does good job with hooking on system level, but again all this will only apply to user mode part of the kernel, beyond that no software (in user mode) will help, but what will help is to read WER report and get sense out of it, it should have a call stack. It is definitely external, but we can't be sure where, if in user mode part of the kernel then EurekaLog should/might capture it, but if it is in protected mode then no. One thing for sure it is as per documentation STATUS_HEAP_CORRUPTION , which is merely something simple like use after free or an overflow in heap or something similar....., But again that an OS API tried to do read/write on what it did classify as corrupted heap, and OS didn't allocate that part but your software did (including OpenSSL library), and it is the one responsible for this wrong memory/pointer fed to the API, OR in a THOERY the API were fed a right pointer/memory/heap .... but another thread wrongfully accessed it and modified something or even freed it !, that what should be checked against. PS : if you supplied a blocking read with a buffer to fill (file or socket ...whatever) and while it is blocking on that operation you did free that buffer, what do you think should be raised as an exception ? yes it will be STATUS_HEAP_CORRUPTION, this might not be easy to reproduce with Delphi MM (FastMM) but will be very easy with VirtualAlloc/VirtualFree, with FastMM there will be no error because freeing memory is rarely a free and return to the system. Hope that was readable and helpful.

Then i will just suggest putting recovery handling code, and leave it there, if or unless the crash is due to security measure form the OS then you might have a chance to retrieve these disk unflushed logs files. like RegisterApplicationRecoveryCallback from https://learn.microsoft.com/en-us/windows/win32/api/_recovery/ It worth trying.

I have few things about the subject 1) The exception is raised in the OS kernel protected part, not the user part, hence the the failure for the application (or MadExcept..) to get hand on the exception. 2) When you say it doesn't happen with YuOpenSSL build, this bring to elephant in the room, YuOpenSSL build will be using/utilizing Delphi application memory manager instead of the System heap and memory manager, and there is a big difference, while FastMM is build for speed and other feature, it is very forgiving in the matter of out-bound write/access, because small or medium allocations are continuous and there is no check for overflow write or even as simple reading after freeing. 3) No sure what MadExcept does offer, but sure that EurekaLog have extended functionality to perform deep hooking and capture and report every handled exception 4) Also EurekaLog can helpful in performing some fuzzing to enhance the chance of capturing the read after free usage I think you can capture and eliminate this exception or at least get better understanding of its context, by going after YuOpenSSL build not the OpenSSL Dlls, focusing on that build in my opinion has the best chance to solve this once and for all, even when there is no exception being raised or any symptoms or memory miss usage.

Refer to the documentation https://docs.devart.com/mydac/modify_data.htm

I did the same thing with in few servers, and as Remy and Angus said it should handled on lower level from the event layer, here a snippet i have in a project if (BytesRecv > 0) then begin if (FInSSLBuffer[0] = $16){ and (FInSSLBuffer[1] = $03)} then begin FConnecitonIsTLS := True; TLSInit; // end else begin // Move(FInSSLBuffer[0], FInBuffer[FInBufferCount], FInSSLBufferCount); BytesToProcess := FInSSLBufferCount; FInSSLBufferCount := 0; end; end; Though i am not experienced in ICS, i would suggest to derive (inherit) your own server and make you detection, before triggering the event thus you will have your dual usage server, and drop in place, On side note, i needed this for some reasons: 1) To remove huge amount of logging from online scripts and bots that keeps requesting plain HTTP on port 443, and i replied with and empty HTTP, when it is was HTTP. 2) I needed to add SSH and HTTP (as above), but i didn't want to go with multiple ports, so used 443 for SSH too, the same way it detected few bytes, as above it seems i used only one byte for SSL/TLS. An argument for the need to have such functionality: I needed to switch off SSL/TLS traffic and leave the plain traffic in extreme debugging/testing and watching unstable networks (WiFi) traffic on WireShark, also needed to stress the socket engine itself not the Secure layer and its CPU demanding, so for such case the ICS server could have a Boolean property to disable SSL/TLS, with default as False, and when it is True the traffic will skip all Secure layer handling, such feature will have its consequences and can be be not allowed to disable after enabling, but it is the responsibility of the developer (ICS user) to understand how and when to flip this property. Not big or needed feature, but a feature non the less.

I am sorry and deleting this distasteful joke, really sorry.

Tried to be funny for god sake, i don't remember seeing such smile !

distasteful joke

May be ! The workaround is very simple, give him money, like 1 dollar will do and say the magic words, that he the compilation as business transaction, still there is a tiny problem here with using actual money and he need to declare it, so buy him pizza and make sure he did eat it in front of you, pizza can't be taxed, like all consumed food in it had been consumed, for you in this case the pizza is non monetary compensation can't be taxed as money transaction.

Exactly the point, I remember reading or accessing a page where the ELC server needed a file that should be generated and locked to an IP or a DNS or something, i really can't remember, but in that case or any case involving ELC server license with Internet parameter then the logical for Delphi IDE to some save parameters/data locally to access that server and in case of failure for extended period of time, it should check with home for valid ELC server registration or a revocation, this makes sense to be implemented in ELC server too. Revocation needed because the license/ELC server could be moved to another/different server (with different IP/DNS...) may be !? Anyway, I don't know, and as Uwe i would love to hear from who tested it with firewall on ELC server or have already knows, or may someone form Embarcadero can shed some light on this.

One more question about this though : By not having internet for Delphi IDE or the server and for long time like few weeks or months, will it still running or fail to allow the IDE to run. Because there is some shady stuff the IDE does after 12 months, the old ones that i have (at least), and i prefer not to discuss this in this forum, but concerned about that ELC, considering it is done by the same team.

Does this server call home ? Is there any documental confirmation that this server will not make outgoing connections ?

Hmmmmm, (scratching head emoji) (scratching head emoji) (scratching head emoji) (scratching head emoji) So Embarcadero might drink from the same cup, the one handed us for years ?!!! Noice !

Happy for you and happy more for the experience you got out of this issue !

NOOOOOO ! Don't go there . Just perform clean QR removal and follow its instruction to the letter to install, if QR package project file had been changed or modified then you have to either : repeat the same process you have done above, i mean removing the needed ...., or just restore the orginal QR package projects. In other words if you didn't change the QR source then delete it completely and try with clean library code. Very popular mistake that cause errors like this. is that the IDE have made some changes or you did or even there was a conflict in the runtime/design time packages when you installed a packages (QR in this case) and the IDE asked you to save the project and you clicked yes, make this conflict hidden.

Dear, your problem is not with your package itself, yes designide may be should added by manually, but the QR package build is broken and is the cause of this issue, i don't think w64 should appear anywhere near design time packages. I suggest to completely remove (uninstall) the QR package and rebuild/install it from scratch, make sure to delete all the bpl and dcp for QR. Also if you look at the installed and loaded packages in the IDE ( IDE Menu -> Component -> Install Packages... ) you should have this window Again i don't have QR, but the same goes for all packages. If a packages is installed then it have an entry in this window. If the package is loaded then the checkbox is checked, unchecked means it is install but not loaded. So when cleaning QR make sure also all (or any) entries referring to QR are gone.

You should change them ! See if you are using the DesignEditors then your package should be Design time only and most likely will fail to build if it using the QuickReport if not in the require section as needed, as Lajos wrote, only the IDE will find it for you, as it should be already loaded for your package to loaded by the IDE then installed.

Now you are on the path to find the real problem. Try to solve the conflict in Those depends on your package and its imported units.

There is no such files, these should have RTL numbers, i suggest to try the project manager, right click on all the required packages then remove them all, after that the IDE on building will ask you to add the needed ones, this for me solves such conflict in many cases/incidents in the project file, specially after upgrading/downgrading between IDE's. These will stay without numbers in the projects but will be adjusted later and internally without your interaction.

This is a little tricky indeed, most likely your JEP is using (referencing) a unit that is included in different package, JEP is expecting another (un-named here) run time package to be loaded first. Find/identify the missing or referenced unit file and handle it, or change JEP Build control from project option, does Explicit or rebuild as needed selected ?!, start there .

Great example ! and i want to expand on this a little System.SysUtils; type IFoo = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] function GetFooName: string; end; IBar = interface ['{5DEC09C5-FADC-46A5-814F-9ED91259A37F}'] procedure Dummy; function GetBarName: string; end; TFooBar = class(TInterfacedObject, IFoo, IBar) function GetFooName: string; function GetBarName: string; procedure Dummy; end; function TFooBar.GetFooName: string; begin Result := 'Foo'; end; procedure TFooBar.Dummy; begin Writeln('Dummy called !'); // this is procedure without result ! // yet it might don't raise an exception here because the result in a register could be 0 or valid value end; function TFooBar.GetBarName: string; begin Result := 'Bar'; end; var i: IInterface; begin i := TFooBar.Create; Writeln((i as IFoo).GetFooName); Writeln((i as IBar).GetBarName); Readln; end. The result Dummy called ! Bar

Dalija , may be you are low on coffee but for sure i am ! Thread.Free is a blocking call and will not return until the Thread.Execute is finished and exited, so if an event is still holding the thread execution then fEvent.Free will not be reached until it is set/triggered, hence the the need to either trigger the event in the destructor by destroying/freeing it or trigger it explicitly before the inherited destructor then freeing it.

I agree on that, but about the part of plenty of code, well, that part is relative for example, the thread in question above should have TerminatedSet called in the destructor before the inherited Destroy this will make sure the thread is not blocking on an event that might not be triggered or will take long time to trigger, this is equal or the same as freeing the event (before the the inherited) and forget about it.

Undefined behavior ?!!

Well, yes, but waiting on event that will not be triggered because the thread is trying to call the inherited destructor, for me is undefined behavior, will if finish or will it not and when ? Because the event is not triggered nor freed, TThread.Free in my opinion should never ever called, all and every TThread by design should clean up after themselves, well that is my humble opinion, the whole point of leaving a class/creature meant to run only once such as thread which can effecting the whole process, should be considered as falling knife, draw the path/loop or what ever then let it run its course cleaning and exiting gracefully.