Hello.
You have a console application right?

If so, we will try easier steps, before we proceed to using AssureSecurityInitializationAndRunOnStaThread .
I apologize for changing the approach, I have not realized all consequences upfront.

Please do this:

1. Is there an [STAThread] attribute on the program's main method?
2. If yes, remove it.
3. Put an [MTAThread] attribute on the main method.
4. Build and run the program again. Has anything changed (does it still give the error)?
5. Check the Windows Event Log. Is the same event still there?
6. If the error is still there: Add a ComManagement.Instance.AssureSecurityInitialization() call to the very beginning of the program's main method (this is an easier one - no arguments - just call it is it is).
7. Build and run the program again. Has anything changed (does it still give the error)?
8. Check the Windows Event Log. Is the same event still there?

Thank you

Hello, and thank you.

It is important to know about this event, but it does not necessarily imply a problem. It just tells us that in the current state of things, many DCOM-related settings inside your app will be ignored, because "something" had initialized the COM security before we had a chance to do it.

I should say that this is complicated matter - and that is still an understatement.

Please read the following article to get some basic idea: kb.opclabs.com/COM_management
and have at least a brief look at kb.opclabs.com/COM_settings_in_OPC_Classic_client_components to get an idea of what we are dealing with.

I suggest to upgrade to version 2023.1, *and* encapsulate all your app code by a call to AssureSecurityInitializationAndRunOnStaThread method (opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User's...lizationAndRunOnStaThread.html ). Even if that does not directly resolve the issue, it should at least get rid of the error in the event log, allowing us to experiment with the DCOM settings from inside the application.

Best regards

Hello, thank you for the details.

Can you please start Windows Event Viewer, then select Event Viewer (Local) -> Windows Logs -> Application, and check if there are events around the time the program was started and the first time the error occurred afterwards? If there are such events, please post them here.

Thank you

Hello.
Yes, this is almost certainly related to DCOM security.

I have earlier suggested an update to a current version (which is now 5.71). Please do it at the first opportunity, because we cannot reliably support older versions.

I have some additional questions:

1. Which operating system is running on the client and server side? Could they be affected by support.microsoft.com/en-us/topic/kb5004442-manage-changes-f...52-c141-43d2-941e-37ed901c769c ?

2. Has it been working before, and only stopped working at some date? Or was the only difference the version change you mentioned?

3. What type of project are you building in VS? Such as Console app, Windows Forms app, Windows service, Web service, etc.?

4. Are you targeting .NET Framework or .NET Core/.NET 6+?

5. Is there a specific reason for having the EnableNativeClient = false setting?

Best regards

Hello.
I need some additional information:

1. The [...] in the error message indicates that are are more lines to the message. Please get the full message (Message property of the Exception object in the result object). And, and if there is .InnerException inside that exception, also the Message of that InnerException, and so forth.

2. 5.63.246 is not the current version. The current version is 5.70. Please test with it and report what the results are.

Best regards