Hi Greg,
There are no CINs or DLLs that are not from NI.
Today I manage to isolate the problem to NI-DAQ VIs, specifically I can have
it crash in Device Reset or AI Group Config. To find this I needed to
"instrument" the NI VIs, this means I placed outputdebugstring.VI in
sequence before and after each NI-DAQ VI call.
I'm using NI-DAQ 6.9.X with two 4452 and one 6711, the 4452s are RTSI
synchronised. I have removed the code that uses the 6711, so now I only have
the 4452 code. It is in these calls that I have the problem.
Machine A - PIII 500 MHz 128 MB
I have produced the problem under Windows NT 4 SP6 using NI-DAQ 6.9.0f9 (not
sure about the f9) with applications built using LabVIEW 5.1.1 and also
recompiled and tested with LabVIEW 6.0.3
Machine B - PIV 1300 MHz 256 MB
I have produced the problem under Windows 2000 SP2 using NI-DAQ 6.9.1f20
with applications built using LabVIEW 5.1.1 and also recompiled and tested
with LabVIEW 6.0.3
I can not ship the entire app to NI, so I have tried to isolate the problem,
which is why I needed to use things like outputdebugstring.vi and the
options debugging=true and memorychecking=true.
The problem is not totally reproducible, in that running the same code path
does NOT always generate an error. This makes me believe that there is a
timing/resource dependency that is hard to isolate. It took me more tries on
Machine B to get it to crash compared to Machine A.
The System Crash dialog does not indicate a DLL but the executable code for
the crash address, information from Dr Watson.
I hope this explains the problem a little better.
Any ideas?
Cheers
Peter
"Greg McKaskle" wrote in message
news:3B8DB6AE.FD0133BE@austin.rr.com...
> > I'm trying to find the section of my application that causes LabVIEW to
> > crash with a memory exception error 0xC0000005. The problems was first
> > produced under LV 5.1.1 and then after some changes to allow the code to
run
> > on LV 6i.
> >
> > I have tried putting debugging output using the outputdebugstring to
allow
> > me to track execution with a debug viewer. I have also tried using the
> > debugging=true and memorychecking=true options to see if I could get any
> > additional information that would allow me to isolate the problem.
> >
> > What I'm looking for is a debugging option that would output debug
traces
> > from the LV code, that is as it enters a LV function such as a DAQ
function
> > it would display on the debugging viewer that the NI-DAQ function blah
has
> > run. Now this presupposes that such functionality exist within LabVIEW,
the
> > options debugging=true and memorychecking=true give me some hope that
there
> > is still undocumented INI file settings that would allow one to isolate
> > causes for crashes.
> >
> > Of course it goes with out saying that the problem is not totally
> > reproducible and single stepping with animation is not an option.
> >
>
> The shipping version of LV has the vast majority of debugging capabilities
> removed -- to improve size and speed of the executable. A couple things
to
> eliminate. Are there any DLLs or CINs involved not written by NI? If so,
> try to isolate them and either test them in isolation or eliminate them
and
> see if the crash still occurs. Once you are certain it is a problem with
> an NI component, you can compare the versions of NI drivers on your
machine
> to the currently available versions.
>
> Another thing to watch for. Has the system dialog ever indicated a module
> name? The OS will often just list the EXE name, which doesn't help much
> in determining which DLL or which part of the LV EXE accessed the bad
> address, but sometimes it will list the DLL name. Also, do you ever get
> a blue screen? On the blue screen, you will usually have a driver name,
> and that can indicate which driver needs to be updated.
>
> Finally, there is a decent chance this is caused by the code that LV
> generates or the support library. If it is possible to send in a somewhat
> simplified set of VIs that can reproduce the problem, then we can
determine
> what component is causing the problem and get it fixed faster.
>
> Greg McKaskle
