Hello,
thank you for the files.

I have some questions:

1. Are you running on .NET Core, or .NET Framework? If on .NET Core, which operating system? I have to ask because you have also not provided the LogEntry notifications from the start of the program, which contain all of this. [note to myself: this question relates to the appearance of BadNotConnected status code]

2. Please confirm that you are running QuickOPC version 2018.3. Again that would be in the log entries at the beginning, but I do not have them.

3. It seems that each notification is written exactly 5 times in the files. I can "filter it" out, but I just want to not whether you are aware of it, and why is it. Aren't you hooking multiple times to the same static event?

4. When the logs were taken, were you running with debugger attached, or without?

5. Are you logging just Warning/Error kinds of notifications in LogEntry, or are Information notifications also included? (I do not see them, so I do not know whether they were not generated, or whether they were generated but not included in the log file).

6. Have you tried to wait very long (such as over 20 minutes) to see if there is still no recovery? What happens then? The reason I am asking this is that there are various timeout periods, and most of them are quite short, but the default for the so-called OperationTimeout is 10 minutes I believe, so under rare circumstances this can slow down things. I am almost sure that this is not the case here, but want to verify it anyway.

[Note to myself for possible next troubleshooting step, depending on the answers: deadlock analysis, extended tracing + wireshark]

I know you have already posted the logs; but if you want to email something in the future, you can send it to support09 (at) opclabs.com.

Best regards

Thank you, but you have removed precisely the part I wanted to analyze.
For the decision on further troubleshooting direction, I need to know whether new events, event with ""OPC-UA client session is not available when connecting the client subscription", continue to come without ever stopping, or whether that have stopped as well.

Can you please provide more information - specifically this:

What are you seeing in the DataChangeNotification event notifications observed when this happens?
- What is the first exception sent through DataChangeNotification when you disconnect in this case?
- Do you get further notifications (with different exceptions possibly) after the first one, or do they stop altogether (on the particular EasyUAClient instance)?
- Please confirm that connections through other EasyUAClient objects are behaving normally even if this happens.

Ideally, send a log that shows all DataChangeNotification-s, all ServerConditionChanged notificitaions, and also the static EasyUAClient.LogEntry notifications, when this happens.

Regarding the ServerConditionChanged : What you described is by design. The EasyUAClient object, in its default configuration (when its Isolated property equals to 'false'), acts as a broker, so in fact, if you had EasyUAClient instances A and B, and instance A connects to servers 1 and 2 and instance B connects to servers 2 and 3, there will be just one connection to server 2 from both. This, however, also means that they notifications about connections and disconnections are common and affect them both. Of course you can say they if you are not sharing, that is you have instance A connecting to just server 1 and instance B connecting to just server 2, that such behavior does not seem logical, but it has to be that way due to the possibility of sharing. If you set the Isolated property on the EasyUAClient to 'true', it will always maintain its own connections - and also it will only see its "own" ServerConditionChanged notifications. But, if two or more such instances with Isolated = true connect to the same server, you will end up with two or more OPC UA sessions to that server, which is not efficient and can cause problems.

Best regards