04-05-2011 12:58 PM
I am trying to access a DLL from a company called USB Micro using 2010. I take the DLL (USBm.dll) and put it in the Systems32 directory. I can use Explorer and go see that the file is indeed there, but when I use the browse function of the Call Library Function Node VI, it does not show up in the window. I tried using a file constant and feeding it into the VI but with the same results. I even made a sub-directory in the System32 directory and the VI browse does not see the sub-directory.
I've done this before in earlier LV versions with no problems.
I checked the file permissions and they seem the same as the other DLL's
Anybody ever seen this issue or am I suffering from cranial rectumitus?
Solved! Go to Solution.
04-05-2011 01:11 PM
LabView will find the DLL if it is not in System32.
03-05-2014 04:23 AM
I have the same issue with LV 2013, Win7 and an aardark.dll for Aardvark I2C/SPI driver.
The solution above doesn't explain the behavior. Does anyone know why LabVIEW can't see certain DLLs in System32?
And what to do about it?
Best regards,
Lars-Göran
03-05-2014 05:44 PM
Hi Lars-Goran,
This thread looks like its a few years old, you will likely get better traffic by creating a new thread.
03-05-2014 08:37 PM
Hello Lars-Goran,
Without more information it's difficult to say for certain, but if my inkling is right this is because you're using 64-bit Windows and the DLL is the wrong bitness for that location. This isn't a LabVIEW-specific issue, refer to this thread:
Stack Overflow: LoadLibraryW() failing to load DLL in System32
http://stackoverflow.com/questions/18522102/loadlibraryw-failing-to-load-dll-in-system32
It's also possible that the DLL isn't registered properly or that it's registered incorrectly as a 32/64-bit library (likely if it's a 32-bit DLL in the System32 Directory on an x86 system). If you can provide more information on the system in question as well as the specifics of the DLL you're using it would be easier to offer advice.
Also, as mentioned by Joel, starting a new thread will probably get more replies- this one is several years old and marked as already solved. If you do find a solution I'd encourage you to re-post it here for posterity, though.
Hope that helps!
03-06-2014 02:02 AM
Thanks Tom,
the link you provided gave the right explanation I guess:
"The likely reason ... is failing is that you're running a 64-bit edition of Windows, but your ... driver has erroneously installed its 32-bit DLL in question into the System32
folder instead of the SysWOW64
folder."
/Lars-Göran