We recently became aware of a leak in trmw32.dll, which if an executable is left run long enough can cause DP4 programs to fail with a GPF. The problem can only be observed on Windows 2000 and XP machines, though it may well occur on older versions of Windows as well. However the API needed to monitor the leak does not exist on older versions, so there is no way of knowing if the problem does exist.
The problem is caused by a bug in a Windows API, DeferWindowPos(), which trmw32.dll uses when it needs to rearrange the Z-Order of maps on the screen. For reasons that are unclear, this API can sometimes fail with erorr code 87 (invalid parameter), even though a call to SetWindowPos() with the same parameters succeeds. When this happens the handle passed to DeferWindowPos() is lost, and a resource leak occurs. The documentation of the API on MSDN clearly implies that this leak should not occur, but it does. In order to fix the leak, code has been added to trmw32.dll to call the API EndDeferWindowPos() with a saved copy of the lost handle, when DeferWindowPos() fails with this error code. MSDN documenatation states that applications should not do this, but doing so fixes the leak and does not appear to have any adverse consequences.
It is conceivable that this fix might not be needed on a future version of Windows, or that the fix might become ineffective, or even counter-productive. Therefore there is a new DP4.INI setting which can be used to control the behaviour of trmw32.dll in this area. Please see the documentation of defer_bug for details.