06-06-2019 01:42 PM
I've read some posts here where others have encountered the same problem and I was hoping someone could help me with my specific case.
I have a custom DLL that does some memory operations on a device and I am getting an error 1097 when I make certain calls, particularly ones of the following format:
DLL_EXPORT TIB_ERROR *WINAPI GetManufacturerInitCRC( IN_ HANDLE pas_uiHandle,
IN_ UINT16 *pas_uiMemoryPtr,
OUT_ UINT16 &pas_uiCalculated,
OUT_ UINT16 &pas_uiStored );
On the LabVIEW side the function prototype looks like this:
uint32_t GetManufacturerInitCRC(uint32_t EDS Object Handle, uint16_t *Memory, uint16_t *Calculated CRC, uint16_t *Stored CRC);
The function appears to be working, in that I get the correct results out of the call, but no matter what I do with changing the call library function parameters I cannot get rid of the 1097 error. I don't know that the error is causing me any problems, but I suspect that the error, which I am currently ignoring, may be causing instabilities that I see from time to time.
Does anyone have suggestions to make the error go away?
Thanks!
Solved! Go to Solution.
06-07-2019 03:54 AM - edited 06-07-2019 04:01 AM
What does the function expect to be passed in for the Memory parameter and what do you pass to it? What bitness does your LabVIEW have? What calling convention have you configured for the function? Are you sure there is a star (*) in front of WINAPI? That would mean that the function possibly returns an array of TIB_ERRORs which would be at least strange.
Also when you are at it, reconfigure the first parameter (and any other arameters in your API that are of type HANDLE) to be a pointer sized integer instead of a 32 bit integer. This shouldn't be the cause for the crash unless you use 64-bit LabVIEW. By making it pointer sized it won't matter which version of LabVIEW you are using for at least this parameter.
06-07-2019 06:37 PM
The memory parameter is a U16 1-D array. I am passing in an array of about 3000 elements.
I am using LabVIEW 2012 32-bit on a 64-bit Windows 7 machine.
The calling convention is set to C.
The asterisk in front of WINAPI is in the header file. I did not write the DLL, but I have access to the guy that did. I can ask him to make changes to make the calls happen without error if needed, but I am not sure what to ask for at this point.
Thanks!
06-08-2019 04:24 AM - edited 06-08-2019 04:28 AM
Well WINAPI is a macro that specifically indicates __stdcall calling convention. So by configuring the Call Library Node as __cdecl you certainly get the calling stack corrupted and it actually seems strange that the function seems to even produce anything valid.
What bothered me too is that there seems no way to tell the function how large the Memory array is, but maybe that is embedded in the array data somehow. Possible but somewhat dangereous if you don't pass in a valid data stream in that array.
A better API would be:
DLL_EXPORT TIB_ERROR WINAPI GetManufacturerInitCRC(IN_ HANDLE pas_uiHandle, IN_ UINT16 *pas_uiMemoryPtr, IN_ UINT16 pas_uiMemorySize, OUT_ UINT16 &pas_uiCalculated, OUT_ UINT16 &pas_uiStored);
And then the function should use the MemorySize parameter to not try to read past the end of the array no matter what the array data may indicate.
06-12-2019 12:47 PM