Access denied error when starting DIAdem from LabVIEW

[cbauer]

We are using the DIAdem Connectivity Toolkit in our application.  Our application starts a DIAdem session to handle querying and datasheet creation.  On a recent installation at a customer, our application was not able to communicate with DIAdem, i.e. we get an Access Denied error when our application tries to start up DIAdem.

The location of the error is in the DIAdem Open Connection.vi.  I believe it is when the Automation Open is run.

Is there some system setting that could be blocking communication between the two, i.e. ActiveX setting, etc?  If so, where could we control these settings from?

[DRock]

Hey cbauer,

A few followup questions for you...

• Does this error message throw you any error code? 
  
• What versions of LabVIEW, DIAdem and the Toolkit are you running? 
  
• Is that toolkit installed on your customer's machine?  
  
• Are you running in the development or run-time environment?
  
• Are you closing your references to DIAdem using the DIAdem Close Reference VI?
  
• Do you still receive the same error if your application merely consist of a DIAdem Open Reference VI and a DIAdem Close Reference VI (and nothing else)?
• Have you tried repairing the installation(s) of your software?
  

Thanks, cbauer - the answers to these questions will help me determine how to best proceed from here.

[kennymolc]

Hello Derrick,

While cBauer is away from the office, I will be working with this case on his behalf.  I will try to answer your questions as best I can to determine what might be causing this failure.

1. The error which we encounter is an "Access Denied" error (as stated above).  I am currently investigating the error code, and will update this post accordingly when I have it.

2. Our application is a built (.exe) application using LabVIEW 8.5 and DIAdem 10.2

3. We do not install the toolkit directly on the customers machine as this is a built application.  We install the FULL LabVIEW 8.5 Runtime engine, as well as a licensed copy of the DIAdem 10.2 Basic edition.

4. The error occurs in run-time environment at a customer site.  We have been unable to duplicate the error in development.

5. We're using the "DIAdem Open Connection.vi" from the DIAdem.dll library to initialize the connection (this is the VI which appears to be producing the error via the "Automation Open" node), and we're using the "DIAdem Close Reference.vi" from the same library to close the reference.

6. I will instrument a simple application which performs these tasks and post the results when we have tried this operation.

7. I am unsure whether the repair operation has been attempted.  I will verify this behavior and again post the results to this forum.


Thank you for your help.  Please let me know if you require additional information.  Hopefully we can discover a solution to our problem.



Ken

[kennymolc]

Still struggling to discover the cause of this problem:

The error code being returned is -2147024891 (General Access Denied), and appears to be thrown by the "DIAdem Open Connection.vi" from the DIAdem toolkit.  I'm speculating that this may have something to do with the "DIAdem TOCommand" DCOM object, though we've gone through the dcomcnfg properties and verified that the access permissions on this object enable access.

Any new thoughts?

[kennymolc]

Still hunting.

The error code -2147024891 indicates a Windows General Access Denied error.  I tried to use the Windows dcomcnfg tool to alter the permissions on the TOCommand object to allow full access, but I still continue to get the access violation error.  I wrote a quick diagnostics tool in LabVIEW 8.5 which uses the "Automation Open" module to open a reference to the TOcommand object and the TODataSheet object (this code was copied verbatim from the "DIAdem Open Connection.vi" included with the DIAdem toolkit).  Both attempts produce the same error code listed above.

It appears that the calls to the DCOM component are never received, as DIAdem does not appear to start at all.  This makes sense, but I wanted to note it for future reference.

Also tried to run a DIAdem installation repair which produced an error 1601 (multiple times) before completing ... though it did not appear to fix any of the problems we're experiencing.

I'll continue looking, but any advice is welcome ... anyone ... Bueller?

[DRock]

Hey DarkCloud,

I have attached a *.txt file to this post because *.vbs extensions are not allowed on the forums.

Please rename this *.txt file to be of *.vbs extension and then try running the *.vbs file from Windows Explorer on your deployment machine.   Placing it on the desktop and double-clicking from there will be sufficient.  If everything goes according to "plan," then DIAdem will launch on the machine and display a message box saying "Hello." 

Please re-post what happens when you attempt this test (this test takes LabVIEW out of the picture).

Were any details/documentation (description, etc.) given when the 1601 error was thrown during DIAdem Installation Repair? 

[kennymolc]

DRock,

Thanks for putting together the vbscript code.  I had my customer try to run the code on his machine, which resulted in a Windows Script Host error with the following information:

Line: 1
Char: 1
Error: Permission denied: 'CreateObject'
Code: 800A0046
Source: Microsoft VBScript runtime error

So it doesn't look like the problem is limited to LabVIEW (though this is a different error code than the one above ... I will see if I can determine what the difference is between the error codes).

Also, the 1601 error which we encountered during the repair installation was not very specific.  The installer ran to completion, but several dialogs with the message "Error 1601 occured" were displayed during the repair operation (this did not seem to cause an install failure, however I would be willing to bet that those components which caused this error were not repaired or replaced).

[DRock]

Hey DarkCloud,

Now that we've taken LabVIEW out of the picture, let's try taking DIAdem out of the picture, too - in other words, are we having trouble connecting to DIAdem's ActiveX Server, or any ActiveX Server?

Why don't you try modifying the same script to connect to an ADO Connection Object:

Set ADO = CreateObject("ADODB.Connection")

Let us know how this works!

[kennymolc]

DRock,

I rewrote your script to open the ADODB connection object as you suggested, and the script ran without errors to completion.  The script contained the following lines of code:

Set ToCommand = CreateObject("ADODB.Connection")
msgBox("Still executing script, no error encountered")
Set ToCommand = Nothing

Definetely not the same behavior we saw with the ToCommand object in the previous script.  So does this limit my problems to the DIAdem ToCommand object?

FYI: I also went through the users local computer policy to verify that the DCOM components are not being blocked due to a permissions problem.  To make sure of this, I enabled full permissions on both DCOM policies located under the Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > DCOM:* (NOTE: there were two policies listed for DCOM, so I enabled full access for both).  This did not change the behavior of the ToCommand.vbs script.  I wondered if maybe their domain group policy could be creating problems for us, however I would assume the ADODB connection would have been a failure as well if this were the case.

I'm at a loss as to what to do next, so any suggestions are welcome.  Thanks for your help.

- Ken

[kennymolc]

Hello DRock,

After verifying that the ADODB.Connection test above would work correctly, I decided to run a few tests on a virtual machine in my lab.  In doing so I discovered the following:

1. If I set the local group policy for the Security Option "DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax" to deny either Local Launch or Local Activation permissions to all users, I can reproduce the error -2147024891 we've been encountering on the customer machine.
2. In addition, with the same settings disabled, I am still able to successfully create an object for the ADODB.Connection class as mentioned above.

This information leads me to believe that there must be a domain policy overriding the local machine policy settings specified above.  I don't know if you are familiar with group policy (I know I'm not), but do you have any suggestions as to what domain policy could possibly create this conflict?

Is there anything else that may be domain-driven that could possibly cause this behavior?

Thanks,
- Ken