Bugs
0
Fixed
OpenICE Demo-apps on WinXP (32 bits)
Hi Jeff,
Using your advice, I've been able to build my own cable to connect with a Philips MP70 monitor, and with a few modifications to AbstractDevice.java, I've been able to build my own version in Windows 7 that can record waveform data to a csv file. (Thank you for your help!)
However, I need to deploy my code on a Windows XP (32 bit) machine. I run into the following error whenever I try to run ICE_Device_Interface on WinXP (for example, one of the simulated waveforms):
2015-03-20 12:38:42,078 | WARN | Unable to load native library nddscore | com.rti.dds | main
java.lang.UnsatisfiedLinkError: mdPNP\demo-apps-0.5.0\demo-apps-0.5.0\bin\.nddshome\lib\i86Win32jdk\nddscore.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at com.rti.dds.util.NativeInterface.extractAndLoad(NativeInterface.java:482)
at com.rti.dds.util.NativeInterface.loadNativeLibrary(NativeInterface.java:172)
at com.rti.dds.util.NativeInterface.loadNativeLibraries(NativeInterface.java:139)
at com.rti.dds.domain.DomainParticipantFactory.<clinit>(Unknown Source)
at org.mdpnp.apps.testapp.RtConfig.loadAndSetIceQos(RtConfig.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:591)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1111)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1006)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:504)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:302)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:298)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:762)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:757)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
at org.mdpnp.apps.testapp.Configuration.createContext(Configuration.java:147)
at org.mdpnp.apps.testapp.DeviceAdapter$DeviceAdapterCommand.execute(DeviceAdapter.java:65)
at org.mdpnp.apps.testapp.Main.main(Main.java:51)
This occurs both with my version, and when running the 0.5 code downloaded from sourceforge. When I look in .nddshome, the i86Win32jdk directory only contains the nddscore.dll.manifest file, but none of the other ndds* files are present. I do have the Microsoft Visual C++ 2005 ATL Redistributable installed on the target machine. I have tried manually copying the needed files over, but the .nddshome directory is cleared at runtime.
Do you have any ideas what might be causing this error? If I needed to regenerate the nddsjava-5.1-mdpnp.jar file, how could I do so? (I have also tried to install the RTI packages on my development machine, if that helps.)
Thanks!
Regards,
Nathan
Using your advice, I've been able to build my own cable to connect with a Philips MP70 monitor, and with a few modifications to AbstractDevice.java, I've been able to build my own version in Windows 7 that can record waveform data to a csv file. (Thank you for your help!)
However, I need to deploy my code on a Windows XP (32 bit) machine. I run into the following error whenever I try to run ICE_Device_Interface on WinXP (for example, one of the simulated waveforms):
2015-03-20 12:38:42,078 | WARN | Unable to load native library nddscore | com.rti.dds | main
java.lang.UnsatisfiedLinkError: mdPNP\demo-apps-0.5.0\demo-apps-0.5.0\bin\.nddshome\lib\i86Win32jdk\nddscore.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at com.rti.dds.util.NativeInterface.extractAndLoad(NativeInterface.java:482)
at com.rti.dds.util.NativeInterface.loadNativeLibrary(NativeInterface.java:172)
at com.rti.dds.util.NativeInterface.loadNativeLibraries(NativeInterface.java:139)
at com.rti.dds.domain.DomainParticipantFactory.<clinit>(Unknown Source)
at org.mdpnp.apps.testapp.RtConfig.loadAndSetIceQos(RtConfig.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:591)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1111)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1006)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:504)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:302)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:298)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:762)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:757)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
at org.mdpnp.apps.testapp.Configuration.createContext(Configuration.java:147)
at org.mdpnp.apps.testapp.DeviceAdapter$DeviceAdapterCommand.execute(DeviceAdapter.java:65)
at org.mdpnp.apps.testapp.Main.main(Main.java:51)
This occurs both with my version, and when running the 0.5 code downloaded from sourceforge. When I look in .nddshome, the i86Win32jdk directory only contains the nddscore.dll.manifest file, but none of the other ndds* files are present. I do have the Microsoft Visual C++ 2005 ATL Redistributable installed on the target machine. I have tried manually copying the needed files over, but the .nddshome directory is cleared at runtime.
Do you have any ideas what might be causing this error? If I needed to regenerate the nddsjava-5.1-mdpnp.jar file, how could I do so? (I have also tried to install the RTI packages on my development machine, if that helps.)
Thanks!
Regards,
Nathan
Customer support service by UserEcho
You've already covered a lot of bases but there are a few more avenues you can explore to help debug the problem. It's true we no longer routinely test on Windows XP but I just downloaded and ran 0.5.0 on my WinXP VM so it ought to be possible.
Since the inception of the project a number of Windows users have had issues with linking in the DLLs due to the dependency on MSVCR80.DLL from the Visual C++ 2005 redistributable package. You say you've already got those libraries installed so the best way we've found to debug failure to link a DLL at runtime is the old reliable depends.exe. If you open nddsjava.dll in depends.exe it ought to tell you in a hurry what dependencies are not locatable on your system.
Which brings up the other point you mentioned. The default behavior of the app is to delete extracted libraries when the process ends as best it can to be 'polite' which may explain why you are not seeing the DLLs. If you have a JDK installed you can extract the libraries from lib/nddsjava-5.1-mdpnp-000006.jar with
and browse to
Alternatively I believe most file compression utilities (winzip and the like) ought to be able to extract the contents of the jar as well.
Let me know what the dependency walk finds. I'd be surprised if it's not a failure to find MSVCR80.DLL but if all the dependencies are found we can start to look for other runtime irregularities.
Thank you
Jeff Plourde
Dependency walker confirmed that MSCVR80.dll was the culprit. I downloaded the Visual C++ redistributable from your link, installed it, and now the program runs. Thank you! Interestingly, that is the 4th version of the Visual C++ 2005 x86 redistributable that I tried installing on the target machine, so apparently this fix is version sensitive.
Again, many thanks for your help!
Regards,
Nathan
You're definitely not alone. I believe they used to call it "DLL Hell", if you'll pardon the expression. Unfortunately the community edition of RTI DDS does not include an installer that would ensure that these necessary redistributables get installed which I think would be the best practice deployment on windows. We'll try to document the need for that particular version more clearly. A pure java solution would be ideal.
Glad it's working now and please let us know if you have any more issues.
Cheers!
Jeff