Hello.

I have looked at the application code. I would say that creating new and new instances of EasyUAClient instances inside the timer is simply a bad idea. it doe snot bring any benefits at all, so to make my point, I suggest that the customer creates just a single EasyUAClient instance outside the timer, and everything should be fine.

The EasyUAClient object, even though it has a capability of sharing the same "physical" connection objects such as UA sessions and subscriptions among its instances, is relatively heavy in terms of memory and other resource consumption. What is likely happening is that, even though the EasyUAClient goes out of scope when it is created inside the timer, the .NET garbage collector keeps it around because it has better things to do. Remember that memory management in .NET is up to the .NET runtime. A memory growth does *not* always a memory leak. In extreme case, .NET runtime can use almost all available memory and only then decide to release finally the unnecessary space - why not? 

There might implementation changes in what precisely happens in relation to EasyUAClient object disposal/finalization, so it is possible that the behavior in this case has changed after version 2021.1. But again, doing the instantiation in a timer was and still is completely unnecessary, so hunting for the precise explanation of the difference would not bring anything useful.

It is not clear how the memory issue relates to the "exception" problem - and why they think the "exceptions" are a problem at all.. Do they refer to Opc.Ua.ServiceResultException-s in the debug output? If so, they are internally handled in the library, so of no concern to the customer. It is also unclear how the exceptions - quote: "upon launching the application" can relate to the suspected memory leak that, upon the time of launching, cannot be happening yet. 

Regards

Hello,I have a customer who is upgrading their application to use the latest release and .NET 8, developing in Visual Studio 2022. They plan to run the application on Windows Server 2025. After some runtime, they began experiencing memory growth that appeared to be a memory "leak," along with some exceptions upon launching the application.To investigate further, the customer created a simplified test application and was able to replicate the behavior on both Windows Server 2025 and 2019. At that point, they reached out to us and provided the test application for internal testing.I ran the application on multiple environments (Windows 10, 11, and Server 2022), changing only the OPC UA server endpoint, channel, and tags to match our test setup. The OPC UA server in both our and the customer's environments is TOP Server. In all my tests—using both local and remote endpoints—I was unable to reproduce the memory growth or see any exceptions.Given that I haven’t been able to replicate the behavior, I wanted to reach out and see if you had any additional insight into what the customer may be experiencing.I've attached the test project exactly as provided by the customer:

• You are not authorised to see this attachment.
• You are not authorised to see this attachment.

The customer did mention that moving the creation of the object outside the event (so it's not recreated with each tick) resolved the memory growth issue. However, they’re still unsure why this issue didn’t occur in their previous application, which was developed with version 2021.1.Your attention and insight would be greatly appreciated. Please let me know if you have any questions or need any additional information.Best regards