LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

calling dll runs in one labview version but crashes in others

Hello all,

I have a DLL written in C by another developer with its corresponding header file.  When he (the DLL creator) runs the call DLL node in LV 2009, the VI and subsequent code run just fine.  When I run the same VI in LV 2013, the call DLL node crashes LabVIEW.  We are aware that error checking for DLLs changed in LV 2010, but the call DLL node works for him in 2009 no matter what error checking mode (Max, Default, None) he chooses, which should not be the case if that is the problem.

Here is the function prototype from the header file:

ViStatus MAGDEV_API MagDev_enumerateDevices(    ViInt32 filters,  ViInt32 *nbrDevicesP,  ViSession *devicesIdArrayP,  ViUInt32 sizeOfdevicesIdArray);

When I use the import DLL feature in LabVIEW, it gives me this function prototype:
int32_t MagDev_enumerateDevices(int32_t filters, int32_t *nbrDevicesP, uint32_t *devicesIdArrayP, uint32_t sizeOfdevicesIdArray);

the wizard shows this as the recognized function:
long * MagDev_enumerateDevices(long filters, long *nbrDevicesP, unsigned long *devicesIdArrayP, unsigned long sizeOfdevicesIdArray);

The developer has acknowledged that these function prototypes/calls should be correct.  Despite that, the VI hangs when I run it.

The array is always 1024 elements long, and I have tried passing in just about everything I can think of into the DLL node with no success (initialized array, constants, no constants, etc).  I have also changed the parameters of the pass-in to signed, unsigned, pointer, value, etc to no avail.

Does anyone have any recommendations on where to find the problem or what the problem might be?  The DLL developer knows nothing about LabVIEW and does not want to share the C source code since it runs for him in LV 2009.  I think the nbrDevicesP pointer is something that is checked for NULL (which automatically throws an error in the DLL, not that I see that since it crashes) after it's passed in and is also used to return a value at the end.  Fairly standard C stuff, but I wonder if LV can handle that.  It's difficult for me to critique the DLL itself when he has shown screenshots of it successfully running in LV 2009.

Thanks,
Yevoc

 

P.S. - I wanted to attach the relevant files, but I can't share the dll here??

0 Kudos
Message 1 of 5
(2,527 Views)

Are both LabVIEW versions 32bit?

0 Kudos
Message 2 of 5
(2,521 Views)
Yes, I just confirmed that his LV 2009 is 32 bit. He also compiled the VI and ran it with the 32 bit LV 2014 runtime engine without any issues.
0 Kudos
Message 3 of 5
(2,471 Views)
  1. Are you using the same OS?
  2. Have you verified his DLL has no dependencies that aren't installed on your system?  For example, .NET version?
  3. If he has a compiled example that works, have him send that to you and confirm it runs on your system.  This will confirm it is not the DLL, and is, in fact LabVIEW.
0 Kudos
Message 4 of 5
(2,456 Views)
Thanks for the suggestions. I ran his compiled EXE using LV 2014 runtime engine, and it crashed as well. This points to there being a fundamental difference between our systems that appears to have nothing to do with LabVIEW.
0 Kudos
Message 5 of 5
(2,438 Views)