Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.

ID: 28963, A hack fix for RegisterWindowMessage Atom leak...

by Ray Vecchio Email: Anonymous

When launching Delphi applications multiple times these applications will leak atoms due the usage of RegisterWindowMessage (RWM) in Control.pas (or VCL.Controls.pas) NOTE: This *only* happens when the Controls unit is linked in. This can cause applications to fail with messages like "not being able to create a window" or "not enough storage to complete an operation" etc.
Download Details
FTP  download also available
CDN Login Required to Download. (You will be redirected to the login page if you click on the Download Link)
To download this, you must have registered:
A free membership

For Delphi, Version 7.0  to 16.0 358 downloads
Copyright: Open Source or other

Terms of use: Embarcadero use at your own risk disclaimer

Size: 7,477 bytes
Updated on Fri, 07 Sep 2012 09:11:37 GMT
Originally uploaded on Tue, 14 Aug 2012 02:26:30 GMT
SHA1 Hash: 40A4B133E4B7013A8C03F8F22ABD6819DE01C24D
MD5 Hash: ED0E3C461924121AA0B2C85832F403D8

    Explore the files in this upload

The reason for the problem...
1) the GlobalAtom table is actually a part of a bigger table that is used internally by the operating system, to store window classes, atoms, clipboard format AND more importantly RegisterWindowMessage (RWM) registered messages. Now unlike GlobalAtoms there is no corresponding Delete API to remove RWM messages, (my guess is as this global it is probably due to security/vulnerbility purposes).
2) You will have noted that GlobalAtoms are indeed correctly clean up, in the VCL code, but as you can see we CANNOT clean up the ONE RWM message we allocate. (this is done in (VCL.)Controls.pas InitControls)
3) Now the issue is, in Windows versions prior to Win2k8/Vista/Win7, this was far less of a problem because the process memory was not randomised... so the "ControlAtomString" always had the same value for the same application and the RWM value was reused by the OS, AND the OS did strictly enforce a limit on these atoms.
4) The reason what the RWM was used in the VCL was specifically for drag/drop and docking support when a Windowed control was allocated in a statically linked DLL (ie one that does not use packages) because it allowed the VCL to NOT pass back a pointer to a control allocated in EXE to the DLL and viceversa.

What is included in the zip file:
1) the source to an application that will show the allocated atoms called Atomiser, the last column is important when you start any Delphi VCL application up and shut is down you will see the RWM atoms increasing. When you click on one of the items in the last two list boxes the caption will show which running application allocated the atom or RWM, if the caption is blank it means the application has terminated, but it can give report incorrect applications as the OS will reuse PIDs.

2) There is a file called "RWMFixUnit.pas" that contains the hack, it replaces the call to RWM in the Controls unit and uses the GlobalAtom value (that will get cleaned up) instead of the leaky RWM. You HAVE to add this unit before the Controls (otherwise it will complain!) and it will only work in statically linked applications. I have simplified the implementation, so it will just reuse the global atom for the "ControlOfs" leak, all other RWM allocation will proceed as normal.

3) I have added a service version of atomiser that you can install as a service and will dump put a logfile every 10 seconds. This will show any leaks in the Windows Session used to run services.

<new> The new version of the atomiser will now run on XP, and I have added a new fix unit that will fix both statically linked binaries and ones that use packages.

So add either "RWMFixUnit.pas" OR "RWMFullFixUnit.pas" to your projects and make sure it is placed before then Forms or Controls unit in a project.

   Latest Comments  View All Add New

Move mouse over comment to see the full text

Could not retrieve comments. Please try again later.

Server Response from: ETNACDC04