It is possible that there will be no fix at all. It all depends on the library vendor, we have no control over it.

If the vendor provides a fixed version by the time of QuickOPC 2021.3 release, we will include it. Older versions will not get updated.

Best regards

Hello.
I have determined that the problem is caused by a 3rd party library (BoxedApp SDK) that we use inside QuickOPC.

You can turn it off like this: kb.opclabs.com/How_to_disable_prerequisites_boxing , and the memory leak goes away.
The downside is that, if the QuickOPC client app will need to create its own instance certificate (usually on the first run), the OPC UA certificate generator utility (Opc.Ua.CertificateGenerator.exe) will have to be present on one of its search paths (can be directly next to your executable).

We will report the problem to the library vendor.

Best regards

Understood. Thank you.

Hello.
I was able to reproduce the issue on Windows Server 2016. I am running various tests now to get some picture of what influences it. It will take time.

Question:

You reported that the application eventually ran out of memory. Was that with the "minimized" project - precisely the one you have sent me - or with some other application where the problem was originally detected?

The reason I am asking is that I have a documented case where the user has seen a constant memory growth for 72 hours (3 days). And we starting looking at it. But, when we ran a longer test, the GC has eventually decided to deallocate the memory on 4th day. So in the end there was no memory leak. If the "out of memory" condition was observed with the original application only, I will have to repeat that test with the minimized project, to see if it also behaves that way (i.e. not only seems to consume more and more memory for cca 12 hours as I did, but over even longer time). But if you have already proved that with the minimized project, I will rely on your test.

Regards

Hello.

I suspect the problem may have to do with the garbage collector not being able to run under some circumstances (in a STA when no message pumping is done - becasue message pumping is a *must* in an STA). See e.g. social.msdn.microsoft.com/Forums/vstudio/en-US/835db88e-db51...-stathread-specified?forum=clr .

Try to pump messages inside your loop, OR make sure the main thread is an MTA thread (add [MTAThread] to Main(), or otherwise).

More info:
- EasyXXClient does not explicitly set the apartment state, to my knowledge, but EasyXXClient objects are exposed as COM objects using .NET interop, so the .NET might be doing something there on its own.
- Re periodic processing: There should be no such processing in the simple code you provided (when the EasyXXClient is just created and nothing else).
- GC is not called explicitly from our own code.
- There is no periodic allocation of memory when no OPC communication is ongoing.

Best regards