0%

OPCDA errors

0x80070776

The following error may occur when a client (ie. Enterprise Guide, VB,
Java) attempts a connection to a remote SAS Objectserver.

Function Name:Advise CILanguageEvents
0x80070776 - The object exporter specified was not found.

Permission was not granted by the client for the server to make calls on
the server interface.

Listed below are possible reasons that could cause this error:

  1. The IP address on the client machine is being used by another
    computer at your site.

  2. The client machine has been configured with TCP/IP as a network
    transport, but TCP/IP is improperly configured. For example, the
    client machines may be configured to dynamically assign an IP
    address using DHCP, yet a DHCP server may not be available, so
    there is no available IP address. The solution in this case is to
    properly configure TCP/IP networking.

  3. With Windows2000 COM, the marshalling packet contains the DNS
    name. If the client is unable to ping the server with this
    fully qualified domain name, then this error may occur. Use a
    network monitoring trace facility such as netmon to take a trace
    of the conversation and check to see what name is being returned
    on the response packet to your OpenConnection method call.

  4. Using DCOM across proxy servers, verify that the client computer
    and proxy server can reach the DCOM server. Verify this by
    using the full computer name, such as <computername.domain>.

I don’t believe that this is caused by a firewall. I have added some comments for clarification about firewall / ports below for completeness, but I don’t believe this is the issue you are running into. The 80070776 error you are getting is “The object exporter specified was not found”, which generally indicates some type of network conflict. It is most likely due to improper DNS resolution. I would suggest adding an entry in the HOST file that matches the shortname of the target OPC Server. Are you able to connect / ping the target machine properly?

To add on to the previous comments, opening up port 135 between the interface (client) and the server is not enough. DCOM communications initiate on port 135 and will then use an ephemeral port. For Windows 2008 (Vista) and later, the ephemeral port range is 49152-65535. Because OPC operations may also use callbacks (async), those ports need to be opened bidirectionally.

It is possible to reduce the port range for ephemeral ports, but you risk running into port exhaustion. See more details on how to do so here: 2973OSI8 - Configuring ports for DCOM for use with the OPC Interface. NAT and Firewall considerations Additionally, although the local Windows Firewall is turned off on the machine it does not mean that it does not have to go through a firewall on the network. I would suggest contacting your IT/Infrastructure/Network team. If you are still seeing the message after defining the ephemeral port range and insuring that all of the ephemeral ports are opened, the next step would be to look at a network trace (Wireshark or netsh) and then looking from lost packets.