LabVIEW exits unexpectedly

[JohnMOwens]

We have a system set up using multiple instrumentation buses, VXI, GPIB, USB, ethernet, etc. all from one computer running Windows XP. Our system is designed to use TestStand 3.1 for control of testing and LabVIEW 7.1 for the actual tests. We have a situation where when a LabVIEW vi that was started by TestStand is running, LabVIEW will sometimes entirely exit without warning. TestStand will still be running, but the LabVIEW process, as seen in task manager, is no longer running. There are no error messages that pop up or any other sort of indication. The processor and memory usage during the tests are fairly low. Is there any way to troubleshoot this type of problem?

[JohnBoy]

Have you tried setting-up breakpoints at all the legal points of exit, in case one of those is unexpectedly functioning?  Don't forget, that you can save the breakpoints with the vi, but only if you alter something else as well.  Say, move anything up and down 1 pixcel.  The breakpoints only work in Development mode, so you'd need to be running the vi like that.

[JohnMOwens]

My apologies. First I must state that the actual LabVIEW Process was still running in task manager, but the Application was no longer visible in the Applications tab. Basically, LabVIEW did not go through a legal exit point. If it had then TestStand would have responded appropriately. But as far as TestStand was concerned, LabVIEW was still running properly. Thus putting breakpoints in the code at legal exit points (of which there is really only one in this code) would do no good.

To make matters somewhat worse, the problem happens randomly. The longest I've run the VI (set of VIs actually) is somewhere around 15 hours. The problem may never appear in that time, or it could appear anywhere from 5 minutes after starting to many hours after starting. And the VI as a whole is doing the same thing repeatedly at a rate of approximatrely once cycle every second. Thus any problem within the code that would end up killing LabVIEW would be very difficult to find using normal methods.

However, I am open to ideas. If it helps, the main VI starts seven VIs which run as their own process. All the VIs communicate with each other through Queues. One of these VIs is running at Time Critical priority. Normal processor usage while running is from 10 to 20 percent.

[DFGray]

Attached is a VI which should help you narrow down the problem a bit.  It is a very lightweight "logging" VI (LV7.1 version).  To use, place it at strategic places in your code and wire a text string to identify the location to the appropriate input.  Download a copy of DebugView from Microsoft SysInternals (it is free) and run it simultaneously.  When you run your VI, every time it hits the logging VI, it will post a message to the Windows debug output.  DebugView will log this, complete with timestamps (great for finding complex race conditions and fine-grained performance tuning).  You can save the DebugView outputs for analysis. Good luck.  Let us know if we can help further.

Message Edited by DFGray on 10-16-2007 08:59 AM

[Neil.Pate]

DFGray,

an excellent tool!

I don't suppose you have a few minutes to put together a list of any other similar apps you use frequently while developing?

Neil

[JohnMOwens]

Thanks for the idea. I had something similar, but it would hae died along with LabVEIW. This is definitely much better. I also recevied word from NI that the crash scenario was most likely due to a DLL crashing. Apparently in LabVIEW (at least 7.1 anyway) when a DLL goes then LabVIEW goes with it. Thus I can concentrate on the few DLL calls to begin with and see if one is causing the problem.