My compiled program crashes after first run (LabVIEW 2009)

[Wire_Warrior]

I have a compiled program created with LabVIEW 2009 that on the first run after the computer is re-booted will work fine but after shutting down the program it will not run properly. 

The program uses a compiled launcher to dynamically activate a set of VI's containing Queue Driven State Machines (QDSM).  On subsequent program starts the launcher module comes up fine and its progress bar shows that it is launching each of the VI's.  Once the launcher is complete it removes itself from memory leaving the dynamically launched VI's running.  The subsequent launches which fail the main user interface VI pops up barely long enough for the observer to see (if at all) then shuts down.  The program is then gone from memory as far as I can tell.  There are no processes in memory or anything.

Additionally, the when I try to run the installed version of the exe on a computer that has the 2009 development environment installed I get this behavior consistently with a successful run even once.

In both cases my program does not throw any errors (which are logged) nor does the runtime engine generate any that I can see.  Also, when I run my program in the development environment the program does not behave this way.  It has no problems at all.

I have used this style of architecture before in LV8.6 with out any problems.  Can anyone suggest some possible solutions or even some debugging tips?  I have never had a problem that I could not duplicate in the development environment so I am unsure how begin attacking my issue.

Thanks for any help.

Jason

[falkpl]

Are you using error clusters to capture any errors generated in the program.  I would just guess that a resource is not closed on termination of the program.  Are you leaving any files or tasks or ports running when the program closes that might not be killed when the runtime engine closes?  What resources are being used by the program.

[Wire_Warrior]

Well the program does use 3 different INI files, 2 TCP ports, references to the QDSM VI's, I am not sure I understand how this could cause the program to fail to start exactly but I will look into that.

Are the NI tools that I can use to look at the resources?

Jason

[falkpl]

Without seeing code I am just guessing, I suggested resources being left open since the queued state machine often is implemented with an error handler case that will exit the program, this is where you should catch any errors and at least announce them before exiting.  The resources I was mentioning because trying get a resource that is locked will throw an error (ie resource is busy) causing the second itteration of a program to error.  Another possible source is the TCP ports blocked by a firewall.  Again these are some things I would check based on the symptoms.

[Wire_Warrior]

Ah, I understand.  I'll try to peel that onion some more.

I have also began to look for race conditions that might be masked when running in the development environment.  It may be a long shot but it's something I thought of this morning.

[PJS]

So you are saying the launcher works just fine, but on subsequent launches of your dynamically called routines, the FP opens and then the application exits.  Meanwhile, you launcher exits out.  

Is your dynamically called VIs set to open front panel on load or are you opening them dynamically?  If the later case, then it sounds like your program is exiting 'normally'.  Do your QDSMs have the ability to log the executed cases? Are there parameters that are being passed that maybe misshandled by the launcher?  If the whole application exits memory, and then fails to run on second launch, this sounds like it is NOT a resource issue.  

[Wire_Warrior]

PJS,

Your description of the problem is spot on.  The front panels are being open dynamically.  I am coding in the logging of executed cases now.  The launcher passes no parameters as everything is loaded from one of the INI files.

Thanks for the comments so far everyone.  Keep 'em comming!

[RDR]

Two tips:

1) Add code to log the state of execution of the application to disk; for instance:

This will provide you with an "execution trace" of sorts as you will know exactly how much of the code executes on the second run (it may be hitting an error case and the error is just not getting logged).

2) Consider building a debuggable executable in order to utilize some of the built-in tools to debug the "launcher" VI (http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/debug_apps_dlls/).

Cheers!

-RDR

Message Edited by B O B on 11-05-2009 09:46 AM

[PJS]

As long as your making code changes... I would put a pause or prompt or execution pause on error, and display these errors on the screen.  Maybe insure that variables that your handing off to your QSDM handlers are displayed as well?

Also, although a day late and dollar short, if you follow the link in my signature, I have a template for a pretty solid, single loop QSM including a handler that includes logging and a fixed error case.  Surely not the only way of doing one, but provides a sound architecture which should help with debugging.  If not used directly, you may be able to improve your base design, once past this issue.

[Wire_Warrior · Accepted solution]

I have solved the problem I think (at least as far as testing to this point has revealed).   After I added in the ability to log the states passed to the QDSM's, I was able to determine that the program was "crashing" after I dynamically closed the front panel of the launcher.  My program was designed to close the front panel of the launcher then pop-up the front panel of the main UI.   My EXE is built on to contain the launcher with my other QDSM files being maintained externally in specific directories.  What appeared to be happening is that when the launcher closed its front panel and before the UI opened up the run-time engine would decide since there were no windows open it would close itself down.  This is my supposition about what may be happening any way.  I modified my code to changed the launcher window to hidden and delay for 1/2 a second to give the main UI a chance to start fully running.  This fixed the problem, or at least worked around it.  If someone out there can explain to me exactly what is happening I sure would appreciate it.

Thanks for all the help those of you who responded.  Your advice was very beneficial and certainly led me to a resolution faster.

Jason