Showing results for 
Search instead for 
Did you mean: 

LV2010 can't find dll but Win7 sees it

Go to solution

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?



0 Kudos
Message 1 of 6
Accepted by topic author old_man_XJ

LabView will find the DLL if it is not in System32. 

0 Kudos
Message 2 of 6

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,


0 Kudos
Message 3 of 6

Hi Lars-Goran,


This thread looks like its a few years old, you will likely get better traffic by creating a new thread.  

Joel I.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 6

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


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!

Tom L.
Message 5 of 6

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."



0 Kudos
Message 6 of 6