Z,

I heard back from the customer and he resolved the issue. Here are the changes he made:

1) The polling thread was calling a method using locally declared variables with C# ref as parameters. I changed the variables to C# Public Properties with Getters/Setters and got rid of the ref parameters on the method call.

2) I moved the creation of the “new EasyOPCclient” to the constructor of a separate class to ensure that only one client exists at any given time.

3) I reinstalled the latest SW Toolbox OPC, licensed and built the solution against those dlls.

The memory usage has held steady for two days now whereas it previously increased by 100MB/day.

Thanks for you efforts on this.

Regards,
GK

Z,

Please see the below email that I received from a customer:

"I have written a number of Windows services in C# running on Server 2012 R2 that use your OpcLabs.BaseLib and OpcLabs.EasyOpcClassic .dlls version 5.50.323.1 to read and write values from and to Automation Direct PLCs under KepServerEx control. The latest service is experiencing memory buildup when polling a dozen PLCs at 60 second intervals in a thread. Indications on Windows Task Manager are that it is growing at about 100MB per day. I have used Ants Memory Profiler and the growth is entirely in Unmanaged Code. The only Unmanaged Code source in this service is the referenced Opc .dlls. There are no C# arrays, lists or objects being constructed in the polling thread, only objects that were constructed at service startup. I have tried disposing of the EasyDAClient by calling the client.Dispose method in the dll interface, nulling the object reference, and calling GC.Collect() all to no avail."

Please let me know what additional details I need to obtain from them, or if you have any questions I should ask.

Thanks,
GK