RegisterWindowsMessage泄漏诊断

Question

我们看到在我们的一个应用程序的生产服务器上原子池资源耗尽。

使用奇妙的AtomTableMonitor工具，我们已经将这个问题隔离开来，通过RegisterWindowsMessage调用创建了大量的原子。他们都有这样的名字：

ControlOfs030D000000000270

最后的数字发生了变化。

我的问题是:我们如何弄清楚是哪个过程创造了这些原子？

一些潜在资源：

https://blogs.msdn.microsoft.com/ntdebugging/2012/01/31/identifying-global-atom-table-leaks/

Answer 1

从"ControlOfs..."开始的原子是由Delphi/C++Builder中Borland/Embarcadero的VCL ()框架创建的。这些原子实际上以"ControlOfs<HInstance><ThreadID>"的形式存在，其中<HInstance>和<ThreadID>是十六进制格式(所以，在您的例子中，HInstance = 0x030D0000 = 51183616，ThreadID = 0x00000270 = 624)。

VCL还以"Delphi<ProcessID>"的形式创建了另一个原子名，其中<ProcessID>是十六进制格式。

这意味着使用VCL的应用程序的每个实例都会创建一个新的唯一"Delphi..."原子，其主UI线程将创建一个新的惟一"ControlOfs..."原子(这些原子用于通过SetProp()将TWinControl对象指针存储在VCL创建的HWND中，供VCL的FindControl()和IsDelphiHandle()实用函数使用)。这两个原子都在应用程序启动时注册到GlobalAddAtom()，在应用程序关闭时使用GlobalDeleteAtom()未注册，因此没有泄漏。

然而，在Delphi/C++Builder 6中，一直到RADStudio XE2，还有一个原子使用相同的"ControlOfs..."名称。这个原子是用RegisterWindowMessage()创建的(对于私有的RM_GetObjectInstance窗口消息)，不能取消注册。因此，每次运行受影响的VCL应用程序时，都会创建这个唯一的原子，并随后泄漏。

2012年，Embarcadero在RADStudio XE3中修复了这一问题(安德烈亚斯·豪斯拉丹发布了早期版本的补丁 )。但是，使用较早版本的VCL编译的现有应用程序会受到影响，如果不在RegisterWindowMessage()中使用静态名称，就无法阻止它们的泄漏。

因此，要回答您的问题，使用AtomTableMonitor和任务管理器的组合，您应该能够确定您正在运行的应用程序是VCL应用程序，然后您可以单独检查它们是否泄漏原子。或者，使用SysInternals过程监视器与Thread Create筛选器一起获取线程ID及其创建进程的列表，然后您可以将这些线程ID与泄漏的原子名称匹配。

Answer 2

您可以使用像API监视器这样的工具，并将其设置为只跟踪RegisterWindowsMessage。它将向您展示哪个进程正在使用此函数，以及堆栈跟踪(虽然没有符号可能不太有用)。

另外，在谷歌上快速搜索ControlOfs，可以找到与你的问题相匹配的https://forums.embarcadero.com/thread.jspa?threadID=47678。他们说这是VCL的一个窃听器。如果您有以下代码，就会有人发布此修复包：

http://andy.jgknet.de/blog/bugfix-units/vclfixpack-10/

如果您没有代码，我建议您在生产服务器中查找Delphi/VCL应用程序，并尝试更新它们或报告问题。