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
- Connections, Reconnections, COM/DCOM
- Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
07 Aug 2014 09:23 #2136
by support
Replied by support on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
Yes, a good portion of 32 vs. 64 bit problem will manifest itself as "Invalid Class String", because the registry has some common parts, some 32-bit specific parts, some 64-bit specific parts, and then some synchronized and "reflected" parts, which is done by Windows to hold the 32/64 bit worlds together. Normally, COM/DCOM does good job in hiding the 32/64 bit differences and making it all work transparent. But OPC does some extra things - it has the "server browser" (OPCEnum) component, and rules for looking up info in the registry, and if either the server, or the client, or OPCEnum, does something that's not fully correct, the code may end up "not seeing" the server registration info, which results in "Invalid Class String".
If you are just after making things work, you can consider replacing the use of symbolic ProgIDs of the target OPC servers in the client code by their corresponding numerical CLSIDs. In this case the ServerClass string passed to QuickOPC methods must look like a CLSID enclosed in curly brackets ("{...}"). Doing so will bypass the extra internal step needed to transform the ProgID to CLSID, eliminating some possible error situations.
If you are just after making things work, you can consider replacing the use of symbolic ProgIDs of the target OPC servers in the client code by their corresponding numerical CLSIDs. In this case the ServerClass string passed to QuickOPC methods must look like a CLSID enclosed in curly brackets ("{...}"). Doing so will bypass the extra internal step needed to transform the ProgID to CLSID, eliminating some possible error situations.
Please Log in or Create an account to join the conversation.
05 Aug 2014 19:24 #2129
by mattbbpl
Replied by mattbbpl on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
I just wanted to reply quickly to provide an update.
Whatever RSLinx is doing behind the scenes is definitely different.
We were able to resolve the issue on a test box using a forced 32-bit compilation on the EXE and associated DLLs, but that uses a Matrikon/Graybox simulator. The same solution on the RSLinx box continues to exhibit the same behavior.
[For anyone else reading this, I will mention that one trap we fell into is that providing the incorrect OPC Server Name will result in the same error message as a 32-bit/64-bit mismatch will, so just beware of that as it can make your results seem more inconsistent than they are.]
Due to some technicalities, I'm able to make little further progress with this box and I'm exerting some political will to get a better test VM - One that I can modify to an extent so I can try to get the same issues on it as I'm seeing in the production environment.
I will report back once I have further information so that others can benefit from whatever I gain out of this.
Thank you for your assistance to this point. I appreciate it.
Whatever RSLinx is doing behind the scenes is definitely different.
We were able to resolve the issue on a test box using a forced 32-bit compilation on the EXE and associated DLLs, but that uses a Matrikon/Graybox simulator. The same solution on the RSLinx box continues to exhibit the same behavior.
[For anyone else reading this, I will mention that one trap we fell into is that providing the incorrect OPC Server Name will result in the same error message as a 32-bit/64-bit mismatch will, so just beware of that as it can make your results seem more inconsistent than they are.]
Due to some technicalities, I'm able to make little further progress with this box and I'm exerting some political will to get a better test VM - One that I can modify to an extent so I can try to get the same issues on it as I'm seeing in the production environment.
I will report back once I have further information so that others can benefit from whatever I gain out of this.
Thank you for your assistance to this point. I appreciate it.
Please Log in or Create an account to join the conversation.
24 Jul 2014 07:49 #2098
by support
Replied by support on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
In additional to an already complicated issues with 64-bit OS and (mostly 32-bit) OPC servers, the fact that it is RSLinx makes things more complex. There are some issues with this server (Google for them...).
One of them can be directly related to this. At least some of the RSLinx servers are in-process servers - which is not wrong per se, but it is very unusual in the OPC world, meaning that not all tools are ready for it.
Second, even if the in-process works in 32-bit world, the implementing DLL is 32-bit only, and therefore can NOT run in-process within a 64-bit process. (D)COM is supposed to resolve this transparently by loading it into a surrogate 32-bit process and exposing it in an out-of-process way, but with it come configuration and permission-related headaches, and more issues with normal OPC tools "assumptions".
In more than on instance, we have also seen a situation where the RSLinx OPC server has been "recognized" by the 64-bit client app, but because it has some internal checks whether it's being instantiated as an in-process server, it refused to run due to licensing issues (it required a different license, because for out-of-process it assumes a remote usage).
And there are more.
But since most of it has to do with accessing the 32-bit server from a 64-bit process, in case you are compiling your service for AnyCPU or x64, can you build it for x86 (i.e. 32-bit process) to see if it resolves the issue?
One of them can be directly related to this. At least some of the RSLinx servers are in-process servers - which is not wrong per se, but it is very unusual in the OPC world, meaning that not all tools are ready for it.
Second, even if the in-process works in 32-bit world, the implementing DLL is 32-bit only, and therefore can NOT run in-process within a 64-bit process. (D)COM is supposed to resolve this transparently by loading it into a surrogate 32-bit process and exposing it in an out-of-process way, but with it come configuration and permission-related headaches, and more issues with normal OPC tools "assumptions".
In more than on instance, we have also seen a situation where the RSLinx OPC server has been "recognized" by the 64-bit client app, but because it has some internal checks whether it's being instantiated as an in-process server, it refused to run due to licensing issues (it required a different license, because for out-of-process it assumes a remote usage).
And there are more.
But since most of it has to do with accessing the 32-bit server from a 64-bit process, in case you are compiling your service for AnyCPU or x64, can you build it for x86 (i.e. 32-bit process) to see if it resolves the issue?
Please Log in or Create an account to join the conversation.
23 Jul 2014 14:19 #2094
by mattbbpl
Replied by mattbbpl on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
OK, I follow.
We're actually hooking into the easyDAClient.ItemChanged event and then issuing a SubscribeMultipleItems call.
The abbreviated code is similar to:
[Begin Loop]
opcGroupList.Add(new OpcLabs.EasyOpc.DataAccess.DAItemGroupArguments(productLine.AutomatedOPCServer,
productLine.AutomatedOPCClass, productLine.AutomatedOPCReprintTag, 100, null));
[End Loop]
...
easyDAClient.ItemChanged += new EventHandler<OpcLabs.EasyOpc.DataAccess.EasyDAItemChangedEventArgs>
(easyDAClient_ItemChanged);
easyDAClient.SubscribeMultipleItems(opcGroupList.ToArray());
But I believe the values you're looking for are the AutomatedOPCClass values. In each item above, that value is "RSLinx Remote OPC Server". This corresponds to the "RSLinx Classic 3.60.00 CPR 9 SR 6" installation.
We're actually hooking into the easyDAClient.ItemChanged event and then issuing a SubscribeMultipleItems call.
The abbreviated code is similar to:
[Begin Loop]
opcGroupList.Add(new OpcLabs.EasyOpc.DataAccess.DAItemGroupArguments(productLine.AutomatedOPCServer,
productLine.AutomatedOPCClass, productLine.AutomatedOPCReprintTag, 100, null));
[End Loop]
...
easyDAClient.ItemChanged += new EventHandler<OpcLabs.EasyOpc.DataAccess.EasyDAItemChangedEventArgs>
(easyDAClient_ItemChanged);
easyDAClient.SubscribeMultipleItems(opcGroupList.ToArray());
But I believe the values you're looking for are the AutomatedOPCClass values. In each item above, that value is "RSLinx Remote OPC Server". This corresponds to the "RSLinx Classic 3.60.00 CPR 9 SR 6" installation.
Please Log in or Create an account to join the conversation.
23 Jul 2014 14:06 #2092
by support
Replied by support on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
Your code is most likely calling methods like EasyDAClient.ReadXXXX, EasyDAClient.WriteXXXX, EasyDACient.SubscribeXXXX (XXXX may vary).
These methods accepts arguments that tell them which computer to connect to, and which OPC server on that computer to connect to. Usually the OPC Server is identified using a string containing it's so called ProgID. So it would be the ProgID that is of interest to me. You should be able to figure it out in the code, or using a debugger. If you post a piece of code with some of the above calls, I will then be ale to tell you precisely which information I am looking for.
Normally, you would also know you by some other means what is the purpose of your app, and who is the vendor (or vendors) of the OPC servers you are working with, and what are their product names and ProgIDs they use. The whole point of our QuickOPC component is to give the developer an easy way to communicate with OPC Servers, so without knowing them the whole point is lost.
These methods accepts arguments that tell them which computer to connect to, and which OPC server on that computer to connect to. Usually the OPC Server is identified using a string containing it's so called ProgID. So it would be the ProgID that is of interest to me. You should be able to figure it out in the code, or using a debugger. If you post a piece of code with some of the above calls, I will then be ale to tell you precisely which information I am looking for.
Normally, you would also know you by some other means what is the purpose of your app, and who is the vendor (or vendors) of the OPC servers you are working with, and what are their product names and ProgIDs they use. The whole point of our QuickOPC component is to give the developer an easy way to communicate with OPC Servers, so without knowing them the whole point is lost.
Please Log in or Create an account to join the conversation.
23 Jul 2014 13:08 #2089
by mattbbpl
Replied by mattbbpl on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
I'm sorry, I'm not sure what you mean by, "What OPC Server are you connecting to?". I'm using the x64 bit version of the runtime, if that helps. We're relying directly on references to some third party DLLs named OpcLabs.EasyOpcClassic.dll, OpcLabs.EasyOpcClassicInternal.dll, and OpcLabs.BaseLib.dll.
The service process runs as a 32 bit process. After recompiling, I've attempted with a 32 bit version and a 64 bit version, but both result in the same issue.
The service process runs as a 32 bit process. After recompiling, I've attempted with a 32 bit version and a 64 bit version, but both result in the same issue.
Please Log in or Create an account to join the conversation.
17 Jul 2014 09:34 #2084
by support
Replied by support on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
What OPC Server are you connecting to? Does that OPC server come with 32-bit and 64-bit version?
And, when you check it in Task Manager, does it run as 32-bit or 64-bit process?
We are almost certainly dealing with an issue related to 32/64 bits.
And, when you check it in Task Manager, does it run as 32-bit or 64-bit process?
We are almost certainly dealing with an issue related to 32/64 bits.
Please Log in or Create an account to join the conversation.
15 Jul 2014 12:32 - 15 Jul 2014 12:38 #2072
by mattbbpl
Replied by mattbbpl on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
Thank you for taking the time to respond.
I've actually tried two separate versions - The latest version of OPC Core Components (x64) from the OPC Foundation Web site and "OPC Core Components Redistributable (x64) 105.0" (3.00.10500) which existed on the server previously.
The OPCEnum.exe version is 1.10.105.1. It existed on the server previously and has been present during times when the other service is functioning correctly and when it's not. As such, I would lean towards it not being the cause of the issue although I can't rule it out as a role player in the situation.
I've actually tried two separate versions - The latest version of OPC Core Components (x64) from the OPC Foundation Web site and "OPC Core Components Redistributable (x64) 105.0" (3.00.10500) which existed on the server previously.
The OPCEnum.exe version is 1.10.105.1. It existed on the server previously and has been present during times when the other service is functioning correctly and when it's not. As such, I would lean towards it not being the cause of the issue although I can't rule it out as a role player in the situation.
Last edit: 15 Jul 2014 12:38 by mattbbpl. Reason: Found more precise version reference
Please Log in or Create an account to join the conversation.
15 Jul 2014 07:09 #2071
by support
Replied by support on topic Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
Hello,
are you using the latest version of OPC Core Components (x64) from the OPC Foundation Web site, or the version from our QuickOPC distribution, or something else? What is their full build number?
Note: Our component can enumerate the OPC servers directly form registry, or using OPCEnum (from the Core Components). A possible hypothesis is that the OPCEnum you are installing does not work well (older versions do not), therefore its absence can make the result better.
We also have flags inside the product to control how the server browsing is done.
are you using the latest version of OPC Core Components (x64) from the OPC Foundation Web site, or the version from our QuickOPC distribution, or something else? What is their full build number?
Note: Our component can enumerate the OPC servers directly form registry, or using OPCEnum (from the Core Components). A possible hypothesis is that the OPCEnum you are installing does not work well (older versions do not), therefore its absence can make the result better.
We also have flags inside the product to control how the server browsing is done.
Please Log in or Create an account to join the conversation.
14 Jul 2014 13:16 - 14 Jul 2014 14:50 #2070
by mattbbpl
Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64) was created by mattbbpl
Good day,
I've inherited a server which runs an OPC service that interfaces with the OPC Core Components 3.00 Redistributable (x86) runtime on a Windows Server 2003 OS. The service interfaces with the runtime primarily through the EasyDAClient.ItemChanged event. The service runs fine on this machine.
I have to deprecate this server in favor of a 64 bit Windows Server 2008 R2 machine. After installing the service and the OPC Core Components 3.00 Redistributable (x64), the service failed to start with the "Invalid Class Name" message. Debugging into the process reveals that the ItemChanged event's EasyDAItemChangedEventArgs.Exception object contains this exception, and the EasyDAItemChangedEventArgs.Vtq value is null.
Now for the fun stuff.
I installed the OPC Core Components 3.00 Redistributable (x86) onto the 2008 machine and the service still failed (as expected). I uninstalled the (x64) runtime, and the service succeeded with no errors. Reinstalling the (x64) runtime resulted in a failure again (with the same error message).
I'm building the service on a 64 bit machine using AnyCPU. The older version of the service was (reportedly) compiled on a 32-bit machine using AnyCPU, and reinstalling that version with the (x64) runtime works fine.
I've attempted to build the new version using the x86 setting (I have no choice but to compile on a 64 bit machine now), yet the didn't resolve the issue. Nor did attempting to override the 32-bit setting using Corflags.exe .
Does anyone know what's going on here and how this situation can be resolved? I might be in too deep to see the forest from the trees at this point.
Update: I performed a test whereby I recompiled the service with the x64 option and installed it on the 2008 server with the (x86) runtime installed, and it works correctly under that scenario. If I install the (x64) runtime (so that both the x86 and x64 versions are installed), the service then fails with the "Invalid Class Name" message. If I then remove the (x64) runtime so that only the (x86) runtime is present, the service succeeds. Then, if I uninstall that runtime (so that neither version of the runtime is installed) the service SILL SUCCEEDS. Thus, the cause of the issue (when compiled as a 64 bit process) seems to stem not from the ABSENCE of the necessary runtime, but the PRESENCE of the (x64) runtime which seems pretty odd to me.
I've inherited a server which runs an OPC service that interfaces with the OPC Core Components 3.00 Redistributable (x86) runtime on a Windows Server 2003 OS. The service interfaces with the runtime primarily through the EasyDAClient.ItemChanged event. The service runs fine on this machine.
I have to deprecate this server in favor of a 64 bit Windows Server 2008 R2 machine. After installing the service and the OPC Core Components 3.00 Redistributable (x64), the service failed to start with the "Invalid Class Name" message. Debugging into the process reveals that the ItemChanged event's EasyDAItemChangedEventArgs.Exception object contains this exception, and the EasyDAItemChangedEventArgs.Vtq value is null.
Now for the fun stuff.
I installed the OPC Core Components 3.00 Redistributable (x86) onto the 2008 machine and the service still failed (as expected). I uninstalled the (x64) runtime, and the service succeeded with no errors. Reinstalling the (x64) runtime resulted in a failure again (with the same error message).
I'm building the service on a 64 bit machine using AnyCPU. The older version of the service was (reportedly) compiled on a 32-bit machine using AnyCPU, and reinstalling that version with the (x64) runtime works fine.
I've attempted to build the new version using the x86 setting (I have no choice but to compile on a 64 bit machine now), yet the didn't resolve the issue. Nor did attempting to override the 32-bit setting using Corflags.exe .
Does anyone know what's going on here and how this situation can be resolved? I might be in too deep to see the forest from the trees at this point.
Update: I performed a test whereby I recompiled the service with the x64 option and installed it on the 2008 server with the (x86) runtime installed, and it works correctly under that scenario. If I install the (x64) runtime (so that both the x86 and x64 versions are installed), the service then fails with the "Invalid Class Name" message. If I then remove the (x64) runtime so that only the (x86) runtime is present, the service succeeds. Then, if I uninstall that runtime (so that neither version of the runtime is installed) the service SILL SUCCEEDS. Thus, the cause of the issue (when compiled as a 64 bit process) seems to stem not from the ABSENCE of the necessary runtime, but the PRESENCE of the (x64) runtime which seems pretty odd to me.
Last edit: 14 Jul 2014 14:50 by mattbbpl.
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Invalid Class String on Windows Server 2008 R2 Using OPC Core Components 3.00 Redistributable (x64)
Time to create page: 0.067 seconds