What does error code 42 mean when it comes from a Call Library Node?

[umars]

I've used call library node successfully before, but am not having any luck with a new DLL

I am trying to use.

What does this code (42) mean?  Does it imply my function prototype is wrong and I have

wrong type for return and/or parameters?

Thanks...

-Umar.

[smercurio_fc]

I thought this sounded familiar...

[umars]

wow...  completely forgot about that.

I don't remember what the solution to that one was, but I have some more info on this one.

It seemed like there was a conflict with a previous call to another DLL.  That DLL would get loaded

into memory, and would not allow the new one to be used.

I was able to remove the problem by eliminating the earlier unnecessary call to the other DLL.

Unfortunately, I do need to use the other DLL later on in my program.

I saw the help for Call Library Node, and it says you can manually unload a DLL by wiring in an

empty path to the Call Library Node (you get the path input if you check the 'specify library path' box

in the configuration page).

I did this, but it doesn't solve the problem.

The problem is I have to interact with one DLL (call it DLL1) and then another one (call it DLL2).

Unfortunately, these DLLs are dependent on another DLL (call it "DLL_common").

I put this in quotes because the "DLL_common" that DLL1 needs is different from the "DLL_common"

that DLL2 needs, though they both have the same name.

I have an app build using AutoIt in which this issue is resolved by putting DLL1 and DLL2 in separate

directories, and pairing each with their own version of "DLL_common".  But LabVIEW doesn't seem

to like this.

It seems like perhaps the LV mechanism for manually unloading a DLL (wiring a null path to the Call

Library Node) does not unload the DLLs that it was dependent on.

I'm sorry for not being able to make this clearer, but if any of this makes any sense, I'd appreciate

any suggestions...

Thanks...

-Umar.

[Neil.Pate]

---

smercurio_fc wrote:
I thought this sounded familiar...

---

I really expected your link to somewhere mention HHGTTG

😉

[SMeserve]

Hi umars,

The behavior you are seeing, that LabVIEW does not unload dependent DLLs, is not entirely unexpected.  The CLF does not have this functionality currently.

[umars]

I'm actually getting error 42 for another much simpler case:

Simply bringing up LabVIEW and running a VI that makes a call into a DLL, which

has the DLLs it depends on in the same folder, and nothing in the VI makes any

call to any conflicting DLL, results in this error.

I have confirmed prototype and calling conventions, but still get the error.

Has any one seen this error under similar simply situation as this, and found

a solution?

[umars]

I tried statically specifying the path to my dll in the Call Library Node configuration window instead of specifying it at runtime

on the diagram.  Doing so resulted in the attached error message as soon as I clicked OK.

[rolfk]

The DLL_common you have in the same folder, while having the right name most likely is not the right DLL. When you try to load a DLL into memory, Windows will attempt to resolve all non-delayed entries in the import table. One single one of them failing, will abort and fail the entire loading of the DLL and all its dependencies.

So if your DLL_common DLL has for whatever reasons not any and all imports used for your other DLL in its exported list of function you simply can't load that DLL into memory.

Also there are many complications that each of your DLLs could and probably tries to do. For instance putting a dependant DLL into the same directory as the calling DLL would normally not cause Windows to load that DLL unless both DLLs do reside in the Windows search paths. These are a very limited number of paths. So possibly your DLL contains some special code to search for the specific DLL in its own directory and load it from there. If it isn't there the load will fail and the DLL might try to load it with the DLL name alone to let Windows try to find it.

Using two DLLs in your project that use two different DLLs with the same name is a sure way of getting a one way ticket into DLL hell. And since the passing of an empty path to the Call Library Node according to StarsHockey seems not to work despite contrary claims in the LabVIEW documentation, there are only two possibilities I can see for now:

1) you can wrap the calls to the two DLLs into VIs that you load, execute and unload dynamically each time you need them. This should also unload the DLLs at the end, but I'm not sure it really will do so.

2) Write a wrapper DLL that does wrap those two DLLs and explicitedly loads and unloads the two DLLs using LoadLibrary and FreeLibrary for each call to one of them. This will work for sure eventhough the details how to do so may vary depending on how much "smartassness" each of those two DLLs does use itself to load the DLL_common.

Rolf Kalbermatter 

Message Edited by rolfk on 07-23-2009 10:03 AM