Labview 2009 executable crashing at random times

[ttat]

Hi.  We have a program that is crashing when it's in executable form in Labview 2009.  It didn't do this when it was built in 8.0.1.  It doesn't seem to crash at the same place or the same time.  Sometimes it runs for a long time without crashing.  Sometimes it crashes during the first 5 minutes.  If we run the program again and try the same operations, it works fine.  Here's what showed up when I put a debugger on it when it crashed.

Any ideas what can be causing this?  Sorry, I can't post the VIs, nor can I post screen shots.  Thanks in advance.

[GerdW]

Hi ttat,

what kind of answer do you expect when you don't show any code, don't give any information about code (IMAQ?, DAQmx?, ActiveX?, .NET?, 3rd party hardware?), don't give any information on crash (error code provided?, CPU load?, memory load?)???

All you show is a disassembled part of code... That could be anything...

[altenbach]

Also check the runtime version.

We noticed some random crashes when running an application built in LabVIEW 2009 SP1 on a target that only had the original 2009 (non SP1) runtime engine.

[ttat]

---

@GerdW wrote:

Hi ttat,

what kind of answer do you expect when you don't show any code, don't give any information about code (IMAQ?, DAQmx?, ActiveX?, .NET?, 3rd party hardware?), don't give any information on crash (error code provided?, CPU load?, memory load?)???

All you show is a disassembled part of code... That could be anything...

---

what kind of answer do you expect when you don't show any code

Sadly, I can't show the code.  It's NDA.  Also, the program is very large with over 2000 VIs.  I was hoping someone has also been having this problem.  It kind of looks like a memory problem in the executable.

don't give any information about code (IMAQ?, DAQmx?, ActiveX?, .NET?, 3rd party hardware?)

IMAQ, DAQ, .NET, a lot of 3rd party hardware (like I said, there's a lot of VIs)

don't give any information on crash (error code provided?, CPU load?, memory load?)???

All you show is a disassembled part of code... That could be anything...

That's the problem.  It's all I know too.  The program crashes at different times.  I can't repeat the crash with the same states.  No error code is returned.  The CPU isn't overloaded.  There's plenty of memory available.  It's crashed in every computer we have.  They range from old laptops to our newer development machines.  It just crashes and pops up the Windows thing to "Send" or "Don't Send" the error to Microsoft.  When it crashed in computers with a C++ compiler, we were able to see the disassembly, and it looks like it's always crashing at the same location.  After following where the address pointed to, it was 1 byte over what looks like allocated memory.

[ttat]

They should all have the SP1 runtime engine.  We include the Runtime Engine in the installer, so it should all have the same Runtime Engine as the development machine.  Also, it has crashed in the development machine that it was built in.  I will double check just to make sure though.

[wilburwu]

Hi,

u may try to check the I/Os in the program (serial, ActiveX, IMAQ). If ur system is run on Windows, the NI spy may help. Post the spy file her if u see the crash and may need help. It may cause crashes if the same I/O is opened or read simultaneously.

If u are sure the versions of the run-times are the same on different parts of ur system, that can only be a software problem in ur programming.

Wilbur

[ttat]

Hi,

Thanks for the reply.  We are starting to think it's an I/O problem too.  We've been noticing that it is usually doing some sort of I/O when it crashes.  We will try running NI Spy to see if we can get any other info.

Regarding the disassembly, I have looked at it a little further.  The spot where it crashes, it has a MOV command.  The address that it's trying to move that data is into a memory location that is just 1 byte above what looks like the allocated memory.  Not sure if that helps.

[TT13]

wondering if you found the solution to your problems? 

We have been experiencing similar problems and are running out of good ideas.