Kas Ob.

I did made small package that capture all the output from the IDE at real time compiling/building, it does capture all messages in Output tab and Build tab, but it was tested on few and old IDEs, it works on XE8, Seattle( can't remember which number it was as i don't use it) , Delphi 2010, 2007 and 2009 . If that is needed and can help you then i need a confirm before revisiting it, also it will need your help to make sure it will work on newer IDEs, so do you need it ?

Thinking more and running more twisted tests on the IDE, the thing is the suggestion to delay the question might be not simple and require a lot of modification, so .. If you can access Application.Handle and pass it as owner handle then it should solve this for good, for both M B_APPLMODAL and MB_TASKMODAL, this put all background threads in order and act as the Application should act. And by "can access" i am assuming that message is coming form a DLL and not from the package (PBL), but in both cases i am sure you can find a solution.

But thinking more, i think the whole loading setting and blocking for user input, might be a problem, what about dropping the loading of setting in this case and delay the question until the IDE fully loaded, then ask the user his input then ask to fully IDE restart, this should happen rarely but will remove any similar and problematic behavior for good.

None as it might cause worse behavior, i am sorry i don't recall testing all the cases with such combination, BUT.. I think MB_APPLMODAL instead of MB_TASKMODAL might the solution with no owner handle, in case that failed then keep using MB_APPLMODAL and use any, like any handle you can access at that stage, on one condition though the handle must be a Delphi form handle.

I have a theory on how this might why this happen, which doesn't involve invisible windows. That MessageBox message doesn't have an owner window handle meaning Applicaiton.ProcessMessages might easily cause this halt of messages processing for this very message box as it will prefer the splash screen, all you need is Modal form and MessageBox with MB_TASKMODAL to enforce the conflict while there is no owner, and of course spray a little of back ground thread calling and might be trying to synchronize with the main thread, and if there is Applicaiton.ProcessMessages somewhere from background thread then messages will not be answered.

Such question and its answer is a reason why a sub forum (specified place) is needed.

Well i tried AI in many cases and wasn't happy with time wasted when the topic about Pascal/Delphi, yet i use Grok with X (Twitter) extensively, it does fantastic job explaining politics and history, In my opinion and for now one sub forum should be sufficient, to prevent a discussion about the place of a topic, the whole idea might yield valuable information and insightful ideas about a technology that is here to stay, should i use it and waste money or not, i voted yes.

Yes i was hasty to not consider the generic way to load, nice!

Nice ! Not seeing reader or i am missing something ? With reader from JSON, this library will become a must-have tool simplifying JSON debug handling, YAML is human reading friendly, so can be used where JSON usually used also replacing INI and config files.

RealThinClient has very powerful TRtcInfo, it is simply put magnificent, capable of many things, but few things in particular are most powerful, namely the ability to read from XML, XML-RPC, JSON and its own binary compacted format also the ability write to any. https://github.com/teppicom/RealThinClient-SDK/blob/develop/src/Lib/rtcInfo.pas#L4073-L4146 YAML is beauty, and having the ability to convert to/from JSON would be fantastic feature, so this might be feature suggestion.

I am not a fan of interfaces, but they have their shining moment, this is one of them, if you introduced C and only used by interfaces then compiler, versioning and implementation should not matter, it will work always. Just take your time to implement it future proof as much as you can think of, don't overengineer it, just keep it simple with multiple interfaces instead of one if possible, also use versioned (numbered) interfaces (in the name) to indicate to yourself and as reminder that these interfaces should not be touched/altered, if in the future need a feature then implement new interface and keep the older.

This is easier i think, But Let the child process check the command line in case of named pipes being passed then child will CreateFile with OPEN_EXISTING then use SetStdHandle to switch, and you are good to go, parent will create them with CreateNamedPipe. In that case parent can switch between standard and named, named can be fixed while you are debugging, parent can be debugged and another debugger will spawn the child on its own with fixed names, This will work, i used this many times, but and unless there is so many other parameters/commandline then it will revert to cumbersome to adjust the child command by hand, yet again these parameter could be temporarily (in debugging mode) to be used form/within a file created by Parent and signaled by specific command to child to process... I think you got the idea, the performance drop between named and standard is negligible.

Well looking at the log again, i see it differently, and it is madexcept fault, the first log is nice main thread ($24b0): 7a26999b madExcept32.dll madExceptDbg 1773 GetMemCallback 006973f0 Posserver.exe System 4966 @GetMem 0069c5fa Posserver.exe System 26079 @NewUnicodeString 0069c83b Posserver.exe System 26693 @UStrFromPWCharLen 0069d93e Posserver.exe System 32005 @UStrCopy 00ec5dc6 Posserver.exe DEFSa 2399 LOADTRANSLATIONS 00ec5e59 Posserver.exe DEFSa 2408 LOADTRANSLATIONS 00ec5e98 Posserver.exe DEFSa 2413 LOADTRANSLATIONS 00eaa910 Posserver.exe Unitmain 678 TMain.FormCreate 00eaacff Posserver.exe Unitmain 740 TMain.FormCreate 009134d5 Posserver.exe Vcl.Forms 5534 TCustomForm.DoCreate 00912ff4 Posserver.exe Vcl.Forms 5401 TCustomForm.AfterConstruction 0069ae25 Posserver.exe System 19736 @AfterConstruction 00912fb0 Posserver.exe Vcl.Forms 5391 TCustomForm.Create 00920a12 Posserver.exe Vcl.Forms 13527 TApplication.CreateForm 00ee3510 Posserver.exe Posserver 132 initialization 7649fcc7 KERNEL32.DLL BaseThreadInitThunk It end with GetMem as it should, but include GetMemCallBack which is the hook for madexcept, and i am not familiar with madexcept, but i think the reasonable action is to strip the hook. In any case the log is nice, Later it lose control, as all these stack traces should be ended with either GetMem or ReallocMem, and be deleted form record later when FreeMem being called on the same address, Yet in the middle of that log, we see it start to count two or three GetMem before stopping, in the end of the log file ( the most later entries) it looks like it hit hard point to continue and stop This one from the middle 7a26999b madExcept32.dll madExceptDbg 1773 GetMemCallback 006973f0 Posserver.exe System 4966 @GetMem <----------- 0069c5fa Posserver.exe System 26079 @NewUnicodeString 0069c83b Posserver.exe System 26693 @UStrFromPWCharLen 0069c912 Posserver.exe System 26870 InternalUStrFromPCharLen 006973f0 Posserver.exe System 4966 @GetMem <----------- 0069c5fa Posserver.exe System 26079 @NewUnicodeString 0069d6af Posserver.exe System 31391 @UStrSetLength 006f2771 Posserver.exe System.SysUtils 8486 _IntToStr32 006f2aa8 Posserver.exe System.SysUtils 8601 IntToStr 006f52f8 Posserver.exe System.SysUtils 13425 WideFormatBuf 006f584b Posserver.exe System.SysUtils 13565 WideFormatBuf 006a3437 Posserver.exe System 41854 LocaleCharsFromUnicode 006983f7 Posserver.exe System 11904 TextOut 0069c5fa Posserver.exe System 26079 @NewUnicodeString 00ea26a4 Posserver.exe http 3486 TTCPHttpThrd.ProcessHttpRequest 006f49a0 Posserver.exe System.SysUtils 12905 FormatBuf 006f4981 Posserver.exe System.SysUtils 12898 FormatBuf 006f6f9f Posserver.exe System.SysUtils 20007 AppendNumber 006f6f41 Posserver.exe System.SysUtils 19991 AppendChars 006f7b98 Posserver.exe System.SysUtils 20444 AppendFormat 006f7c31 Posserver.exe System.SysUtils 20449 DateTimeToString 006f7d67 Posserver.exe System.SysUtils 20460 DateTimeToString 006973f0 Posserver.exe System 4966 @GetMem <----------- 00e94450 Posserver.exe http 1155 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 006f6943 Posserver.exe System.SysUtils 19661 TryEncodeTime 006f697e Posserver.exe System.SysUtils 19668 EncodeTime 006f6e1b Posserver.exe System.SysUtils 19871 Now 006f7dd3 Posserver.exe System.SysUtils 20518 FormatDateTime 00e945b0 Posserver.exe http 1174 TTCPHttpThrd.ProcessHttpRequest 00e945ef Posserver.exe http 1174 TTCPHttpThrd.ProcessHttpRequest 00ea26a4 Posserver.exe http 3486 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 00e80a16 Posserver.exe http 673 TTCPHttpThrd.Execute 007506bb Posserver.exe madExcept HookedTThreadExecute 00750726 Posserver.exe madExcept HookedTThreadExecute 007dd4d9 Posserver.exe System.Classes 16396 ThreadProc 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 0075067c Posserver.exe madExcept ThreadExceptFrame 007506bb Posserver.exe madExcept HookedTThreadExecute 00750726 Posserver.exe madExcept HookedTThreadExecute 006973f0 Posserver.exe System 4966 @GetMem <----------- 0069c5fa Posserver.exe System 26079 @NewUnicodeString 0069d6af Posserver.exe System 31391 @UStrSetLength 00701456 Posserver.exe System.SysUtils 30732 TStringHelper.Create 006f7d18 Posserver.exe System.SysUtils 20459 DateTimeToString 006f7d67 Posserver.exe System.SysUtils 20460 DateTimeToString 006973f0 Posserver.exe System 4966 @GetMem <----------- shoudl stopped here 00e94450 Posserver.exe http 1155 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 00eac77b Posserver.exe misc 262 html2sg 00e98c33 Posserver.exe http 1981 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 007506bb Posserver.exe madExcept HookedTThreadExecute 007dd4d9 Posserver.exe System.Classes 16396 ThreadProc 0069c548 Posserver.exe System 25850 ThreadWrapper 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 7649fcc7 KERNEL32.DLL BaseThreadInitThunk Now that make sense at least from me.

Not exactly confused as much it is catching the temporary string, see the common thing between these worrying lines is the temp string, Copy will generate temp string, like the concatenation with "+", to confirm this extract these into their own declared string var then put that var in-place to see if the report change. That is little problem, the problem i am afraid of is the unreadable and none sense stack trace, take as example TryEncodeTime i mentioned earlier, it is low level and has should not raise exception, also it is end point, meaning it should never ever seen at a stack unless it raised an exception or in this very case and because we (madexcept) are tracking memory allocation, it should be ended with the real memory allocation, that is not what reported, as madexcept call trace shows it passed ProcessHttpRequest, this makes no sense, pointing that the call trace (stack) is wrong and not trust worthy, madexcept failed to build clean stack trace. There is also a temp string introduced by compiler every time you use or pass different string type, like concatenation a Ansistring with different string type, so it could be "thisip" is declared an Ansi on newer Delphi while pos will force the compiler to do the temp conversion.. Also TryEncodeTime is allocating temp string to pass it as result (out to be exact and not result), so it really could like the first lines i wrote the cause is failure to handle tempstring that compiler is generating behind the scene. Anyway, these all may be false positive as you asked, but the shuffled stack makes me afraid from sinister behavior coming form madexcept, is this is missed up and broken then what else ?! Didn't mention what Delphi you are using and if madexcept is up to date, and i really think it is miss configuration in madexcept or a bug, but has little to do with Delphi, unless you are using Delphi version that is not supported by your madexcept.

Hi, They doesn't look like that, looks innocent. What is really strange and make no sense at all is the log you attached, take an example this one thread $34f0 (TTCPHttpThrd): 7a26999b madExcept32.dll madExceptDbg 1773 GetMemCallback 006973f0 Posserver.exe System 4966 @GetMem 0069c5fa Posserver.exe System 26079 @NewUnicodeString 0069c83b Posserver.exe System 26693 @UStrFromPWCharLen 0069c912 Posserver.exe System 26870 InternalUStrFromPCharLen 006973f0 Posserver.exe System 4966 @GetMem 0069c5fa Posserver.exe System 26079 @NewUnicodeString 0069d6af Posserver.exe System 31391 @UStrSetLength 006f2771 Posserver.exe System.SysUtils 8486 _IntToStr32 006f2aa8 Posserver.exe System.SysUtils 8601 IntToStr 006f52f8 Posserver.exe System.SysUtils 13425 WideFormatBuf 006f584b Posserver.exe System.SysUtils 13565 WideFormatBuf 006a3437 Posserver.exe System 41854 LocaleCharsFromUnicode 006983f7 Posserver.exe System 11904 TextOut 0069c5fa Posserver.exe System 26079 @NewUnicodeString 00ea26a4 Posserver.exe http 3486 TTCPHttpThrd.ProcessHttpRequest 006f49a0 Posserver.exe System.SysUtils 12905 FormatBuf 006f4981 Posserver.exe System.SysUtils 12898 FormatBuf 006f6f9f Posserver.exe System.SysUtils 20007 AppendNumber 006f6f41 Posserver.exe System.SysUtils 19991 AppendChars 006f7b98 Posserver.exe System.SysUtils 20444 AppendFormat 006f7c31 Posserver.exe System.SysUtils 20449 DateTimeToString 006f7d67 Posserver.exe System.SysUtils 20460 DateTimeToString 006973f0 Posserver.exe System 4966 @GetMem 00e94450 Posserver.exe http 1155 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 006f6943 Posserver.exe System.SysUtils 19661 TryEncodeTime <------ 006f697e Posserver.exe System.SysUtils 19668 EncodeTime 006f6e1b Posserver.exe System.SysUtils 19871 Now 006f7dd3 Posserver.exe System.SysUtils 20518 FormatDateTime 00e945b0 Posserver.exe http 1174 TTCPHttpThrd.ProcessHttpRequest 00e945ef Posserver.exe http 1174 TTCPHttpThrd.ProcessHttpRequest 00ea26a4 Posserver.exe http 3486 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 00e80a16 Posserver.exe http 673 TTCPHttpThrd.Execute 007506bb Posserver.exe madExcept HookedTThreadExecute 00750726 Posserver.exe madExcept HookedTThreadExecute 007dd4d9 Posserver.exe System.Classes 16396 ThreadProc 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 0075067c Posserver.exe madExcept ThreadExceptFrame 007506bb Posserver.exe madExcept HookedTThreadExecute 00750726 Posserver.exe madExcept HookedTThreadExecute 006973f0 Posserver.exe System 4966 @GetMem 0069c5fa Posserver.exe System 26079 @NewUnicodeString 0069d6af Posserver.exe System 31391 @UStrSetLength 00701456 Posserver.exe System.SysUtils 30732 TStringHelper.Create 006f7d18 Posserver.exe System.SysUtils 20459 DateTimeToString 006f7d67 Posserver.exe System.SysUtils 20460 DateTimeToString 006973f0 Posserver.exe System 4966 @GetMem 00e94450 Posserver.exe http 1155 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 00eac77b Posserver.exe misc 262 html2sg <------ 00e98c33 Posserver.exe http 1981 TTCPHttpThrd.ProcessHttpRequest 00e805f0 Posserver.exe http 622 TTCPHttpThrd.Execute 007506bb Posserver.exe madExcept HookedTThreadExecute 007dd4d9 Posserver.exe System.Classes 16396 ThreadProc 0069c548 Posserver.exe System 25850 ThreadWrapper 007505a1 Posserver.exe madExcept CallThreadProcSafe 00750606 Posserver.exe madExcept ThreadExceptFrame 7649fcc7 KERNEL32.DLL BaseThreadInitThunk What do we see ? TTCPHttpThrd.ProcessHttpRequest behave like recursive !! but no it is not recursive, yet walking the call stack is illogical, html2sg does raise an exception ? or it doesn't ?, the exception most likely is handled inside try..except..end clause, yet two calls after that come from madexcept then the stack point to TTCPHttpThrd.Execute, that is unexplainable Also TryEncodeTime is raising an exception !? or not ? No need to answer the above, as the log might be wrong. I am not expert with madexcept, but i want to point that you might be miss configured it and caused this reports, so if you asked it to capture handled exception then it might be the cause, but i am not sure. As suggestion, start with the simplest thing which is make sure to pass strings as const in these two function ProcessHttpRequest(const Request, uri, protocol, params: string; var keepalive: boolean; var nosettype, linkclose: boolean): integer; procedure debug(const s: string); VAR I: integer; begin if (debughook <> 0) OR inparams('Z', I) then begin writeln(F1, s); flush(F1); end; In case your code failed to compile then just add local strings and load the content form the parameters, this easily could be the solution for the above unexplained madexcept log. Suggestion : Fix the declaration to const and try to change/tweak madexcept behavior then capture a new log then share, in case the problem persist. and Good luck!