Professional OPC
Development Tools


Seemingly random COMException

09 Jan 2018 20:19 #5846 by jgreg311
Understood. If QWORDs were invalid under WoW6432Node, then Windows wouldn't allow them.

I'm not sure if the issue lies with the Windows installer, or if it's the MSI file itself that is being generated by my Visual Studio Installer Project. I even tried compiling for x64, but other issues cropped up with the installer project (related to the installer class I'm using for the Windows service generating a BadImageFormatException... it was another rabbit hole).

But, without too much trouble, I was able to get a REGEDIT process fired off during installation to correctly import the registry values for the license, so I'm not going to spend any more time investigating.

Thanks again for your time!

Please Log in or Create an account to join the conversation.

09 Jan 2018 17:27 #5838 by support
I do not see any issue in QuickOPC in this respect. The values and their types in the registry are meant to be identical in both 32-bit and 64-bit parts. We have used these QWORD-s, in 32-bit registry, long before the software even supported 64-bit systems or ran on them.

The fact that the Windows Installer has an issue with it is new to me, but other installers appear to work fine in this respect.

Please Log in or Create an account to join the conversation.

09 Jan 2018 17:07 #5837 by jgreg311
When I mentioned that it's running as a service previously, I was talking about my (client) application.
To fix my issue, I set the OPC Server to run as a service.

I'll try calling the REGEDIT process to import .reg files during the install. I think this might mean we'll have .reg files sitting out in the installation folder, but I guess that's unavoidable.

I'm not positive, but I think there might be an issue in QuickOPC's validation of licenses when the application using QuickOPC is 32-bit. Let me try to explain:

When the (32bit application) installer runs and inserts the registry keys, it's causing the QWORD values ("NotAfter", "NotBefore", and "ReleaseDateCovered") under WoW6432Node to be added to the registry as binary values rather than QWORD. This is because QWORD is a 64bit value.

Correct me if I'm wrong, but my understanding is that the registry entry WoW6432Node is the view of the registry for a 32bit application on a 64bit system. Therefore, it doesn't make sense to require that these three registry values be QWORDs for license validation.

Of course I don't know how the license validation is occurring, but maybe the 32bit application is reading the (32bit) registry values and passing them to a 64bit license validation application?

When I load the license through the License Manager to correct the registry, it sets those three values to be QWORDs under WoW6432Node. I'm confused as to why Windows even allows 64bit values under the 32bit view of the registry.

Please Log in or Create an account to join the conversation.

09 Jan 2018 07:25 #5834 by support
Thank you for update. I am glad it works. I was under impression that the server was set to run as a service already.

A possible workaround for the Windows Installer issue would be to export the license to a .REG file (or separate .REG files for 32- and 64-bit parts), and then have the Windows Installer call the REGEDIT to import it. And a reverse step for uninstallation.

Best regards

Please Log in or Create an account to join the conversation.

08 Jan 2018 17:11 #5831 by jgreg311
Just wanted to update that I was able to get my connectivity issues resolved.

I don't know much about the OPC software on the server side, but I was able to find where you can have RSLinx start as a service. I changed it to start as a service, and it seems to work fine now. I don't have the desire or time to figure out which setting was tripping me up before, but it still confuses me.

Now I just have to figure out why the Microsoft Visual Studio installer project is messing up the registry.
After installing a new version of our application, we're getting the "invalid license" error after 30 minutes. I've done some comparisons, and it looks like Visual Studio is converting the QWORD values to BINARY for some reason - but only under Wow6432Node.

Please Log in or Create an account to join the conversation.

03 Jan 2018 17:40 #5802 by support
I am afraid that I cannot help much further here. The intent of my suggestion was to remove the element of unpredictability which is in settings like "Launching user" or "Interactive User" - because it cannot be guaranteed that they are always the same; and, you were getting an error that was unpredictable in this way.

So I still believe that the recommended setting in better in principle and may even be a solution to the issue; but there is something that prevents it from working. Is the account you have used the same as the account under which the service is running? It Is the service pre-started ("Automatic" in the Service Manager) or is it DCOM that starts it ("Manual" in Service Manager)? If it is being started by DCOM, can you pre-start it instead? Or, can you log in as that user configured in DCOMCNFG, and test whether that user can actually start the service? (because it looks like that DCOM has problem starting it).

The following user(s) said Thank You: jgreg311

Please Log in or Create an account to join the conversation.

03 Jan 2018 15:44 #5800 by jgreg311
I configured both OpcEnum and RSLinx to run as a specific user in the DCOM Config, and now I'm getting the following error:

Exception Type: OpcLabs.EasyOpc.OperationModel.OpcException
Exception Message: An OPC operation failure with error code -2146959355 (0x80080005) occurred, originating from 'OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient'. The inner exception contains details about the problem.
Inner Exception Type: System.Runtime.InteropServices.COMException
Inner Exception Message: Server execution failed

I tried a couple of different admin users, getting this exception each time.

Could I be missing some kind of configuration on the client side in code? I'm setting UseCustomSecurity to false, but could there be something else?

Please Log in or Create an account to join the conversation.

03 Jan 2018 06:46 #5789 by support
Although I do not know for sure where the error is coming from, I would certainly recommend against using the "Interactive user" setting. Of the options available, the only really practical with OPC is choosing a specific user account and type it in, together with its password. There is always a danger that "Interactive user" or "Launching user" end up trying to run the server under a wrong identity, which seems to be what the error message indicates.

This applies to both the OPC server itself, and OPCEnum.

Please Log in or Create an account to join the conversation.

02 Jan 2018 21:51 #5788 by jgreg311
Note that I'm also setting the static property:
EasyDAClient.SharedParameters.ClientParameters.UseCustomSecurity = false;

before creating an instance of the EasyDAClient.

Please Log in or Create an account to join the conversation.

02 Jan 2018 21:49 #5787 by jgreg311
Thanks for the quick response!

Identity is set to "The interactive user" (and under General, Authentication Level is "None").

One weird thing is that I'm not 100% positive of the server under DCOM Config. The customer doesn't know anything about their setup, and it'd require getting their vendor involved, which would not be easy (or cheap). I know it's Rockwell's "RSLinx Remote OPC Server", but the closest thing listed is "RSLinx", so I'm assuming that's it. I've done some searching online, and it sounds like it is.

OpcEnum is configured the same as RSLinx.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.222 seconds


 Recommend this on Google