Remote Server Error

[Dan R]

Hello,
When trying to run the TestRemote.exe application on the computer attached to our instrument, I get the following error:
Handle value is zero. JEOL 8900/8200/8500/8230/8530 driver or emulator may not be loaded.

When I run the application on my laptop, I do not get this error. Any ideas what this means? I've tried uninstalling and installing a few times to no avail.

-Dan

[John Donovan]

Hi Dan,
I'm not sure why.

Maybe try running the TestRemote app "as administrator" and see what that does.

[Dan R]

John-
This is the error you get when you forget to add the JeolEIKS.ini and .dll files into the SysWOW64 folder where Remote.exe resides. I believe it is a symptom of doing too many things at once.
-Dan

Edit by John: Yes, the JEOL EIKS interface requires separate copies of these EIKS files to make simultaneous connections to the instrument.

Glad you were able to figure it out!

[pgopon]

Has anyone gotten the remote server to work on the most recent version of PfEPMA.  I tried running my code again and I keep getting an error message when I try to connect to the remote server.  I get the same error message when I run the remote server test by itself.

Error Message:
InitINIHardware
Interface Type keyword is no longer supported in C:\Probe Software\Probe for EPMA\PROBEWIN.INI

We haven't changed our Probewin.ini file since we last successfully ran the remote server, so not sure what the error means. 

Thanks,

phil

[John Donovan]

Hi Phil,
It means that you are trying to run the new 10.x version of Remote COM server on your SX50 instrument.

Beginning with v. 10.x of the software, the Advanced Microbeam, TRACOR, Sesame and SX50/51 instrument interfaces are no longer supported.

Therefore you must download the 9.x version of Remote Server and install and use that instead if you are trying to connect to the SX50/51 interface.

[pgopon]

Ok, thanks.  I can't find an old version of the remote server.  The one I download from you website is v10 and on your ftp site I can only download v9 for Windows 7, which does not install.

phil

[Probeman]

Ok, thanks.  I can't find an old version of the remote server.  The one I download from you website is v10 and on your ftp site I can only download v9 for Windows 7, which does not install.

Yes, the v9 Remote.msi in the Win7 folder is what you want.  The installer doesn't work?  What is the error?

You can also download the REMOTE_UPDATE-E.ZIP file from the same ftp folder and copy the files manually for updating if Remote was previously installed, but you should try the Remote.msi first for sure.

[pgopon]

No error on the installer.  I download it to the PfEPMA folder, try to run the .msi file and it thinks for a seconds, stops and then the .msi file is gone.  I have tried re-downloading it 4 or 5 times and the same thing happens every time.  Is it a 32-bit issue?

We had to wipe the probe computer a while back, so unfortunately we don't have a previously installed version.

phil

[Probeman]

The msi file is deleted?  How does that happen?   What OS are you using?

I just tried a test on my SX50 and installed the Remote.msi downloaded from the whitewater ftp folder.  It installed fine and ran fine using TestRemote.exe under Windows XP.

[pgopon]

Got it figured out, it was an issue with the Windows XP installer.  The Windows installer could not be accessed by the .msi file (or any other installer for that matter).  Here is a link to fix the issue if anyone runs into this in the future.

http://support.microsoft.com/kb/315353

cheers,

phil

[John Donovan]

John-
This is the error you get when you forget to add the JeolEIKS.ini and .dll files into the SysWOW64 folder where Remote.exe resides. I believe it is a symptom of doing too many things at once.
-Dan

Edit by John: Yes, the JEOL EIKS interface requires separate copies of these EIKS files to make simultaneous connections to the instrument.

Glad you were able to figure it out!

JEOL 8230/8530 users: note that because the Remote.exe COM server (starting with version 12.2.8 ) is now installed into the "Common Files" folder (usually C:\Program Files (x86)\Common Files\Probe Software), one will now need to copy the JEOL EIKS files:

eiksJSample.exe
jeoleiks.dll
JeolEIKS.ini
mfc100.dll
msvcr100.dll

from the Probe for EPMA application folder (usually C:\Program Files (x86)\Probe Software\Probe for EPMA), to the Common Files folder (usually C:\Program Files (x86)\Common Files\Probe Software).

Remember, when the Remote.msi installer is run the first time (or any subsequent time for updating), one must generally run the Remote.exe COM server "as admin" by right clicking the app and selecting "Run as administrator" as seen here:



Once this operation is performed the Remote.exe COM server is registered in the system and you can subsequently run the provided sample app (TestRemote.exe) and Excel (for the provided macro examples) as normal applications. This example app and example Excel macros are found in the Remote application folder (usually C:\Program Files (x86)\Probe Software\Remote).

Again remember also (this applies to *all* instrument interfaces), that one should not run the provided Excel spreadsheet macro examples directly from the Remote application folder as they cannot be saved there, because all application folders are marked "read only" by Windows.  So all .xls and .xlsm files should be copied to a writable folder of your choosing and run from there instead.

[Probeman]

It's probably worth mentioning that if the Windows UAC control is set to "Never Notify", then when the TestRemote app is run the first time to set the system parameters, the request for the user to enter the admin password is not shown and the DCOM connection will fail with a general DCOM error.

Because the Remote.exe is a self registering COM application, it needs to set certain system parameters the first time it is run.  So generally one simply right clicks the app, and selects Run As Administrator.  But as noted above, if the User Access Control is set to "never notify", it won't prompt you and the app simply returns an error because it can't set these parameters.

Here is how to change the User Access Control on your Windows computer (this is specifically how to set the UAC to "never notify", but we need to set it to "notify" so we get prompted for the admin password):

Issue:
How to turn off User Account Control (UAC) in Windows in order to troubleshoot a software issue or to allow a program to run better, especially when it interacts with other software.
Causes:
Applications can get a timeout message.
Solution:
UAC is a Microsoft security tool that helps prevent intrusion of malicious software. It is not full-fledged anti-malware or an antivirus, but it does notify of changes that are about to be made to the computer.

For troubleshooting application problems, temporarily disabling UAC may help pinpoint the problem or relieve the issue.  Be sure to restore this security setting as soon as the issue is resolved.

To turn off UAC:
Click the Start menu. In the search field type UAC.
Click "Change User Account Control settings."
In the window that comes up, move the slider down to "Never Notify."
Click OK and then restart the computer.
Note: UAC is designed by Microsoft. Please contact Mircosoft Support for more details and permissions about UAC.

https://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/How-to-turn-off-User-Account-Control-in-Windows.html

Once the system parameters have been properly set by the Remote.exe COM application, one can turn the User Access Control again to Never Notify, but I would just leave it at the default setting myself.

[John Donovan]

Under Windows 10, there are several steps that may be required to get TestRemote to run properly the first time.  The error seen is usually "ActiveX: can't create object".  This error occurs because the first time that the Remote.exe ActiveX server runs (when initiated by TestRemote), it needs to register itself as an ActiveX server with the system registry.

Once you get through this system registration, the TestRemote application (and other apps that call the Remote.exe ActiveX server) can be run as normal apps.

What we find is that on Windows 10 (and probably also Windows 7), after we run the Remote.msi installer for the first time (or after installing a new version of Remote- please note that uninstalling Remote is only necessary if your current version of Remote is from April 2018 or earlier), we need to:

1. Use Explorer to find the TestRemote.exe application, which is in the C:\Program Files (x86)\Probe Software\Remote folder. 

2. Then right click the TestRemote.exe file, then click the Properties menu as seen here:



3. Then click the Compatibility tab.  Then in the Compatibility Mode frame, check the "Run this program in compatibility mode for:" checkbox, and select the Windows XP (Service Pack 3) list item.

4. Then in the Privilege Level frame check the "Run this program as an administrator" checkbox, and click Apply, then OK to close the window.

It should look like this before you click OK:



5. Then launch the TestRemote.exe application by double-clicking it.  The TestRemote app will load after 30 seconds or so, and the Remote server window should appear as seen here (in the lower right):



Now that the Remote ActiveX server has properly registered itself, you can put things back to normal:

1. Again right click the TestRemote.exe app and click Properties, then the Compatibility tab.

2. Then uncheck both the compatibility mode and run as admin checkboxes and click Apply and OK.

3. Now you can run TestRemote as a normal application by simply double-clicking it, and it should launch as before, but without the need for running with the compatibility and admin modes.

Our apologies for all this, but in the more recent Microsoft operating systems, Microsoft is trying to protect the system registry from unauthorized modifications.

[Ryan McAleer]

Hi John,

I am making a stab at using the REMOTE application and have run into the "Active-X component can't create object" error.  I first tried opening the TestRemote.exe from the Programfiles path and got the error.  Then I followed the instructions on your 12/15/18 post [set to REMOTE to run in compatibility mode (SP3) and run TestRemote.exe as administrator] but  still receive the same error.  I also updated to the latest version of Probe for EPMA (I had last done this is October), but this didn't change anything.

Any advice on what else I might try?

I am running on Windows 7 Service Pack 1.

I did also check the User Account settings and they are on the default notifications settings (not "Never Notify").

Thanks,
Ryan

[Ryan McAleer]

Update:  I got it working. I didn't see that you had to first go to the Remote.exe in  "C:\Program Files (x86)\Common Files\Probe Software\remote.exe" and set to run on SP3 and Run as Administrator. I had changed the setting for the "C:\Program Files (x86)\Probe Software\Remote\TestRemote.exe".  Anyway, after changing those settings the Remote.exe opens after ~30 seconds.  I was then able to change the settings back to normal and the Remote.exe still worked.

Thanks!