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 COM
- Connections, Reconnections, COM/DCOM
- Issues connecting to DeltaV servers.
Issues connecting to DeltaV servers.
I have made an improved version of the test tools. I would like to make you one more test. This time, the tools are capable of specifying whether they want DCOM to activate 32-bit or 64-bit server on the remote end (machine B ). Since the 64-bit registration appears to be broken (and 64-bit server activation is the default for 64-bit clients), we want to instruct the DCOM (in some of the tests) to explicitly activate the 32-bit server on the remote end. If that succeeds, we will know for sure what the problem is.
Can you please unpack and use the tools from the attached ZIP file, and then run following 4 commands, and post the output? All on machine A. Thank you.
ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_32_BIT_SERVER
ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_64_BIT_SERVER
ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_32_BIT_SERVER
ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F} CLSCTX_ALL,CLSCTX_ACTIVATE_64_BIT_SERVER
Please Log in or Create an account to join the conversation.
I'm not able to physically disconnect the machine, so I created firewall rules blocking all traffic to/from other machines that either host the deltav server or have a mirror of it similar to the one we've been working on.
Here are the results:
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>ping 192.168.2.220
Pinging 192.168.2.220 with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 192.168.2.220:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 32
*** Error: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 64
*** Error: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
C:\Users\[companyname]\Desktop\[companyname]\BuildOutput>
Please Log in or Create an account to join the conversation.
In my view, the results now make it 100% clear that there is nothing wrong on the QuickOPC side. It is simply that the 64-bit processes cannot instantiate the DeltaV OPC server's main COM object; any OPC Classic client running in a 64-bit process would have the same issue.
This does not stop the investigation, but it rules out one area of options. It is a mystery, however, because the registry settings appear correct to me. And, when the server is "redirected" to machine B in this way, it should not matter whether on machine B it is a 32-bit or 64-bit server. But, because everything looks OK on machine A, and I am running out of ideas, I'd like to rule a somewhat far-stretched possibility that DCOM is attempting to activate the (probably non-existing) 64-bit server on machine B.
Would it be possible, for a short test, to shut-down machine B, or break the network connection between machine A and machine B? And then re-run ComCreateTest32 and ComCreateTest64? The intent here is to determine whether the "class not registered" comes from machine A (in which case the results will be the same as we had already), or whether the problem comes from machine B (in which case, breaking the connection should result in a different error - probably one of the RPC errors).
If you could do this, please also re-start machine A just before performing the ComCreateTest32/ComCreateTest64 tests. This is to assure that machine A won't use cached information from the time the connection to machine B was still fine.
Best regards
Please Log in or Create an account to join the conversation.
C:\ ... \BuildOutput>ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 32
Success
C:\ ... \BuildOutput>ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
CLSID: c3b72ab1-6b33-11d0-9007-0020afb6cf9f
Bitness: 64
*** Error: Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
C:\ ... \BuildOutput>
Unfortunately I do not have access to Machine B.
The dependency is an SDK provided to us by another vendor for one of the instruments our system connects to. We have the source code for it, so we could in principle rewrite it, but the linking settings etc for the project have only been set-up for x64. It's not impossible but it wouldn't be a small task.
Please Log in or Create an account to join the conversation.
I have created the little tool(s) I have mentioned. They are in the attachment.
Can you please open the command line prompt on machine A (the client machine) and run
ComCreateTest32.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
ComCreateTest64.exe {C3B72AB1-6B33-11D0-9007-0020AFB6CF9F}
and let me know what the results were. If you could do it on machine B (the server machine), then that would be a plus.
Can you also elaborate on the fact that is preventing you from switching the project to 32 bits - you wrote that you had a 64bit-only dependency. Those are pretty rare - is that some commercial product, or what is it, if I may know?
Best regards
Please Log in or Create an account to join the conversation.
Actually, the registry settings indicate that on machine A, references to DeltaV server are simply forwarded to machine B by DCOM. So there appears to be no "synchronization", or a copy of the DeltaV server on machine A. Breaking the link to machine B should result in loss of connectivity right away.
But with that being the case, it is even more mysterious why 32 bits work and 64 bits don't, because the DCOM infrastructure in between fully hides these differences from the client, normally. And the registry appears OK.
Next step: I'd like to prepare two small programs, one 32-bit and one 64-bit, that would simply create an instance of the DeltaV OPC Server - that is, no QuickOPC involved, just plain C# or C++ code. And I will ask you test them out. The reason I want to do it is that I want to be absolutely sure whether the issue is something specific to QuickOPC, or can simply be attributed to the client program being 64-bits. Knowing that for sure, I would be able to direct the further steps without risking that I am going the wrong way. I will most likely prepare these programs over the weekend.
I have no reply from Emerson yet.
Best regards
Please Log in or Create an account to join the conversation.
All fair points, still remote sessions are available if it comes to that.
Edit: Please let me know if there is any other information I can provide to help debug this.
Please Log in or Create an account to join the conversation.
- You have machine A, where the QuickOPC client test resides, where you have performed the two tests (32/64 bits), and where you have made the registry exploration and registry exports. At the same machine, there is "one part" of the DeltaV OPC server.
- You then have machine B (192.168.2.220) where "the other part" of the DeltaV OPC Server resides.
Remote session is an option, but our own local system would be much much better. Locally I can install development tools like Visual Studio, and make small programs and experiments easily. That would have to be somehow prepared upfront, and still I cannot foresee what will be needed in the next step - likely resulting in multiple remote sessions etc.
Thank you
Please Log in or Create an account to join the conversation.
Would remote access or running a version of the demo app with more verbose logging be useful? I would need to supervise a remote session as this is an active installation of our product, and could do it during normal business hours, Eastern Standard Time.
Please Log in or Create an account to join the conversation.
I am now confused: The registry entries from Step 11 and Step 12 indicate that the server is configured to run remotely, on 192.168.2.220 (this is the kind of configuration where the client does not have to specify the remote machine - it "looks" like that it is local, and DCOM redirects the server activation and calls elsewhere).
Can you comment on that? I thought that we were troubleshooting the situation where the server and client resided on the same computer. If it is set up differently, please describe how.
Besides this open part, I have not yet discovered a problem with the server registration, so I still do not know the cause.
Best regards
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in COM
- Connections, Reconnections, COM/DCOM
- Issues connecting to DeltaV servers.