Memory leak while using OPC UA Server


We have OPC UA server with an integer tag .
We could connect to the OPC Server using Ignition.
We have timer based client script firing every 10 ms to write to the integer tag with value of 50 as shown below

We could see the memory growth for every write.
We have observed the traffic using Wireshark . We could see for every OPC UA write there is a OPC UA read is performed .

We suspect this additional OPC UA Read may cause the memory increase.

Could you please help us why there is additional OPC UA Read while using Ignition?


The Read asks the server for the DataType, ValueRank, and ArrayDimension attributes so the Ignition client can be sure to send a value with the correct DataType in the Write. Unfortunately this information is not cached anywhere right now, so it happens for every write as you’re seeing.

Hi Kevin,

I have been working with Antoni on this. You mentioned that “this information is not cached anywhere right now”. Can we expect this to be added in Version 8? Is that still expected to be released in Q1 of 2019?


I’m not sure this will be added for 8 or not. It’s low priority because it shouldn’t really matter.

The current release date target is February 2019.

HI Kevin,
We appreciate your quick reply on this. Thank you.

We suspect that the memory leak is because of not caching the information by ignition.

We have tried with another OPC UA client “OPC Labs Data client” , we do not see any memory leak in our OPC Server.

Is it safe to assume the memory leak is because of this behavior? Please advise.

NOTE : Our OPC server is developed using VB .NET .

Thank you again


It's possible, but my point is that reading those values repeatedly shouldn't cause a memory leak in your OPC server. If it does, that's a problem you need to fix, not us.

Hi Kevin,
Thanks for the reply .

Basically we use COM object inside our .NET application. In our case the OPC UA tag is a COM object which is referred by Ignition script always and never get released.
Is there anyway to release the COM referred object to read/write from python script?


Hi Kevin
I could not get any response for memory leak issue introduced by ignition software when I have connected COM type server to it.
When the opc tags are referred then the reference for COM object is auto incremented. The memory for COM object are released only when the reference count to COM Memory Object is zero. The ignation software these references are incremented but never get released so memory can not be collected by garbage collected. This memory can be released using
" System.Runtime.InteropServices.Marshal.ReleaseComObject(COMObject);
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(COMObject);" in ignition side software.
When these tags(COM_) objects are referred in the c# side application we are using these statements to release reference. but still one reference is pending which is hold by ignition software., hence associate memory is not collected and memory leaks.
I request to do the necessary action and reply ASAP to make the ignition compatible to all type of server like COM servers.

Thanks ., Awaiting reply ASAP.

Are you still talking about an OPC UA connection from Ignition or are you talking about an OPC COM/Classic connection now?

Yes. Thanks for reply, That issue is resolved from this side. When we do asynchronous write that happens. When we do synchronous write call that works fine as expected,. But still there is memory leak in even in synchronous write. For now I will further investigate server side application and get back to you on this, for any server c++ or COM server when we do write though Ignition, memory leak starts but when server side write calls no leak, what to do? Thanks for reply again.

I am talking about OPC UA connection to OPC COM server connection. When the values for tag is written by COM server., It allocates the memory for result array, Which should to be freed by ignition software after reading the result for each item using CoTaskMemFree(Results). If not freed the memory allocated by COM server will remain ,will cause memory leak. Please verify the same from Ignition side weather the return values are freed after writting ?
Thanks for Help. Appreciating your response in advance.

That's not how OPC UA works. There's no shared memory and nothing for the OPC UA client to "free".

When you want to read.or wtite to tag the call is made to COM server? During this call a set of parameters are sent like result i.e. read success or write success to Ignition client. Once Ignition reads the result variable that needs to be freed?
I hope this is correct if not correct me?

You said this was on OPC UA connection, so the OPC UA Read and Write services are called. If there is an OPC COM server sitting behind it or involved in the implementation, that's transparent to Ignition.

Unless it is Ignition's own OPC-COM module, in which case the entire discussion has been under the wrong title and assumptions.

Thanks Once again for the reply. Its very clear. Still I have one more doubt. When item values are written to COM server tag through Ignation, It is sending 3 times GetItemProperties and QueryAvailableProperties calls to COMserver for each write., whereas other Clients are not calling these functions at all. Its ok to send but the COM server is filling the BSTR string value to the properties of the tag, but I doubt whether client is clearing the BSTR memory after using that.

Thanks for all replies once again.

Thanks for not replying. I got the answer myself. Since I have UA client other than Ignition which does not leak memory where as when I do the ignition as client leaks memory. I am investigating since 15 days. So I got some silly questions.
Anyway Thanks again.

Snark doesn't help presenting your issue here. And you were answered. UA clients don't have access to a UA server's memory, so your memory leak can only be your own problem.

You keep mentioning "COM" objects, which aren't used in OPC/UA. If you have implemented the legacy OPC/DA protocol, which does use COM objects, there must be a "shim" between Ignition and your server. Such a shim might be contributing to your memory leak, but you haven't provided sufficient information about your setup to even identify whether this scenario applies.

If you cannot share more information in this public forum, consider contacting IA support to obtain professional help. Also consider climbing down from your high horse when asking for free help on a user forum. I'm not a COM technology expert, but there are some on this forum, I believe.


Thanks. Memory leak found in third party tool used in COM server used., Which none of the tool were detecting. So things are neutralized for now. I again appreciate your patience and help time to time Good bye.

1 Like

Glad you got it sorted out.