Executable front panel can't be restored, but continues to run

[csalwen]

I have an executable that gets in a state where I can't get the front panel window to display.  It was running for a couple of weeks without any problem.  When the problem occurs and I click on the Windows taskbar the focus seems to shift to that executable, but no front panel window comes up.  Also, if I try right clicking on the taskbar I don't get the context menu.  I've tried going into the task manager and switching to this application, but that doesn't work either.  The task was built with Labview 9.01 and is running under Windows XP.

Anyone seen a problem like this?

Cindy

[Mark_Yedinak]

Did you check to see how much memory is being used by the application. Since you said this was running for a long time I suspect you have a memory leak (or are inadvertently letting something grow in size infinitely) and therefore the application Window can't load because the PC doesn't have enough memory available. the other posibility is that you have some infinite loop in your code with no Wait or other VI that will allow LabVIEW to do a context switch. This results in that loop (task) preventing LabVIEW from processing anything else while the loop is running.

Unfortunately for the application that is currently in this state the oly way out is to kill the task from the task manager.

[csalwen]

I wasn't the one to kill and restart it this time, but if I remember correctly from last time this happened, the memory wasn't big.  When I say its continuing to run, I mean that it continues taking data and writing files.  I don't have any loop it can be stuck in and still be doing these tasks.

This is an executable and there is one other Labview executable running on this machine.  I was told by NI support that the 2 are separate and that each executable has its own instance of the runtime.  Could the other executable be somehow causing the problem?  I don't see any problem with it.

[Mark_Yedinak]

Do you have an event structure in your code? What is the architecture of your code? If it a producer/consumer type architecture? If you have an event structure do you have events to catch and process the application and panel close events? Is it possible that you may have exited your loop with the event structure without notifying the parallel tasks that it has exited?

These questions are based on the assumption that you are using an event structure in your code.

[csalwen]

The code is a state machine, a case structure inside a while loop.  This continues to run.  There is a small event structure in one of the cases, but that case can't be the one executing, otherwise I wouldn't still be writing files. That case (and the event structure) will ony execute if there is a front panel button press, and the event structure has a timeout.

There are no events to catch and process the application and panel close events, but there are also no parallel tasks in this vi.  There is another executable running.

Your first answer made me think about the question of when a thread yields control of the CPU.  If you have this state machine structure, which is a while loop with a case structure in it, what is a single thread?  I've taken another look at this code, and I see that there is no wait in this main loop with the case structure in it.  There is also no other loops inside the case structure.  Would this cause a problem with the user interface?  There are things like serial write/read and file write in this case structure.  Wouldn't the thread release then?  And I am able to do other things on the computer, like open the file explorer.

Cindy

[Mark_Yedinak]

Without seeing your code it is difficult to give you any specific advice. I have given you th emost common things that happen in an application that result in the type of behavior you are describing. Any other suggestions would require seeing the code.

In light of that, is your state machine building arrays dynamically? Are you certain that your state machine itself is correct? Can it be getting into some mode where you no longer process the state that contains the event structure? If you don't call that state you will not process any of the events. I suspect that you are getting into some state that is causing you to stay stuck in one or a very few states without getting out and allowing you to call the state that has your event structure. Check all of your state transitions to make sure they are handling whatever decisions to determine the next state are correct.