Kas Ob.

Yes not for everyone, yet the decentralization and distribution of the signature log might help or at least increase the chance of avoiding catastrophic failure or again at least faster response, in case of compromise did happen, some might look and see logs with different colors of the names and/or the time of multi signature happened at 3AM then you go why and what Andres had signed binaries, could his station being hijacked !, lets notify him or the responsible person. Anyway, food for thought, and this what i did and my clients loved it !

Then i would expand on this and suggest to make like what i did, on every sing issued the result on both GUI and console client side, it does grab last few signing operation and disclose them to every one is singing, as the best security is transparency and awareness, this means any singing developer can have a glance of what have being signed last 5-10 singing procedures, with time, dates, authorization and the binary name. Just food for thoughts. And thank you very much !

@Vincent Parrett Feature suggestion even before seeing this great tool As i already did 3 projects for 3 different clients, although it wasn't for USB or hardware tokens, but for usual certificate and its private key, the project was to keep the private key securely stored away from developers machines, yet monitor what executables were signed and by whom, stored IPs and devs authentication in detailed nice logs, also the administrator could allow only the digest to be shipped to the server but also allow the administrator to choose who can not sign without uploading the whole binary to be stored on the server for .. security and trust reasons. My suggestion is to expand or at least consider the forced operation logging on server side, this is not something belongs to best practice and i am sure it will be requested sooner or later.

Name suggestion if you interested : "DSign" or "DSigning" from Distributed .. ihm... i meant Delphi . The latter yield zero search result on both DDG and Google.

Yes they have reasons, and this 100% doesn't include solving your mentioned problem, these APIs are about locking/reserving physical memory, to one end and one reason, minimizing page faults for one critical application, hence recover or reserve performance as much as possible, and by performance i mean the just to prevent losing performance due to high memory usage and paging to file, and that is it. I can't imagine how this can help your application not crashing, but i can few scenarios where it delay the crash enough that you don't notice, this does not fix the problem, and there is bug(s) somewhere, it might be 1) Your bug very similar to the @dummzeuch mentioned, it is coming from casting pointer to signed integer then perform some operations on that integer, like shuffling it to other variables, or do some arithmetic operation with it, back in days 32bit application had 2GB and there wasn't a problem, i mean there wasn't crashing or access violations (because the problem is there waiting), then comes the boot switch /3GB that allowed/added one extra GB to the memory rendering all the abusing of the pointer as access violation, but this didn't happen or noticed right away as it will happen arbitrary, and only when your application utilized so much memory, in newer Windows version, the OS started to make this allocation addresses more arbitrary, hence these bugs started to show even if your application didn't utilize a lot of memory, anyways, these access violation and miss use of pointers, could be easily found and fixed by use the FastMM4 with MEM_TOP_DOWN, which i remember is default, hence will fixed right away, without you might depend on luck and high memory usage to capture. 2) Your application in fact using high volume of memory but it does abuse threading and miss using timing, if you have one Sleep because you are assuming an operation will take 5ms and you gave it something like 500ms, that should be fine, right ? NO ! , you are wrongly assuming this can be enough, because when when paging hit, the operation will block, by operation i mean a single CPU instruction will trigger OS VMM intervention due to hard page fault, and this thread will block until VMM free some physical memory, not really free (!!) but stop another thread/process and then write its memory from the physical to the page file, then load you paged memory, then continue your thread, by continue i mean literally re-execute that single instruction, the one stopped the earth planet form rotation. These bugs coming from miss using timing where very frequent back in days with HDD, with SSD it is faster and wrong logic might pass unchallenged, yet with heavy software running on OS like Windows Defender that literally capable to utilize the disk operation at tens of thousands operations per second when it does scan, these bugs come to light again. So i hope that was readable and clear, and of course i hope helps identifying your bugs, but one thing is for sure denying physical memory by manipulating working set, is not good sign at all, let your application be free of bugs and let it take small extra time due paging, and let the OS perform as intended.

The listed errors are linker ones, which means there is a confliction in the compiled source units, to understand these errors you have to get in the shoes of the compiler and linker, the compiler check for the source file time for last modification and build the .o/.obj (same goes for the .dcu in Delphi), (well dates and times among other parameters but most relevant is the time) if these times are identical then will skip compiling !!, assuming it is the same and nothing changed then nothing to recompile, linker on other hand will build the executable binary from scratch and from its own build version, here comes the unresolved externals... in case the .o/.obj files were built/compiled with different compiler form different IDE. Delphi doesn't suffer form this because DCU files has the compiler version included (again among others, like all the compiling switches are there in the DCU) , while .o/.obj files can't be used effectively as dcu files. So it is either bug in the compiler where it should check for the compiler version (and project switches) before skip compiling, Or you have to clean your paths from all artefacts (.o , .obj...) to be able to build on different compiler, I can't say for sure about this being compiler bug or not.

At +5 pixel, most likely you are resizing the form from the corner, try to increase this, or pick a point where no resizing might happen, +10 do it , like this SimulateMouseDrag(left+10, top+10, left+200, top+200);

Should be {$SETPEFLAGS IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP or IMAGE_FILE_LARGE_ADDRESS_AWARE} You missed an "or" !

What happen if Windows Service called "Theme" is stopped and disabled ? Will the flicking continue to exist with RDP ?

I wouldn't expect much on/from this, for many years i am not fan of what Embarcadero focusing their effort and resources, but about this particular one, i don't think they can do much. Take an example CFG, it is still new and not fully matured by Microsoft itself, while the real deal (the devil most needed) in its parts is RFG, this one in particular is not standardized and i really don't expect they will have any specification any time soon if ever ! Without written specification, no compiler and linker can perform/produce compliant code, a code that OS require to to perform undocumented behavior while still changing on the OS part, so ... Embarcadero can't help or do much for now, yet there is parts can be implemented, here i am talking about parts to be comply with the known and documented part of the CFG. The request for RFG is outrageous and out of the reality as you mentioned it, even Rust with LLVM can't do it. I expect that audit is more like the more the merrier in a (longer) list of checkboxes without thinking them enough, and it is their right to do so after all, they should everything they can think of, the red line is were to make it a deal breaker. On this i agree, this is Embarcadero lack or lag in this space, they neglected this part for very long time, i mentioned 2 DLLs out of punch i came across and you have one, i had in few projects to remove the import for these two DLLs to raise a project rank in VirusTotal, signed or not signed was it. But for Embarcadero to do something about this they need put effort and ask for what should be removed or adjusted, the community can report them, of course some public awareness is critical here, so an initiative should be take a place, started by Embarcadero. I am out of touch with the new IDEs, and really don't know if the mentioned above DLLs still relevant now, but many here aware about this now and can help, as for FireMonkey and cross platforms.

Other than checking the Edition, i would do compile an empty unit and check for the artefact or the output, though i never installed or used CE, so might be wrong about this approach, but the fact it is not exiting with ExitCode=1 is disturbing non the less D:\Program Files (x86)\Embarcadero\Studio\16.0\bin>dcc32 EmptyUnit.pas Embarcadero Delphi for Win32 compiler version 29.0 Copyright (c) 1983,2015 Embarcadero Technologies, Inc. EmptyUnit.pas(8) 9 lines, 0.02 seconds, 15 bytes code, 4 bytes data. unit EmptyUnit; interface implementation end.

May be the approach is very similar between CnWizard Editor Enhancement and newer IDEs, adjusting the gutter after seeing the need to, combine this with very busy system at this moment to cause some delay in update. Anyways, i was just pointing that this behavior or visual effect is/was there with older IDEs.

I witness this in both Delphi 2010 and XE8 almost always, this visible more in XE8 and when the Editor open a big file for the first time, it adjust the gutter on them all, if the editor has a file with more than 10k line it will be most noticeable. BUT, 100% sure this artefact from CnPack/CnWizard in my case.

If you have capital Latin letters then just subtract 64. In case of small Latin letters then subtract 96. https://en.wikipedia.org/wiki/ASCII

I have no idea why this DLL is imported, but searching landed me here https://learn.microsoft.com/en-us/windows/win32/api/avrt/ And those belongs to https://learn.microsoft.com/en-us/windows/win32/procthread/multimedia-class-scheduler-service Nothing more about this, except some little rant about how Delphi RTL and VCL using and importing stuff just because the original designer didn't think it through, useless stuff, like every single Delphi application is importing winspool.drv for no reason at all except the idea that every application should use the printer !! and historically the Printer Drivers were the most abused for security vulnerabilities, hence just adding more stuff to irritate any AV about Delphi applications, also there is this one "winsta.dll" which as i recall were used as backup in case the application can't figure the OS version, so there is a static import for this DLL and it is not call, this DLL is the library responsible for many terminal and servers (stations) connection and licenses managing, communicating... etc , this one is red flag for any application in the eyes of any Security software (AV)... enough of that. I think you can't do any of these in Delphi except this one "Authenticode", which has nothing to do with the compiler or linker, this is not even a flag, this is the Digital Signature as defined by Microsoft, so all you have to pass this, is to sign you binaries with Code Signing Certificate issued by trusted Certificate Authority that leads to trusted root in the OS store (certificate store). The rest names decryption : cfg = Code Flow Guard , Delphi compiler can't produce compatible code for this, in fact i don't any other compiler than VS will do it, as the whole CFG is not yet matured, and really should depend on specific hardware, namely CPU features, this is new standard. to read more about this https://www.intel.com/content/dam/develop/external/us/en/documents/catc17-introduction-intel-cet-844137.pdf forceIntegrity = https://learn.microsoft.com/en-us/cpp/build/reference/integritycheck-require-signature-check?view=msvc-170 well this one is complete useless and will not add any security what so ever, easy to enable though as it is a simple bit in the PE header gs = well this one is tricky as it might be Gs or GS https://learn.microsoft.com/en-us/cpp/build/reference/gs-buffer-security-check?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=msvc-170 One does need special stack protection explained by stack cookies while the other ensure free buffer zone in the stack, both Delphi can't do ! rfg = Return Flow Guard very similar to CFG, also to my knowledge this one is part of CFG, and it is useless to make it out of CFG, and there is no specification yet on how to be implemented except in theory and as VS do it ! https://security.stackexchange.com/questions/206560/methods-of-exploiting-a-windows-executable-protected-by-control-flow-guard-and I hope that explained the whole thing a little for you, also the one who compiled the report for you, adding these together may be didn't understand them fully or what do they means or how they works, it could be one of these great software that do understand security and how it should be implemented (/sarcasm/), in all cases CFG and GS are impossible with Delphi compiler and linker, although GS protection is possible by using EurekaLog, but it will kill the performance of you application, yet they can not see the flag where the OS will do its part, so the protection against the stack/buffer overflow will be there but no one will witness, audit report should be based on actual source and deep understand what it does, yet it might be regulatory thing these days. as for CFG and its RFG, if it is that much needed then you need to redo you application in VS (namely Visual Studio) nothing else. Good luck and hope that was clear.

This made laugh and angry at the same time, along with audit in the same post. Anyways, don't have time, to write a lot, but later will post about this and give you some rest. Meanwhile, convert and build your application to Visual Studio from a company called Microsoft to pass these flags, which are not named as they should.

This warning/error is here forever, i suggest to do yourself a favor and rewrite the above with future proof parameters.

No issue there, just simple error.

Well see ROT13, Caesar and their family, these doesn't need key but easy to add one in case you want to, by shifting (adding) by the key, these it might fit your need Start here https://stackoverflow.com/questions/6800326/how-to-crypt-or-hide-a-string-in-delphi-exe A nice playground for Cesar https://www.dcode.fr/caesar-cipher And in general https://www.dcode.fr/en Also https://www.dcode.fr/vigenere-cipher looks nice and does have a key https://en.wikipedia.org/wiki/Vigenère_cipher Yet from quick look at it, i think it might fit your need more than Cesar or ROT13, might be wrong though, In all cases i hope this will give you at least start point for your search, and of course i believe many here will give you insight too.

These two do make things very hard and even impossible to put in an algorithm, i mean going form wider range (arbitrary strings with special characters) of data to narrower output range (only Latin and digits) and while keeping length. You have to drop one of them or accept some degree of length increase ! I can't think of an alternative approach or existing algorithm, unless the length of your strings are long enough (must be big and long, or may be with repeated words and parts) to add compression layer that decrease the input strings to a sufficient length to do the presentation with Latin and digits.

1) How many loop are there in the code in that DLL ? and many iteration being executed ? and compare that to the reported leaks numbers ? 2) Empty loops does produce leaks ? this means broken logic in TThreadPool, yet doesn't mean it is buggy yet, it could be MM, at least try FastMM4 for both EXE and DLL, make sure you are using the same MM. 3) Not bad idea to use the manually induced leaks, this will consolidate the numbers, like i explained above, you should make sure of consistency of the report, if you have more than one loop. 4) in my opinion, TThreadPoolMonitor is the one behind all these leaks, this easily can happen if it is was locked and corrupted or overwritten, that is your target and the direct cause in this bug hunt, it is reported as leak in your log, and as you pointed to. Yet unless someone can confirm and reproduce it, i am inclined to assume your project environment (setup) is responsible for it. Unfortunately, that is good news, and means replicating or reproducing a smaller and stripped project (the smallest new project) to reproduce this bug is feasible, so please try ! Just one thought, lets imagine one thread belongs to TThreadPool was stuck/frozen/looping, how one thread being would affect the pool exiting and cleaning after the threads, does its position affect the pool behavior, like if it was the first, last or in the middle... I don't have an answer for this, so i suggest to dump pall the threads on exit, also don't know how madshi, but i know eurekalog can do this and triggered by hand or by option and manually induced an exception, in any case try to dump all the threads and their stacks to see if there is a thread is still do something or simply unhinged somewhere. The best way to do this is to introduce any unit to the project that has finalization and here you will trigger the threads dump (to get all threads stacks), make sure this unit is the highest place in the dpr uses clause, right after MM, and of course right after the exception tool you will use.

@Eric Grange How about hooking TDX11Context.DoSetShaders ? Wait a second !, TDX11Context is private and non accessible, at least on my XE8, that is bad design to hide a critical and OS dependent class, was the designer so confident it is bug free and it does include everything could be needed from DirectX11 even in the future. From the name DX11, there will be DX12 and even DX13, and they will break compatibility in huge way, so a private one is like, NO update your IDE framework and wait for our updated design...

Where is Byte[7] ?!! Anyway, try this for fair comparison function NewGuidV7: TGUID; var LUnixMSec: Int64; LUnixMSecBytes: array[0..7] of Byte absolute LUnixMSec; LBytes: array[0..15] of Byte; I: Integer; begin for I := 0 to 15 do LBytes[I] := Random($FF); LUnixMSec := DateTimeToMilliseconds(TTimeZone.Local.ToUniversalTime(Now)) - Int64(UnixDateDelta + DateDelta) * MSecsPerDay; LBytes[0] := LUnixMSecBytes[5]; LBytes[1] := LUnixMSecBytes[4]; LBytes[2] := LUnixMSecBytes[3]; LBytes[3] := LUnixMSecBytes[2]; LBytes[4] := LUnixMSecBytes[1]; LBytes[5] := LUnixMSecBytes[0]; {LBytes[0] := (LUnixMSec shr 40) and $FF; LBytes[1] := (LUnixMSec shr 32) and $FF; LBytes[2] := (LUnixMSec shr 24) and $FF; LBytes[3] := (LUnixMSec shr 16) and $FF; LBytes[4] := (LUnixMSec shr 8) and $FF; LBytes[5] := LUnixMSec and $FF;} LBytes[6] := (LBytes[6] and $0F) or $70; LBytes[8] := (LBytes[8] and $3F) or $80; Result := TGuid.Create(LBytes, 0, True); end; Fix LByte[7] as should, because in my sample it is missing too ! In case you did a benchmark then please share the result with us, (i didn't)

@terran i see you updated you post with a log Yes that log does shows memory leaks, and you didn't do what i asked for and suggested, but yet more information is needed to pin point the problem, i do understand you can't share codes, But as curtesy and respect for our time as yours, read what people write you and if you don't understand their reasons and logic, then you can ask, you might learn something or two. So here what i see with the little provided: I put your log in Notepad++ and searched for all the occurrences of "The allocation number is", the result is Line 28: The allocation number is: 3155 Line 60: The allocation number is: 504725 Line 92: The allocation number is: 504689 Line 124: The allocation number is: 504673 Line 156: The allocation number is: 504650 Line 188: The allocation number is: 504623 Line 220: The allocation number is: 504604 Line 252: The allocation number is: 502198 Line 284: The allocation number is: 486818 Line 316: The allocation number is: 486791 Line 348: The allocation number is: 486093 Line 380: The allocation number is: 504750 Line 412: The allocation number is: 504747 Line 444: The allocation number is: 504733 Line 476: The allocation number is: 504727 Line 508: The allocation number is: 504694 Line 540: The allocation number is: 504690 Line 572: The allocation number is: 504678 Line 604: The allocation number is: 504674 Line 636: The allocation number is: 504656 Line 668: The allocation number is: 504652 Line 700: The allocation number is: 504630 Line 732: The allocation number is: 504625 Line 764: The allocation number is: 504608 Line 796: The allocation number is: 504605 Line 828: The allocation number is: 502202 Line 860: The allocation number is: 502199 Line 892: The allocation number is: 486839 Line 924: The allocation number is: 486795 Line 956: The allocation number is: 486792 Line 988: The allocation number is: 486099 Line 1020: The allocation number is: 486094 Line 1052: The allocation number is: 486819 Line 1084: The allocation number is: 484903 Line 1116: The allocation number is: 484900 Line 1148: The allocation number is: 2221 Line 1180: The allocation number is: 2293 Line 1212: The allocation number is: 2127 Line 1244: The allocation number is: 2087 Line 1276: The allocation number is: 2047 Line 1308: The allocation number is: 504746 Line 1340: The allocation number is: 2018 Line 1372: The allocation number is: 1971 Line 1404: The allocation number is: 3168 Line 1436: The allocation number is: 1944 Line 1468: The allocation number is: 1896 Line 1500: The allocation number is: 1873 Line 1532: The allocation number is: 1860 Line 1564: The allocation number is: 1888 Line 1596: The allocation number is: 1850 Line 1628: The allocation number is: 484899 Line 1660: The allocation number is: 1902 Line 1694: The allocation number is: 504748 Line 1728: The allocation number is: 504729 Line 1762: The allocation number is: 504691 Line 1796: The allocation number is: 504675 Line 1830: The allocation number is: 504653 Line 1864: The allocation number is: 504627 Line 1898: The allocation number is: 504606 Line 1932: The allocation number is: 502200 Line 1966: The allocation number is: 486829 Line 2000: The allocation number is: 486793 Line 2034: The allocation number is: 486096 Line 2068: The allocation number is: 3170 Line 2102: The allocation number is: 484901 Line 2136: The allocation number is: 3157 Line 2170: The allocation number is: 2295 Line 2204: The allocation number is: 2223 Line 2238: The allocation number is: 2131 Line 2272: The allocation number is: 2020 Line 2306: The allocation number is: 2090 Line 2340: The allocation number is: 1946 Line 2374: The allocation number is: 1974 Line 2408: The allocation number is: 1899 Line 2442: The allocation number is: 2049 Line 2476: The allocation number is: 1875 Line 2510: The allocation number is: 1890 Line 2544: The allocation number is: 1862 Line 2578: The allocation number is: 1853 Line 2612: The allocation number is: 1989 Line 2654: The allocation number is: 3169 Line 2686: The allocation number is: 2297 Line 2718: The allocation number is: 2225 Line 2750: The allocation number is: 2294 Line 2782: The allocation number is: 2136 Line 2814: The allocation number is: 2222 Line 2846: The allocation number is: 2092 Line 2878: The allocation number is: 2129 Line 2910: The allocation number is: 2051 Line 2942: The allocation number is: 2088 Line 2974: The allocation number is: 3173 Line 3006: The allocation number is: 2022 Line 3038: The allocation number is: 2019 Line 3070: The allocation number is: 1976 Line 3102: The allocation number is: 2048 Line 3134: The allocation number is: 3159 Line 3166: The allocation number is: 1948 Line 3198: The allocation number is: 1972 Line 3230: The allocation number is: 3156 Line 3262: The allocation number is: 1901 Line 3294: The allocation number is: 1945 Line 3326: The allocation number is: 1892 Line 3358: The allocation number is: 1897 Line 3390: The allocation number is: 1877 Line 3422: The allocation number is: 1889 Line 3454: The allocation number is: 1864 Line 3486: The allocation number is: 1874 Line 3518: The allocation number is: 1855 Line 3550: The allocation number is: 1851 Line 3582: The allocation number is: 1861 Line 3614: The allocation number is: 504739 Line 3650: The allocation number is: 504703 Line 3686: The allocation number is: 504687 Line 3722: The allocation number is: 504661 Line 3758: The allocation number is: 504635 Line 3794: The allocation number is: 502167 Line 3830: The allocation number is: 486073 Line 3866: The allocation number is: 486801 Line 3902: The allocation number is: 486575 Line 3938: The allocation number is: 504614 Line 3974: The allocation number is: 3164 Line 4010: The allocation number is: 2174 Line 4046: The allocation number is: 3113 Line 4082: The allocation number is: 2065 Line 4118: The allocation number is: 2107 Line 4154: The allocation number is: 2236 Line 4190: The allocation number is: 1997 Line 4226: The allocation number is: 2031 Line 4262: The allocation number is: 1960 Line 4298: The allocation number is: 1934 Line 4334: The allocation number is: 1893 Line 4365: The allocation number is: 1978 Line 4401: The allocation number is: 1865 Line 4437: The allocation number is: 1878 Line 4473: The allocation number is: 1857 Line 4509: The allocation number is: 1848 Line 4545: The allocation number is: 484882 Line 4581: The allocation number is: 504587 Line 4617: The allocation number is: 504749 Line 4657: The allocation number is: 504731 Line 4697: The allocation number is: 504692 Line 4737: The allocation number is: 504676 Line 4777: The allocation number is: 504655 Line 4817: The allocation number is: 504629 Line 4857: The allocation number is: 504607 Line 4897: The allocation number is: 502201 Line 4937: The allocation number is: 486836 Line 4977: The allocation number is: 486794 Line 5017: The allocation number is: 484902 Line 5057: The allocation number is: 486098 Line 5097: The allocation number is: 3171 Line 5137: The allocation number is: 3158 Line 5177: The allocation number is: 2296 Line 5217: The allocation number is: 2224 Line 5257: The allocation number is: 2133 Line 5297: The allocation number is: 2091 Line 5337: The allocation number is: 2050 Line 5377: The allocation number is: 2021 Line 5417: The allocation number is: 1975 Line 5457: The allocation number is: 1947 Line 5497: The allocation number is: 1900 Line 5537: The allocation number is: 1891 Line 5577: The allocation number is: 1876 Line 5617: The allocation number is: 1863 Line 5657: The allocation number is: 1854 This shows two group of leaks, one group happen very early, while the other was very late, both group are condensed, meaning they do happen on specific event. I followed what i think is the first (the oldest reported leak) with number 1848, and here is it --------------------------------2024-09-02 17:00:36-------------------------------- A memory block has been leaked. The size is: 68 This block was allocated by thread 0xA44, and the stack trace (return addresses) at the time was: 0542E4D2 [fastmm5.pas][FastMM5][FastMM_DebugGetMem$qqri][7820] 054170D2 [System.pas][System][@GetMem$qqri][4962] 05418F9B [System.pas][System][TObject.NewInstance][18331] 0541969E [System.pas][System][@ClassCreate$qqrpvzc][19661] 05517233 [System.Threading.pas][System.Threading][Threading.TThreadPool.TQueueWorkerThread.Create][3479] 0541970C [System.pas][System][@AfterConstruction$qqrxp14System.TObject][19710] 05516998 [System.Threading.pas][System.Threading][Threading.TThreadPool.CreateWorkerThread][3223] 05516B19 [System.Threading.pas][System.Threading][Threading.TThreadPool.GrowWorkerPool][3269] 05516E1F [System.Threading.pas][System.Threading][Threading.TThreadPool.QueueWorkItem][3357] 05513D9B [System.Threading.pas][System.Threading][Threading.TTask.QueueEvents][2715] 055145C1 [System.Threading.pas][System.Threading][Threading.TParallel.TReplicableTask.QueueEvents][2972] 0551419B [System.Threading.pas][System.Threading][Threading.TTask.Start][2779] 05510F1A [System.Threading.pas][System.Threading][Threading.TParallel.ForWorker][1483] 056D8CF2 [ImageCompare.dpr][ImageCompare][ResizeCanvas$qqrp33Imagingcanvases.TFastARGB32Canvasp30Imagingcanvases.TImagingCanvasiiii][1069] 05653BA6 [ImagingCanvases.pas][ImagingCanvases][TImagingCanvas.ResetClipRect][954] 056CA19D [Imaging.pas][Imaging][GetImageFormatInfo$qqr25Imagingtypes.TImageFormatr29Imagingtypes.TImageFormatInfo][2812] 05653B76 [ImagingCanvases.pas][ImagingCanvases][TImagingCanvas.UpdateCanvasState][949] 056C432E [Imaging.pas][Imaging][TestImage$qqrrx23Imagingtypes.TImageData][921] 056D97E9 [ImageCompare.dpr][ImageCompare][TProcessFile.GetdHash$qqrr22Imagecompare.TLastInfox20System.UnicodeStringiii][1200] 77911B2C [Unknown function at RtlpNtEnumerateSubKey] The block is currently used for an object of class: System.Threading.TThreadPool.TQueueWorkerThread The allocation number is: 1848 Current memory dump of 76 bytes starting at pointer address 72AE3A0: AC 3C 50 05 A4 9E 00 00 CC 03 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 FB 2C 07 40 4F 21 07 40 EB 22 07 64 FB 2C 07 68 FB 2C 07 00 CB 27 07 00 00 00 00 D4 2F 2C 8D D2 E4 42 05 . < P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . @ O ! . @ . " . d . , . h . , . . . ' . . . . . . / , . . . B . Now this proof you are wrong about none of your code is involved ! All start in your ImageCompare.dpr, so more information is needed here, Is that ImageCompare.dpr belongs to a DLL or an EXE ? Another thing, is there any thing prohibited you from do what i suggested about deliberately invoked leaks ? Again and for the last time, put TMyObjectX before such loops you pasted above, replace X with a number (1,2,3..) so they can be named and recognized in the log, and put this simple line in the loop "TMyObject.Create;" no variable, no thing, this is enough to cause a leak to report. Depending on the number of reported leaks for these TMyObject1, TMyObject2.... you and we can see a little more, because in your first post there was very interesting numbers 27 and 54, yet the loop is 11 ! This must be addressed also, to get the bigger picture or at least identify a method to catch and categorize the problem, is it a Compiler/RTL bug or some mishandling code. Another thing, Why ImageCompare.dpr does show in the log to begin with ? in case it is a DLL then you must not initialize long process or an even more dangerous process like multithreading, when the thread is Loaded/Attcached, like such process that depend on and identify the calling thread as main one, the calling thread here (in case with DLL) is an OS one that will be created and will be destroyed by the OS, and this will confuse your code with the Process Main Thread, causing all sort of problem. And good luck !

I don't have an answer, just one to do about thing this Add a fake (not used) TMyObject to your code, create it inside that loop you are doubting, then don't free it ! See if the report is consistent and reliable, with 11 leaked TMyObject. This might save time.