I have a windows application developed in Labview, it's recording acceleration data coming from accelerometers. On the system, we have a couple of NI9230 devices connected to NI9181 and NI9191 modules. So communication between devices is done over ethernet. It's working perfectly on all of our computers but one. On that specific machine, it causes a Windows error that I am unable to solve. The error recorded to Windows event log is;
Log Name: Application Source: Application Error Date: 10.05.2018 18:07:00 Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: DESKTOP-75KFKSS Description: Faulting application name: Acceleration Measurement and Logging.exe, version: 184.108.40.206, time stamp: 0x58ce9923 Faulting module name: NIlibeay32.dll, version: 220.127.116.11152, time stamp: 0x58b5d904 Exception code: 0xc0000005 Fault offset: 0x0000000000015323 Faulting process id: 0x830 Faulting application start time: 0x01d3e8707442310e Faulting application path: C:\Program Files\Acceleration Measurement and Logging\Acceleration Measurement and Logging.exe Faulting module path: C:\Program Files\National Instruments\Shared\nissl\NIlibeay32.dll Report Id: f3ece9d6-d549-49a5-96d4-e89693fe797d
I have already tried to uninstall and install everything related without luck and would appreciate if anyone could help me to solve this problem.
Solved! Go to Solution.
What does the error look like when you first see it, is it a pop up? If so, can you post that as well? What version of LabVIEW are you using?
According to this post that DLL has to do with OpenSSL. Maybe you need to install some web services toolkit?
The error is standard windows error pop-up which says "The program caused an error and will be closed". I don't have that specific computer with me but I can send it later.
I also noticed another strange thing, I can access both devices (9181 and 9191) throughout the NI MAX or Express DAQ screen and I can get sensor data. However, when I create the VI by using DAQ Express and try running it, Labview also closes with the same error. You can see the details below;
Log Name: Application Source: Application Error Date: 11.05.2018 18:17:22 Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: DESKTOP-75KFKSS Description: Faulting application name: LabVIEW.exe, version: 18.104.22.16806, time stamp: 0x58ce988b Faulting module name: NIlibeay32.dll, version: 22.214.171.124152, time stamp: 0x58b5d904 Exception code: 0xc0000005 Fault offset: 0x0000000000015323 Faulting process id: 0x1524 Faulting application start time: 0x01d3e93acfe076ab Faulting application path: C:\Program Files\National Instruments\LabVIEW 2017\LabVIEW.exe Faulting module path: C:\Program Files\National Instruments\Shared\nissl\NIlibeay32.dll Report Id: c8418d55-147d-4f50-bca2-0c34a47975f8 Faulting package full name: Faulting package-relative application ID:
I am using Labview 2017 x64.
This might somehow be a permissions issue? What happens if you run the program as administrator?
I can look into this further, Can you post screenshots of the LabVIEW crash?
I have tried to run it as admin but the result is the same. Labview does not generate any error codes, it just crashes. The only report I can get is from Windows event logger which I posted above.
I would like to give a quick update on the problem.
I tried the application on 2 different Intel NUC computers with Windows 10 installed. The problem still exits on this computers, even with a fresh Windows installation. I also tried on different computers and there were no problems, so I think the problem is related to NUC's hardware. We are using NUCs for the project thus I am still searching for solutions...
Basically nilibeay.dll is the NI compiled version of the pre-1.1 OpenSSL DLL. They renamed it to avoid name conflicts with other software installing and using OpenSSL, as the OpenSSL API libraries tend to be incompatible between versions. I believe the later versions of the NI version of the OpenSSL libraries do have some minor modifications to add proper locking of the SSL sessions with mutexes right in the library itself rather than by a wrapper library that must be called, but other than that it should be the same as any OpenSSL library with the same version. And the version should be visible in the Properties for the DLL file.
So your best bet would be to search for incompatibility problems of the 1.0.x OpenSSL libraries on your hardware. Someone must have tried to use OpenSSL on Intel NUC targets.
It's very possible that a bug in the network driver for those targets causes a problem in Winsock, which is used on a very low level by the OpenSSL library.
Thank you for the help Rolf.
To eliminate driver related problems I have tried to connect the network with an Amazon USB-Ethernet converter and disabled NUC's network hardware. As the only network equipment enabled on the system is this external ethernet connector, problem still exists.
Installing NI-DAQmx 18.1 solved the problem. I would like to thank everybody for their help.