Upon exiting LV7: Application Error-Memory could not be read.

Question

Upon terminating my application, I get the following error:
"LavVIEW: LabVIEW.exe - Application Error
The instruction at referenced memory at . The memory could not be 'read'."
So far the error seems non-critical. It does not appear to affect the performance of the program in any way. However, it is certainly unnerving for my end users (not to mention me)!
The error occurs in both the executable and the debugging mode. I have traced it to the VERY END of my application, which runs flawlessly until the very moment when I use the Exit instruction. I have also tried using Close FP with Abort VI, as well as Close FP with Exit. All threads in my application have successful
ly terminated, so aborting does not stop any action in mid-execution, as far as I am aware.
Searching for others in the forum who have had similar problems has turned up little useful help. Could this be a bug in the (god forbid!) runtime engine?!
Here's a link to a discussion of the closest thing I could find to my problem.
Thanks for any help you can give. Any whatsoever.
-Nick
"You keep using that word. I do not think it means what you think it means." - Inigo Montoya

Answer 1

> Hmmm... I'll look into it. Many or all of the DLLs that I call were
> written in Delphi, which has at least three string types that come
> into play: regular Pascal String, PChar (Delphi's re-creation of the C
> string type), and the ShortString type, which is sized to 256 bytes
> (if memory serves). From your response, it sounds as if I should
> search for those DLLs that use the ShortString type.
>
> Also, I encode many complex data forms and pass them into the DLLs as
> array pointers. These also sound like places to start looking.
>
> Thanks for the input. If I ever track down the problem, I'll update
> this discussion for posterity. In the meantime, if anyone else out
> there has any more thoughts, I'd sure appreciate them.
To h
elp track it down, if you can build a debugging version of the
Delphi DLLs, especially something that will validate memory references.
One of the great tools for tracking down memory overwrites is a well
implemented debugging memory library. Also, if you have some notion of
DLL calls that write to the string and return it to LV, that would be
the first place to look. And in the end, the solution is usually to
look at the assumption of the DLL and send in a larger preallocated
string. So in some cases it is easiest to look for the strings and
arrays going into DLL node calls and one at a time give them large input
sizes looking for the closing crash to go away. Then when the symptom
goes away, look at the code for that DLL.
Greg McKaskle