LabVIEW 8.6.1 crashes trying to read address 0x10

[jdoyle]

LabVIEW 8.6.1. Application is running on various dual-core Intel systems.  It makes great use of multiple threads, LabVIEW objects, queues, notifiers, etc. We are getting persistent crashes in what appears to be lvrt.dll.  We are using several 3rd party DLLs and some of our own, so we can't be sure that one of these DLLs is not contributing to the problem.  We have not been able to correlate this crash with any particular activity in our application.  It doesn't seem to depend on load.  We have trapped the crash with VS2005, but without symbols, there is not much information. I have attached various windows from the debugger.

Note that we have tried to move to LV2009, but it vanishes trying to read our .lvproj file.  This problem has been submitted as a separate report.

[DiscoBall]

Hi jdoyle,
 
Sorry to hear that you are having trouble. Let's try to get some items straightened out...
 
1. What operating system, service packs are you running?

2. At what point did the crashes happen? Can you isolate a change that started causing issues?
3. Do you get any LabVIEW error logs when LabVIEW restarts?


Perhaps we can isolate if the issue is with LabVIEW versus one of your functions inside your DLLs by using Diagram Disables.

[jdoyle]

Hi, Joshua. We have had it happen on a variety of Windows systems. One is a Windows Server 2003, Standard edition, SP2, 4 Xenon CPUs @ 2 GHz w/4 GB RAM.  Another is a laptop running Windows XP Pro Ver 2002 SP3 on an Intel dual core CPU @ 2.1 GHz w/3 GB RAM.

We have not been able to correlate the crash with any specific application activity.  There are 2500+ VIs and innumerable independent threads using all the usual synchronization mechanisms.  The most heavily-used DLLs have been used for some time and we believe they are stable, but of course we can't prove this.  We can say that this problem did not occur prior to using 8.6.1.

I will look into using diagram disables on the DLL calls, but most of them are so critical to the application's operation that it would be difficult to avoid using them.  We are unable, as yet, to get the crash to happen with great frequency (once or twice a day during testing is about normal).

There is no error log when LabVIEW restarts.

Since the problem is not reliably reproducible, I think we should first concentrate on a way to use the information available in the JIT debugger to isolate the general source of the problem.  I.e., is it in a DLL, was it LabVIEW trying to use memory/stack corrupted by a DLL, or did LabVIEW get in trouble all by itself?

I should note that one of our engineers lives in Austin, which might lend itself to collaberation on this and one of our other bugs.

Thanks,

John Doyle

[DiscoBall]

Hi John,

I agree with your debugging approach, however please understand that working with the JIT ebugging for LabVIEW with a very large application is a bit out of the scope from what we (Applications Engineers) handle on the forums. Therfore, we may need to get some extra help. Who is the Field Sales Engineer that you normally communicate with for NI products?

Message Edited by DiscoBall on 08-24-2009 11:32 PM

[jdoyle]

Our FSE is Hani Rajabi.  What's the next step?

[DiscoBall]

H John,

It appears you have already taken the next step. I hear that you made some phone support requests. That will be the best way for you to get the quickest support possible.