- Posts: 71
- Thank you received: 10
Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- General Issues, Building
- EasyDAClient Unable to browse branches on a remote OPC DA (Using Cogent proxy)
EasyDAClient Unable to browse branches on a remote OPC DA (Using Cogent proxy)
The CLSID listed in the first event corresponds to PerAppRuntimeBroker, and the event hinted at security issue. The debugger does some "extra" things to the hosting process, and it is possible something is broken there. When you Google for the PerAppRuntimeBroker and event 10016, you will get bunch of interesting results. Nothing conclusive (and not precisely what we are seeing), but my general impression from those posts is that there is some Microsoft issue related to that. There are some procedures on the Web intended to fix the issue(s), but none of them quite reliable, I think.
It might be possible to experiment with Debugger settings in VS to see if there isn't something that has effect on the outcome.
And thank you once again for providing such clear reports, with images etc. - that makes the support work enjoyable
Best regards
Please Log in or Create an account to join the conversation.
support wrote: Hello.
the latter event (10010) is clearly the one that is then transformed to the COM "Server execution failed" error. I know that from past experience.
1. Can you please confirm that the first event (10016) *only* appears together with 10010. That is, that it does not appear with your QuickOPC app (e.g. the pre-built demo) that connect to the Cogent server successfuly?
2. Can you try running your app outside of the debugger, to see if it makes any difference? Ideally, starting it outside of Visual Studio, just by double-clicking its EXE. And, even if it still does not connect, is the error message precisely the same, and also the same two event appear in the log?
Thank you
Hi,
Indeed It is a DCOM configuration issue for the CogentDataHub object, even tho permissions were granted for mostly every type of windows user agent, it still fails when running on the debugger, not sure what's the internal account the debugger is using when trying to access DCOM objects in that specific solution session but it is being denied, even tried disabling DCOM Authentication completely, gave 'Everyone' and 'Anonymous' full access rights and still hit the same wall. You were right, running a release version ended up working with local OPCLabsKitServer and Cogent too, did not thought of that possibility because I was able to browse the local server on debug and also in the testing project I was able to read the tunneled Cogent server on debug mode as well...
Thanks for the support,
Best Regards,
Iker Ruiz Arnauda
Attachments:
Please Log in or Create an account to join the conversation.
the latter event (10010) is clearly the one that is then transformed to the COM "Server execution failed" error. I know that from past experience.
1. Can you please confirm that the first event (10016) *only* appears together with 10010. That is, that it does not appear with your QuickOPC app (e.g. the pre-built demo) that connect to the Cogent server successfuly?
2. Can you try running your app outside of the debugger, to see if it makes any difference? Ideally, starting it outside of Visual Studio, just by double-clicking its EXE. And, even if it still does not connect, is the error message precisely the same, and also the same two event appear in the log?
Thank you
Please Log in or Create an account to join the conversation.
support wrote: Hello,
thanks for the details. I was also thinking that something must be different 0 be it the server descriptor, or the project setting, or the code. But all of that seems to be correct, I agree.
This shifts the focus more to the error itself, and to the server.
First, are you making the tests always under the same user account? Always under the debugger, or sometimes without it? Always with, or always without administator (elevated) privileges?
Second, do you know how is the Cogent server configured to run? Is it a Windows service, or a COM "Local Server" (meaning that it starts and stops depending on how the clients use it).
Third, please start Task Manager, switch it to the Details view/tab, sort processes by name, and look for the process that corresponds to the Cogent server. And, observe what is happening when you do the "passing" test, and what happens when you do the the "failing" test. Is there always a Cogent server process? Does it start and then disappear? Are there sometimes two or more of them? Are there differences between the "passing" and "failing" scenario?
Fourth, please check the Windows event log to see if there are signs of crashes of the server (or some other process), especially around the time of your test(s). Type ""Event Viewer" into the Windows Search box and run it, and look under Windows Logs -> Application (and possibly others).
Thank you
Hello,
1. Always using the same user accounts in both client and server, running in Debug x64 within Visual Studio 2017. Not elevated rights anywhere.
2. Not sure, both client and server have a running process 'CogentDataHub.exe' and both have a CogentDataHub DCOM configuration object. The process itself its related to the UI program, so if you close that window the process ends along with the tunnel.
3. I have not seen any visible changes in the processes tab between the working and nonworking tests, there is always only one process running CogentDataHub.exe.
4. There is indeed a DCOM related issue when the exception is thrown..
Please Log in or Create an account to join the conversation.
thanks for the details. I was also thinking that something must be different 0 be it the server descriptor, or the project setting, or the code. But all of that seems to be correct, I agree.
This shifts the focus more to the error itself, and to the server.
First, are you making the tests always under the same user account? Always under the debugger, or sometimes without it? Always with, or always without administator (elevated) privileges?
Second, do you know how is the Cogent server configured to run? Is it a Windows service, or a COM "Local Server" (meaning that it starts and stops depending on how the clients use it).
Third, please start Task Manager, switch it to the Details view/tab, sort processes by name, and look for the process that corresponds to the Cogent server. And, observe what is happening when you do the "passing" test, and what happens when you do the the "failing" test. Is there always a Cogent server process? Does it start and then disappear? Are there sometimes two or more of them? Are there differences between the "passing" and "failing" scenario?
Fourth, please check the Windows event log to see if there are signs of crashes of the server (or some other process), especially around the time of your test(s). Type ""Event Viewer" into the Windows Search box and run it, and look under Windows Logs -> Application (and possibly others).
Thank you
Please Log in or Create an account to join the conversation.
support wrote: Hello,
thank you for the additional information.
I wanted to verify the ServerDescriptor you are using now, but nowhere in the images provided was it sufficiently displayed (it is there, but for the OPC Labs Kit Server, which works); I'd like to see it in the debugger when the exception occurs, with Cogent server. Can you please provide a picture showing the contents of the ServerDescriptor you are actually using?
Some additional questions, just checking/trying to limit the possibilities:
1. is this on 32-bit or 64-bit machine?
2. In the project properties in Visual Studio, is the target set to AnyCPU, or to x86 or x64?
3. can you try to construct the ServerDescriptor simply like this: new ServerDescriptor("", "Cogent.DataHub.1").
Best regards
Hey there,
I've been doing further testing, created a new console project (.NET Framework) target 4.6.2, installed QuickOPC from nugget, did a simple block of code in order to Browse servers and then Browse branches and leafs, turns out the tunneled OPC works here. I compared both working and nonworking ServerDescriptor object hash and they are identical, both projects target 4.6.2 Framework, both projects target x64, both are running as Console applications.. I'm kinda lost here..
Not working project ServerDescriptor object:
Working project ServerDescriptor object:
Not working project ServerDescriptor hash:
Working project ServerDescriptor hash:
Not working project properties/targets:
Working project properties/targets:
Not working project QuickOPC version:
Working project QuickOPC version:
Thoughts?
Regards,
Please Log in or Create an account to join the conversation.
thank you for the additional information.
I wanted to verify the ServerDescriptor you are using now, but nowhere in the images provided was it sufficiently displayed (it is there, but for the OPC Labs Kit Server, which works); I'd like to see it in the debugger when the exception occurs, with Cogent server. Can you please provide a picture showing the contents of the ServerDescriptor you are actually using?
Some additional questions, just checking/trying to limit the possibilities:
1. is this on 32-bit or 64-bit machine?
2. In the project properties in Visual Studio, is the target set to AnyCPU, or to x86 or x64?
3. can you try to construct the ServerDescriptor simply like this: new ServerDescriptor("", "Cogent.DataHub.1").
Best regards
Please Log in or Create an account to join the conversation.
support wrote: Hello,
I have some questions.
1. What happens when you try to connect using the Connectivity Explorer, but remotely?
2. What happens when you try to connect using your application, but locally?
3. Is the BrowseNodes first thing your application does with the target OPC server (and it fails right away then), or are there other OPC operation done with that target server before the NrowseNodes, and they work well?
Note: I spotted in your code a somewhat unusal handling of "Element" vs. "Descriptor" objects. For example, you seem to be creating ServerElement from various parts first, and then making ServerDescriptor out of it. That is not normally needed. The descriptors contain everything that is needed to reference some entity (such as the OPC server). The elements are outputs from discovery/browsing, and contain additional useful information, that is however not used to actually refer to the desired entity. So, you should probably be creating ServerDescriptor right away. I am mentioning it because there is a danger that by unnecessary complicating the code, you have made some mistake. You can construct the ServerDescriptor e.g. right from UrlString you have (a simple string), or from two strings - machine name, and server's ProgId. Let me know if you need help with that.
Best regards
Hey there,
1. Remote TopServer is not visible through the network with out using a TCP proxy, so no, you cannot discover the remote server with Connectivity Browser or with any OPC client.
2. My application is able to browse OPCLabs Kit Server (local) with out any issue (Discover/Subscribe/Pull/Etc)
3. I do not call BrowseNodes directly, I call BrowseBranches which is probably calling BrowseNodes internally and throwing.
4. I modified the code to use a descriptor like you suggested simply built from the url.
Using Connectivity Explorer to browse the tunneled OPC Server.
Even the OPCDA Winforms Explorer from the NET examples is able to browse it:
Local OPCLabsKitServer in Code (Branches): (WORKS)
Local OPCLabsKitServer in Code (BrowseNodes): (WORKS)
Local OPCLabsKitServer in my program. (WORKS)
Trying to read the tunneled Branches: (FAILS)
Any call done through EasyDAClient to the tunneled server fails, BrowseBranches, BrowseAccessPaths, even trying to directly ReadItemValue with location and item id fails..
Please Log in or Create an account to join the conversation.
I have some questions.
1. What happens when you try to connect using the Connectivity Explorer, but remotely?
2. What happens when you try to connect using your application, but locally?
3. Is the BrowseNodes first thing your application does with the target OPC server (and it fails right away then), or are there other OPC operation done with that target server before the NrowseNodes, and they work well?
Note: I spotted in your code a somewhat unusal handling of "Element" vs. "Descriptor" objects. For example, you seem to be creating ServerElement from various parts first, and then making ServerDescriptor out of it. That is not normally needed. The descriptors contain everything that is needed to reference some entity (such as the OPC server). The elements are outputs from discovery/browsing, and contain additional useful information, that is however not used to actually refer to the desired entity. So, you should probably be creating ServerDescriptor right away. I am mentioning it because there is a danger that by unnecessary complicating the code, you have made some mistake. You can construct the ServerDescriptor e.g. right from UrlString you have (a simple string), or from two strings - machine name, and server's ProgId. Let me know if you need help with that.
Best regards
Please Log in or Create an account to join the conversation.
Cogent DataHub is working.
Browsable through Connectivity Browser
Find the server via BrowseServers()
Fail
It would be a great assistance if you could offer me some advice in order to fix this.
Regards,
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- General Issues, Building
- EasyDAClient Unable to browse branches on a remote OPC DA (Using Cogent proxy)