02-23-2026 03:47 AM
Hi,
i have received a Labvieww project in which some dependencies are strange since on my computer the DLL are under /Windows/System32, while in the project are directly under C:. I have tried to adjust the thing but it worked only for one DLL (DAQNavi_LV.ddl) with the result of showing it two times (i have only specified the path in the function node which uses the dll). I can't remove the wrong dlls and if I try to refresh the dependences nothing change (moreover i have no access to some visthat uses nilvaiu.dll). How can i solve the problem since when i built the EXE somo dependencies will miss?
thank you for the help!
best regards
Zuc
02-23-2026 05:00 AM
The application builder will include most dependencies automatically and if one is missed you can add it to the "always include" list in the build specification.
(There is no C: in a project, the hierarchy is virtual and has little to do with location in the file system.)
02-23-2026 09:06 AM
Hi altenbach,
it's fine that the Folder tree can be different from the project organization, the fact that no path is shown for the dlls is leaving me with some doubts. especially if i build an exe to deploy on a target machine. How can i check if the paths are all ok?
Best Regards,
Zuc
02-23-2026 10:48 AM
DLLs without any path in the project window are actually loaded from one of the relevant search locations that include system32 and windows directory. You should also NEVER enter a full path to any such DLLs in the Library Path inside the Call Library Node. The fact that you only include the library name without any directory information is a special indication to LabVIEW that it is a system library that should not be included in an application build. If you enter the full path you not only can confuse LabVIEW/Windows (when the project is loaded on a different computer) but also will cause the LabVIEW application builder to include that DLL into the build as a private library. And if that happens with DLLs such as kernel32.dll or advapi32.dll or anything similar, Windows completely looses it and causes rather sooner than later that the process is terminated due to some protection fault error and under extreme situations the entire Windows system can get unstable.
02-24-2026 04:51 AM
Hi rolfolk,
the problem is related to the Exe build. the AdvLvDaq (in System32 by installation of the driver) is seen as a dll to save in the support folder, DAQNavi_LV.dll, otherwise, isn't saved in the support folder and the exe have problems at the start up. observing the differences between the DLLs i was trying to understand the best practice to manage third part dlls and projects.
Best regards,
Zuc
02-24-2026 05:33 AM
If the application builder includes the DLL in the build it is because one of the Call Library Nodes contains a full path rather than just the library name. If that DLL is installed in the system32 folder, this is an error of that Call Library Node.
You need to find the respective Call Library Nodes (search with text in the project) and change the Library Path to the name only.
DLLs from system32 are NOT to be installed by an application directly but by the relevant driver installer!