Hello,

are you mixing in your application access to OPC DA and OPC XML-DA servers?
Not that there is anything wrong with it. I just noticed it in the call stacks, and want to verify whether it is intentional.

Regards

Thank you - that's what I needed.
I will analyze it and let you know here.

Best regards

Hello,

there are various reasons for the "Catastrophic failure" errors. One that I have seen relatively often is that the COM infrastructure transforms unhandled native code exceptions (such as when the server is written in C/C++ and throws an exception during a COM method call) to "Catastrophic failure". So in this sense yes, the very origina of it *can* be in the OPC server. In such case the expected behavior of QuickOPC would be to try to reconnect after a configured period.

But, there is also a possibility that the "Catastrophic failure" comes from a QuickOPC bug. That would be an internal error, and in such case, anything that happens *after* the first error is undefined. It can even, indirectly, cause a deadlock.

So, we need to explore all these options. I'd like to first look at the deadlock. The screenshot and the callstacks you have provided are nice, but do not give me enough. Specifically, in the callstacks.txt, I would need more threads expanded: Not necessarily all of those you have on the screenshot, but one of every kind: I mean, if you look at how they are displayed on the screenshot, each has the location where it hangs - but many of them are the same - and the call stacks are most likely the same as well. So, can you please provide the remaining call stacks?

Here is what I expect to get from the analysis - one of two outcomes:
a) If the threads are blocked, and it can be seen from the call stacks that there is a combination of locks causing the hang, it would be quite clear that this needs to be avoided in the QuickOPC code, so we will look at it.
b) If the threads are blocked but no obvious reason can be seen from the call stacks: In such case it is possible that a lock has remained entered, but the thread that did it is gone (aborted). That would be an indication of a problem in QuickOPC but elsewhere - not sure where.

Many thanks

Hello,
I have some additional questions.

1. I assume you are referring to a contents of the Exception property of the event arguments object you receive - please confirm.

2. Can you please provide the contents of the Source and StackTrace properties of the exception object.

3. If there is a non-null InnerException (probably not), please provide details about it as well.

4. Are you doing/trying to do something "special" in order to reconnect, or you rely on built-in QuickOPC ability (which should normally work by itself, I agree)?

5. Can you please describe precisely the sequence of of events. For example, you subscribe, you get data successfuly, then at some random moment (related to server crash?), you receive the "Catastrophic failure" in the Exception property of the event arguments. What happens then (for the same OPC item)? Do more errors come - the same ones, or do you ever get a different error? Or do you receive a single "Catastrophic failure" error, and from that moment on, nothing else for the same item?

6. Which target OPC server are you connecting to? Is it local or remote?

7. You wrote "my application after that cannot reconnect to the OPC server when it is up and running". Please confirm that this referred to the already running instance of your application. And, after the server crashed and is running again, can other OPC clients connect to it, and can a 2nd, newly started instance of your application connect to it?

Thank you