> We had a similar situation when a customer's C++ Exec was callling out
> dll, which turned out to be a threading problem. Actually, the
> problem was a little more complicated.
>
> I would check for open references, open hardware, etc. You may be
> neglecting to close a DAQ or Serial session, or something to that
> effect. However; the problem could be within the dll.
>
> The symptom you are seeing I have seen in IMAQ VIs. For whatever
> reason, LabVIEW causes a complete application or system failure when a
> memory allocation error occurs. I believe this is sympomatic of a
> larger problem in LabVIEW, but suspect that they are working on it.
>
> Try getting in touch with NI and see what they say. Also, put your
> code in Highlight Execution
mode to track down exactly where the
> problem occurs. I found this to be very helpful in isolating the IMAQ
> dlls as a source of an application crash in LabVIEW which turned out
> to be something as simple as a missing ROI input.
>
If the OS crashes, then more was involved than just LV. LV is an
application and has no protected code in it. It is not supposed to be
possible for LV to crash the OS without the aid of a driver. Drivers
have code that runs protected, as part of the OS, and if they get
confused, by LV or user inputs, they can lead to blue screens, etc.
For this case, I suspect that the DLL is overwriting memory and
corrupting the structures used by the memory manager. The second call
tries to access the same structures and crashes when doing so because
the pointers are no longer valid. I'd check to see if the DLL is
returning data in strings or arrays. If so, it probably expects you to
have adequately sized buffers before calling it. You can preallocat
e a
string or array, or use a constant full of blanks, it really doesn't
matter, but that is probably the most common cause of DLLs not working
as expected.
Greg McKaskle
