Labview VI behaving inconsistently

[blockheadjr]

This seems to be a common occurance for me:  I have a library node call function that queries a C program via a .dll file.  The function is used as a sub-VI for other larger Labview programs, and is quite simply a library node with outputs and an error in/error out line.  Nothing fancy.

The thing is, one program will use this VI successfully while another will result in the dreaded memory corruption error, located at the library node in question.  And it gets stranger:  a modified version of this library node VI was made for testing.  On day one, it worked like a charm.  On day two, memory corruption error.  The same damn program.  The only changes between day one and day two were a cleanup and consolidation of files, and I know that shouldn't pose a problem.

Other info:  the C code query initiates I/O with a power supply in every case above.  I have not mucked with the C code or the .dll file. 

Are there any memory corruption error vets out there who can recommend a plan of action?  Or, in lieu of that,  a novel way to vent my frustration with Labview?

Thanks.

[blockheadjr]

And to add more fuel to the fire:

In the Call Library Function properties of the VI in question, the function name is "GrabLogData", but the function prototype is listed as GrabLogData@@YAHJAP000...@Z.  I have no idea where this suffix of letters, numbers and @'s comes from.  It certainly isn't in the C code that the function calls to. 

[WM_John_Weeks]

I don't use Labview, so I can't really help with suggestions for debugging.

However, your description of the symptoms sound very much like memory corruption (ah- you included that phrase in your post, didn't you). I would look through the library source looking for some place where you write one element past the end of an array or something like that.

Overwriting memory like that can often be completely benign if there isn't anything important in the next few bytes. But then you re-load the library, or use it with a different program, or re-shuffle your source (so it links in a different order) and those bytes now hold something important.

This can be particularly difficult to track down, because the corrupted bytes may be accessed in a completely different part of the code, so that by the time the crash comes, the actual cause of the crash happened long ago.

Good luck!

[blockheadjr]

Thanks, John.

I realize this topic has been brought up in the wrong forum (not sure how that happened), so your input is especially appreciated.