I really appreciate your efforts. In fact, we might finally be getting somewhere. It is now likely that the there is server registration problem, but not on machine A as I thought, but on machine B.

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.
Best regards

Thank you for the results and explanation.

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

Hello,

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

Thanks again.

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

Can you confirm that this is how you understand your setup:

- 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

Thank you again.

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