Absent Member.
Absent Member.

Suspected memory leak in AD remote loader


I'm running an AD remote loader on Windows Server 2012 R2. Recently
we've started seeing an issue where the system memory used by "Identity
Manager Remote Loader Executable" gradually climbs over a period of 1-2
weeks until it's using over 2GB of RAM. A reboot clears the issue, and
the process starts over.

The only TID I found that refers to a remote loader memory leak is TID
#7016414, but it says it's fixed by upgrading to IDM 4.5.0. We are
currently running remote loader executable version, while the AD
driver DLL is version

Has anyone else seen this? Should installing the new driver shim
(ADDRIVER resolve it?


Labels (1)
5 Replies
Knowledge Partner
Knowledge Partner

I do not know that it will fix it, bu the 4.0.2 shim is pretty old
(time-wise), so I would definitely try being on current code before you do
too much else. The Remote Loader (RL) itself usually does not do much
with memory, other than with its tracing window, but the shim within does
the real processing and is therefore more likely to leak memory.

There have also been leaks over time with password filters, though very
rarely. If you upgrade the Remote Loader, the MAD shim may not be
updated. Even if you update the MAD shim, the password filters will not
necessarily be upgraded, so be sure you do all of that, pushing out
filters to all relevant domain controllers (DC) so that they do not end up
with memory issues. I doubt that is your issue (you would not see it as
Remote Loader memory buildup since the filters do not run as part of the
RL) but you had might as well patch everything, hen duplicate and report
the issue if possible.

MAD download, which I think is current:


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Honored Contributor.
Honored Contributor.

I am seeing this issue on a Windows 2016 server running:

dirxml_remote.exe  version dated 20190917

ADDriver.DLL version dated 20200430

The server is a VM with 8GB of RAM and 8 processors

Memory utilization is around 2MB at startup, but starts to rise from there and often peaks at over 1GB within a few days. This is a vast improvement over its behavior when it was running IDM 4.6.4 and ADDriver (when RAM usage by dirxml_remote.exe frequently topped out at 3.5GB)  but it still doesn't seem ideal, and I suspect it is sometimes causing sync delays. 

1. What would be 'normal' memory usage for this driver?

2. Assuming >1GB is excessive memory usage, what information should I gather to find out why this is happening? 






Tags (3)
Honored Contributor.
Honored Contributor.


I've monitored the remote loader server closely for the past few days, and while I've seen dirxml_remote.exe's RAM usage go as high as 1GB, it has dropped off since then. Currently it's only 59MB, the lowest I've ever seen. Maybe it's too soon to say for sure, but  it looks like upgrading the remote loader and AD driver helped and the high RAM usage immediately after said upgrade was just a fluke.  Fingers crossed!



Honored Contributor.
Honored Contributor.

Turns out it actually was 'too soon to say'. Over the past several weeks, I've seen the RL memory usage start out at under 15MB, then gradually creep up until it's over 1.5GB.  Restarting the service (sometimes I have to kill the task to get it to unload) gets it back down, and the process begins again. 

What information can I collect to narrow down the cause of this? 

Platform: Windows Server 2016 Standard, running in a VMware VM with 8GB RAM and 8-core processor,  IDM remote loader version, AD driver version 



Honored Contributor.
Honored Contributor.

(also, should I start a new thread since this one is so old?)
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.