We are not the originator of the error. It is a Microsoft-defined error that comes from the COM/DCOM infrastructure, most likely at the moment when we attempt to instantiate either the OPCServer object, or OPCEnum. We are just passing this error up to the application layer.

If the application has worked previously, has not been changed, and then it stopped working for one specific remote computer, then something *else* must have changed. It could be an update of one of the computers involved, or security reconfiguration. That should be investigated.

The OPC clients that had not stopped working are all developed in the "usual" way, basically a COM consumer applications written in C++ and compiled into a native code. This includes the OPC Web Client 3.03, which on the surface has a .NET interface, but in reality it just provides a transformation layer on top of a COM client running as a "local server", i.e. in a separate process, much like the other OPC clients. It seems that the only clients that are affected are those that are purely .NET based. The problem can be influenced to the fact that in the .NET world, some of the COM security settings are controlled by the host (the CLR runtime), and may be different from what the non-.NET applications receive. For this reason, I suggest that you experiment with settings mentioned in the last two posts in this forum thread:

www.opclabs.com/forum/connections-reconnections-com-dcom/124...achines-via-code-quickopc-dcom

BTW, what kind of application is your project? E.g. a Windows Forms (desktop) app, Console app, Windows Service, Web app, Web Service, or...?

Best regards

This will be difficult to investigate. Anyway, I have moved one of your posts to the same single thread, because it concerns with the same issue. Communication related to this will continue on this forum thread only.