I try to install Labview 2020 through the NI package manager. But I get this error:
I have followed several steps to debug the error from the NI forum. But, I can't solve it.
Why I get this error? Anyone can help?
I have the same problem. And I also have no idea how to get rid of this error.
I solved the problem. You can refer to this link: https://forums.ni.com/t5/LabVIEW/LabVIEW-Not-Installing/td-p/3975586?profile.language=en.
First, uninstall all the Labview software/folder. Then, install back the software one by one.
Hi, I'd like to add to this discussion since I just encountered this. Background: I currently have LabVIEW 2019 and 2020 on my PC. I wanted to install LabVIEW NXG and include the Web Server Development. These instructions worked for me: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kIbbSAE&l=en-US . I like this because it didn't require uninstalling and reinstalling everything. Hope this helps someone else.
I know this is an "old" thread at this point, but I ran into this issue today, and spent the better part of 6 hours trying to solve it, and figured I'd post the results here in case anyone runs into this in the future. My symptoms were the same as were posted here, and I tried everything posted here multiple times... uninstalling Erlang/RabbitMQ, clearing folders, clearing registry, uninstalling NI and starting from scratch, nothing worked.
After enabling logs in the NI Package Manager, I found that the process was falling when connecting to RabbitMQ. Looking further, I found that the RabbitMQ service was not started. I tried starting it manually, and it stopped almost immediately.
I then tried uninstalling RabbitMQ & Erlang, and installed them myself from the official sites (to try and start clean), and the Rabbit service STILL wouldn't start.
I poked around on the web, specifically around this topic, and someone suggested checking the windows Event Log, which I did. This showed two errors.
1. ErlSrv: "RabbitMQ: Erlang machine stopped instantly (distribution name conflict?). The service is not restarted, ignoring OnFail option."
2. Generic "Application Error" which was tied to erl.exe, when calling the crypto.dll
Some more searching eventually let me to find out that there is apparently an issue with OpenSSL in some limited use cases where the hashing used by Erlang will cause a crash.
I was able to confirm this by launching the Erlang interface manually and running the command :
(note the "." at the end... as someone who never used erlang before this took me a few tries to get).
This command crashed Erlang.
Supposedly this was an issue with OpenSSL 1.0.0, and solved with OpenSSL 1.1.1. I believe the Erlang distribution that NI is using here is calling the "old" version... maybe (it's unclear whether OpenSSL is tied tot he OS, or Erlang, or both/neither).
Regardless, apparently the "block" of SSL code being called here can be avoided by adding an environmental variable to the system of:
This must be done through the OS interface :
Advanced System Settings >> Environmental Variables
and then explorer.exe must be restarted (or the computer).
THEN you can start the RabbitMQ service, and the installation of this package will install correctly.
(note: The work around that I specified works with the out-of-box NI installation, so the Erlang/RabbitMQ was not needed at the end of the day. It was useful for me while troubleshooting though).
Here are some links on this topic:
- Article from Intel on the crash/work around: https://software.intel.com/content/www/us/en/develop/articles/openssl-sha-crash-bug-requires-applica...
- Bug report in Erlang which describes the crypto.dll crash report: https://bugs.erlang.org/browse/ERL-533
- Second bug report in Erlang which describes crash/work around, and some details about the OpenSSL versions.
Again, I'm not sure why this issue was seemingly only an issue for me (the solutions posted here seem to work for a majority of people?), but it was. For reference, I'm working on a Microsoft Surface Pro, with Windows 10, and was installing LabVIEW 2020 SP1. OS was up-to-date.
I should also note, that "Skipping" the NI Web Server Development Installation ALSO solved the problem for me, but in my case I'm actually developing against that so it wasn't an option.
Open SSL 1.0.0, 1.0.1 and 1.0.2, 1.1.0 and 1.1.1 are not binary compatible. For one they changed the used DLL names multiple times, and also made binary incompatible changes to the API between some of these versions. OpenSSL never guaranteed binary compatibility between different versions and never made serious attempts to make it binary compatible between versions either.
So if a software was compiled with one of these versions as dependency it will generally only work with that version of OpenSSL (but will work with all the bug fix minor versions of that version indicated by the appended letter a-z). It seems they plan to go directly to version 3.0.0 as next step, whenever that one will be ready.