LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Find path of dll in Library Node Function

Solved!
Go to solution

In a library node function call, a dll (i2cfa.dll) is called and I can't see the path. Clicking browse will get me to the desktop. During execution the dll opens a window and in that window I can see that the dll revision is equal to 1.
 
In the PC I have 4 instances of this dll. And all of the are revision 2 when being opened. There is no revision 1 dll as I have searched the whole PC, and LabVIEW search paths.
 
How can I find out the path of this ghost dll labview is calling? I tried tasklist in cmd but since the dll is in the LabVIEW application context I can't see any task with a similar name i.e. i2c.

0 Kudos
Message 1 of 15
(4,293 Views)

I've used process monitor to track down where applications are trying to load DLLs from but I'm not sure I understand the question you are asking.

 

Is the issue that the call library function node is calling a DLL and you are not sure where that DLL is being loaded or is the CLFN calling a function that requires another DLL to be loaded into memory and that DLL isn't being found?

Matt J | National Instruments | CLA
0 Kudos
Message 2 of 15
(4,266 Views)
Solution
Accepted by topic author Heartbeat

I'd use LoadLibraryA, and then a GetModuleFileNameA. Give the LoadLibrary just the name, and it should return a reference to the loaded module. Then GetModuleFileNameA will return it's path. 

 

Of course use FreeLibrary to release the module reference.

 

Get Loaded DLL Path.png

In LabVIEW 2013...

Message 3 of 15
(4,251 Views)

Hey Wiebe,

That's a really good contribution!

 

I have a small addition: As you wrote, GetModuleFileNameA will return the path for a module that was loaded. However, this means loaded by the current process (as you are doing in your example). There is also GetModuleFileNameExA, which locates the file of a module that was loaded by another process.

 

And a remark: I don't know if these functions are aware of Windows 64-bit's transparent path redirection, that is 64-bit dlls being stored in %windir%\system32, 32-bit dlls in %windir%\syswow64. In case the function returns a path that seems to be non-existent, check the other path as well.


Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
Message 4 of 15
(4,237 Views)

@ikaiser wrote:

Hey Wiebe,

That's a really good contribution!


Thanks, surprisingly simply. Hope it works for OP.

 


@ikaiser wrote:

 

I have a small addition: As you wrote, GetModuleFileNameA will return the path for a module that was loaded. However, this means loaded by the current process (as you are doing in your example). There is also GetModuleFileNameExA, which locates the file of a module that was loaded by another process.


Yes, but you'll need privileges to be allowed to do that. That could make things really complex. I think dlls loaded by dlls in LabVIEW, count as the same process. Not sure, someone should do an experiment.

 


@ikaiser wrote:

 

And a remark: I don't know if these functions are aware of Windows 64-bit's transparent path redirection, that is 64-bit dlls being stored in %windir%\system32, 32-bit dlls in %windir%\syswow64. In case the function returns a path that seems to be non-existent, check the other path as well.


At some point I'll undergo the transition to 64 bit. At the moment, I have no reason...

 

 

0 Kudos
Message 5 of 15
(4,229 Views)

wiebe@CARYA wrote:


At some point I'll undergo the transition to 64 bit. At the moment, I have no reason... 


Just change the HINSTANCE parameter for each of the three functions from Numeric->(U)Int32 to Numeric->Pointer Sized (Unsigned) Integer. That way it will still work in 32-bit but you will be prepared when (rather than if) you ever move to 64-bit.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 15
(4,225 Views)

@rolfk wrote:

wiebe@CARYA wrote:


At some point I'll undergo the transition to 64 bit. At the moment, I have no reason... 


Just change the HINSTANCE parameter for each of the three functions from Numeric->(U)Int32 to Numeric->Pointer Sized (Unsigned) Integer. That way it will still work in 32-bit but you will be prepared when (rather than if) you ever move to 64-bit.


Your probably right, but how can you tell from the spec if a handle is a pointer? Are all handles pointer sized? I think you've mentioned something about this somewhere a while ago.

0 Kudos
Message 7 of 15
(4,218 Views)

You can't tell what is the internal implementation. But a Windows HANDLE is defined as

 

typedef void *HANDLE;

And all H-something variables in Windows are defined as being of type

#define DECLARE_HANDLE(name) struct name##__{int unused;}; typedef struct name##__ *name

Which is a pointer to a struct containing an opaque int value. What this int value means, if anything, is up to the resource manager handling the according type of handle, for some the handle itself is a pointer to some internal data structures, for others the int value is an index of some sorts into a table of resources, and for some it's probably something else.

 

So all Windows API functions accepting a handle of some sorts (HWND, HDC, HBRUSH, HBITMAP, HKEY, HENHMETAFILE, HFONT, HICON, HMENU, etc) expect here a pointer sized value even if some might not use the upper 32 bit of the value on 64 bit platforms.

Rolf Kalbermatter
My Blog
Message 8 of 15
(4,206 Views)

Rolf, OK thanks. I thought there were exceptions.

 

Attached is the same VI with a pointer sized integer. I also changed the CLFN to run in any thread. No need to stall the UI thread. I also added error in\error out and connected the inputs and outputs to the CP. And I put the configuration to show 'names' (that could be more descriptive).

 

Get Loaded DLL Path.png

Message 9 of 15
(4,183 Views)

Nice work, but my eyes hurt when I see the module name wire not lining up to the arg1 parameter (which could be named more descriptively too). Smiley LOL

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 15
(4,179 Views)