From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error loading lvanlys.dll in Labview 64 bits

Solved!
Go to solution

I just did a fresh install of LV 2019, 64 bit on a Ryzen 3600 and got the same behavior. Seems like an issue with the Ryzen 3x processors that is still present.

 

The marked solution works for me as well.

0 Kudos
Message 21 of 33
(4,485 Views)

@altenbach wrote:

Thinking about this a little more, it is not clear why the dll does not load without the tweak. Shouldn't it run just fine, but less optimized? What else comes into play here?


Most likely, the MKL does some serious initialization code in its DLLMain function, which gets called by Windows when it tries to load a DLL. In this DLLMain() function the routine to initialize the exact SSE method seems to error out because it can't determine the correct CPU family and this error is propagated up the call chain to the DLLMain function which then returns a failure to Windows, which lets Windows abort the loading of the DLL, and that in turn will fail the loading of the lvanlys.dll.

There are two possible bugs in this:

1) The initialization method might not need to error out on not being able to detect the exact SSE implementation but instead just fall back to a safe one like SSE2 which probably all current CPUs should support albeit this would result in less performance.

2) The error might not need to propagate up the call chain and fail the loading of the DLL if there is some sort of fallback possible, even if that fallback has (terrible) performance.

Rolf Kalbermatter
My Blog
Message 22 of 33
(4,456 Views)

I had the same problem with a new Ryzen 3600 and the fix worked fine for me also.

 

Thank you so much!

0 Kudos
Message 23 of 33
(4,442 Views)

Worked for me as well using Ryzen 9 3950X, thank you!

0 Kudos
Message 24 of 33
(4,379 Views)

I’ve run into this issue as well, and the solution worked for me. Does anyone know what version of LabVIEW has this fixed?  2019 SP1?  2020?

0 Kudos
Message 25 of 33
(4,277 Views)

This solved my issue too! Both  MKL_DEBUG_CPU_TYPE=4 and MKL_DEBUG_CPU_TYPE=5 work for me. My cpu is AMD Ryzen 9 3900XT 12-Core Processor.  

 

This issue was very frustrating!  I searched online many times. I tried many ways, like installing different versions of Labview, OS. Finally, I got here.

 

Really hope the team of Labview can solve this in the near future.

 

thanks a lot, anyway

0 Kudos
Message 26 of 33
(4,175 Views)

where do I put the enviromental variables in LabView (the code)? sorry, i'm new to the app. 

0 Kudos
Message 27 of 33
(4,152 Views)

That has nothing to do with LabVIEW, but rather with Windows.

 

https://docs.oracle.com/en/database/oracle/r-enterprise/1.5.1/oread/creating-and-modifying-environme...

Rolf Kalbermatter
My Blog
Message 28 of 33
(4,124 Views)

I experienced this issue too, and it took me a while until I found this thread, very frustrating. I hope NI can fix this at some point.

 

Thank you so much BoKnows for posting this workaround!

0 Kudos
Message 29 of 33
(4,094 Views)

If anyone stumbles upon this the bug, The number reported is actually bug number 960430 and is fixed in LabVIEW 2020 and NXG 5.0

 

Detailed steps for previous version of LabVIEW to solve this problem:
1) Add a new environmental variable in Windows: Control Panel » System » Advanced System Settings » Advanced » Environment Variables » System variables (the bottom part of the dialog) » New
2) Put MKL_DEBUG_CPU_TYPE as Variable name
3) Put 4 as Variable value
4) Confirm OK multiple times to close all dialogs
5) (A Windows restart might be needed.)
Message 30 of 33
(3,975 Views)