You should not use prerelease versions unless instructed to.
They are for our internal use.

Best regards

I can confirm that there are calls to SubscribeMultipleItems and UnsubscribeMultipleItems that are blocked.
But it remains unknown what is causing it.

In two types of cases, the threads are waiting on a critical section that does not seem to be entered anywhere else. A hypothesis for this is that the thread that had entered the critical section might have terminated unexpectedly (earlier), in which case (according to Microsoft documentation) it can remain in locked state.
In the third type of case, the call waits on a critical section entered by an internal thread, which (among others) takes care of "garbage collection", which includes disconnection from servers that are no longer needed (there are items subscribed on them). This can block until the disconnection is finished, that is not an ideal design but that's how it is. It looks like that there is a bug that even though the server might have been disconnected, the garbage collector does not get the corresponding notification. According to the call stack the garbage collector is waiting, but I could not find the thread that actually "works" on the disconnection. This is something I have tried to at least partially address in the earlier "fix", but it looks like that is still there. And is similar to the first two types of cases - it looks like that if some threads are "gone", leaving the synchronization objects in an undefined state.

I am sad to report that further progress on this is probably not possible; certainly not without having a reproducible scenario on our computer.

I can only suggest some workarounds to reduce the likeliness that this happens:
- Increase EasyDAEngineParameters.GarbageCollectionPeriod (default 2000), in static EasyDAClient.SharedParameters.EngineParameters
- Increase EasyDAEngineParameters.AutoAdjustmentPeriod (default 500)
- Increase EasyDAEngineParameters.MaxTopicAge (default 1000)
- Increase EasyDAEngineParameters.MaxClientAge (default 5000)
- Do not unnecessarily unsubscribe

Depending on the application, it might be possible to increase these e.g. 10 times or 100 times.

And, add some higher-level functionality checking and app restart if necessary.

Regards

Not yet. Working on it.

It depends on the symptoms.

There are OPC-DA related threads in the all stacks, that is true. But none of them is a user thread.
If you were subscribed to OPC-DA items, and the notifications has stopped coming "forever", then yes, it would probably be possible that the call stacks represent
such state. Was that the case?

But, it is impossible that the call stacks represent a state in which, for example, a call to ReadMultipleItems on OPC-DA items was hung, because there is no such thread in them.

Re "The lot of them are stuck somewhere internally subscribing/unsubscribing to/from opc tags.". I do not see anything like that in the call stacks. For is the base of your claim?

Re "Can you send me debug symbols if you cannot fix it?": No.

Re "Do you have an option to provide access to your source code? : No.

Regards

I have reviewed the call stacks from posts #8225 and #8253.

The user threads (your threads) are all related to OPC XML-DA. There are also threads for OPC DA, but they are internal threads, so even if they were blocked, you could not have perceived them as blocked. So I assume your problem was that the methods called (ReadMultipleItems or so) had not ever returned - or had not returned in time.

This is therefore a different situation from what has been addressed (regarding this topic thread) earlier.
Because the current problem now seems to be related to OPC XML-DA, I have forwarded my preliminary analysis to the programmer that has developed this part (I cannot determine more myself).

Regards