Built executable dependent on dlls works in LV2016x64 but not in LV2024x64 (Arcus PMX-4EX-SA)

[NRiver]

Hi All,

I've got some strange behaviour when building an application that controls an Arcus PMX-4EX-SA (this may be relevant, it may not be) and the Arcus driver uses 2 dlls, the 1st is called directly by a CLFNs and the 2nd is a dependency of the 1st.

I've got a very simple test application which gets the number of connected devices and displays them in a listbox, you then select the device, a connection is made and then closed. When I run an exe that has been built in 2016, everything is fine, the connected device is displayed in the listbox (which requires dll calls) and the connection is then opened and closed. Now when I do exactly the same thing except built in LV2024, I get the device listed in the listbox - so I know that something in the dll is working, but when I connect I get an error from the dll. In this case it's about a USB buffer overflow (I don't think this is really relevant).

I haven't had the time to try (and I probably won't as my customer does not want to get bogged down by this if we can get something running):

- running in the LabVIEW 2024 IDE,

- any other versions of LabVIEW (exe or development)

I have ruled out any basic mistakes like bitness and have ensured that I know exactly which dlls are being loaded by removing them from any search paths so LV prompts me to manually select them at runtime. The 2nd dll is in the same folder as the 1st. It seems like the only difference is the runtime engine, but I can't understand why - once the dll is executing it's own functions then isn't that out of the sphere of control of LV? So if the dll loads correctly (which if it didn't, I'd expect LV errors) then how can a runtime engine affect the dll's function? If anyone has any thoughts on this then I'd very much like to hear them.

Thanks,

Naeem

[wiebe@CARYA]

I think you're right about the loading of the dll.  Unless the dll dynamically loads other dependencies, if the exe loads without breaking, the dll seem to load just fine.

You could, to be extra sure, call the 2nd dll directly from a VI in code that's never called, but isn't removed by dead code elimination (e.g. a case w\ Boolean on the FP). That would force the dll to be in memory and it would break the VI if there's a problem loading this dll.

Are any of these dlls build in LabVIEW? That would add a few reasons for failure. 

What remains is the executable. How about user rights? Is there a difference if you right click, run as administrator (e.g. elevated rights)?

[NRiver]

These are great suggestions - thanks so much. Unfortunately for the moment the 2016 build is now out and functional so I won't get to try these out yet but I will as soon as I get the chance.