DLL Maximum Error Checking problem

[Ivoef]

Hi,

I have a strange problem concerning calling a DLL function from LabView. The function prototype is

int32_t _GetRegister@20(int32_t DeviceNr, uint16_t ID, uint16_t Channel, uint8_t *pPointer, uint16_t Length);

Call convention is set to stdcall.

and calling code from LabView:

The function prototype in C++ code (VC2008 Expr. edition) is:

extern "C" int _declspec(dllexport) CALLBACK GetRegister(int nDeviceNumber, WORD wID, WORD wChannel, unsigned char *pPointer, WORD wLength)

Now when I call the function with Error Check Level set to Default, then everything is OK. The buffer pointed by pPointer is properly sized (its size is 0x2F6), initiated by 1, filled in DLL etc.

But when I call the function with Error Check Level set to Maximum, then the call finishes with an error:

When I have furthermore investigated the problem (via a debbuger attached to the DLL) I have found out one strange thing. In a memory allocated for the array (which should be initiated to value 0x1) and pointer to which is passed as fourth parameter, appear different values when the function is called with Maximum checking. See the following picture:

When the function is called with Default error checking or when the Minimum size parameter is set to proper number (which is 0x2F6), the allocated memory block is not corrupted and is fully filled with 0x1. When the Minimum size parameter is used then the function call succeeds regardless of Error Check Level setting.

I wonder if it could be due to some error in LabView 8.5.1, which I am using or there is something wrong in my code.

Any opinion is highly appreciated.

Ivo

[Barbara_XYZ]

Hi Ivoef

I'm sorry You got the answear so late. I'm not a DLL master, but I've made some research to try to help You.

Many issues involving DLLs are a result of improper memory handling. This can be caused by many different things. The rule of thumb is that a DLL cannot change the memory of LabVIEW's space. This is why you typically need to preallocate arrays, strings and clusters in LabVIEW before you intend to pass data back from a DLL. This is called static allocation of memory. This is only effective if you know the size of the data that is expected back from the DLL. If you need dynamic memory allocation, you need to use the LabVIEW Memory Manager functions. Basically the DLL tells LabVIEW to allocate memory instead of doing it by using "malloc" functions. Some times these errors can be tricky to find. Is the DLL resizing arrays, strings or clusters when it shouldn't be? Many times LabVIEW will report some sort of memory error however, memory mismanagement can also lead to crashing. See Call DLL.vi example - maybe You'll get some idea.

I have not found any reference so far for this issue being a version issue.

Hope This will help. Please, update the forun with Your work, so we can all gain new knowledge out of Your problem.

Your faithfully

Barbara

[Ivoef]

Hi Barbara,

thank you for your reply and help.

I look carefully at your post and checked all your suggestions. Nevertheless I think there is no such bug in my code. I am allocating a properly sized array in LV. I do not resize it in DLL. Just modify it's content. The LV itself seems to be "the culprit" who modifies the content of the array. I have checked everything in debugger.

I think the LV "DLL checker" puts in array some kind of signature but in wrong position and then reports a false positive error about DLL calling when the signature is overwritten with requested data by a DLL code.

Due to a time pressure I had to give up another investigation of the problem.

So the resolution was to turn off the extensive DLL checking, which is anyway intended only for development purposes.

Than you for your help.

Ivo