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

[asbo]

Perhaps the easiest way to start debugging is throw some state loggers which will immediately write to disk. This way, you can at least get an idea of which SM is where when the code quits. You could also put loggers onto your error wires and see if there's anything suspicious going on there.

[Tomi Maila]

There is a patch for LV 2009 you should add. Maybe it fixes the problem. If not, then go on trying to debug the issue.

[Wire Warrior]

There is a patch for LV 2009 you should add. Maybe it fixes the problem. If not, then go on trying to debug the issue.

Thanks for the suggestion...I downloaded the f2 patch and recompiled yesterday. Didn't help the problem.

Jason

Perhaps the easiest way to start debugging is throw some state loggers which will immediately write to disk. This way, you can at least get an idea of which SM is where when the code quits. You could also put loggers onto your error wires and see if there's anything suspicious going on there.

Thanks for the suggestion, I have some error logging in place but having the state machines log behavior I had not thought of.

Jason

[Wire Warrior]

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

[asbo]

I believe your reckoning on the RTE quitting out because there were no open FP is correct.

Rather than have an arbitrary wait, you should use a notifier (or the like) so your main UI can signal to the launcher when it has actually opened. If you ever have to troubleshoot on a slower machine, you'll thank yourself

[Ton Plomp]

after I dynamically closed the front panel of the launcher.

Jason

I believe your reckoning on the RTE quitting out because there were no open FP is correct.

Rather than have an arbitrary wait, you should use a notifier (or the like) so your main UI can signal to the launcher when it has actually opened. If you ever have to troubleshoot on a slower machine, you'll thank yourself

Good idea, another option is not to close the main FP, but set it's state to hidden!

Now after closing all child process you should close the FP of the main VI.

Ton