LabView hangs after calling DLL

[Bublina]

Hello,

I am working on a library that makes calls to other DLLs, that are linked dynamically.

To do so, I have to customize the DLL search order before the call and add some custom directories (where the called DLLs are).

The called code runs fine, and doesn´t leak any memory within the called DLL, however LabView hangs.

It took me some time to figure this out, so I hope this helps someone in the future. Bellow is the solution.

[Bublina · Accepted solution]

LabView uses its own DLL search order so beware of using call to "SetDefaultDllDirectories" as it affects the whole process and LabView DLL managing functionality goes bust.

Allways avoid it using flags in the LoadLibraryEx.

[rolfk]

---

@Bublina wrote:

LabView uses its own DLL search order so beware of using call to "SetDefaultDllDirectories" as it affects the whole process and LabView DLL managing functionality goes bust.

Allways avoid it using flags in the LoadLibraryEx.

---

LabVIEW doesn't really uses a different search order than what the underlaying OS supports. The only thing LabVIEW does when it can't find a DLL at the path it last found it is to also check in the project directory.

Basically there are following scenarios:

1) you only specify the DLL name and no path:

       - LabVIEW passes the request to Windows load library and does nothing else

2) you specifiy an absolute path:

       - LabVIEW passes this path to Windows LoadLibraryEx() which will only attempt to load the DLL from that location and fail if the DLL is not already loaded from that location or can't be found there.

       - if it fails LabVIEW attempts to find the DLL in the project directory

       - if that fails LabVIEW passes the DLL name only to LoadLibrary() and lets Windows try to resolve that request

As you can see on the web SetDefaultDllDirectories has many possible problems that are completely independent of LabVIEW. Basically another attempt from Microsoft to solve a specific problem with DLL loading by adding a new layer of complexity to the already super complex underlaying system, and in the process make DLL hell an even bigger issue.

[Bublina]

---

@rolfk wrote:

LabVIEW doesn't really uses a different search order than what the underlaying OS supports. The only thing LabVIEW does when it can't find a DLL at the path it last found it is to also check in the project directory.

---

I ment the LabView DLL management in general (for LabView itself), I guess that's the reason of hanging.

[rolfk]

---

@Bublina wrote:

---

@rolfk wrote:

LabVIEW doesn't really uses a different search order than what the underlaying OS supports. The only thing LabVIEW does when it can't find a DLL at the path it last found it is to also check in the project directory.

---

I ment the LabView DLL management in general (for LabView itself), I guess that's the reason of hanging.

---

There is little that would deserve the name DLL management. LabVIEW simply lets Windows do the work. I still am convinced that the problem you are seeing is not LabVIEW specific, but rather a problem caused by your specific DLL, in conjunction to where you installed it and the non standard Windows configuration you try to enforce with that API call.