Event Log Error Messages

[Double_D]

I have a rather large CVI program that is in continous operation on a server computer.  In investigating some occasional hiccups with the program, I looked at the event log for clues.  There are several messages in the queue with the following info:

LabVIEW information:

Error: 404 "Not Found" for "national instruments/ni-rpc/interface/eadfc80d-1e6f-425b-8986-12ccef98f646", file "c:/program files/national instruments/shared/ni webserver/www/national instruments/ni-rpc/interface/eadfc80d-1e6f-425b-8986-12ccef98f646": Can't access URL I don't think this is causing any of the problems I am seeing, but I am curious as to what the meaning of this error is. The error I am seeing intermittently is that when a panel is minimized and made invisible (this occurs when a message box is activated), the panel doesn't always return to the correct state.  It comes back as a blank white rectangle, which prevents user interaction with the program and requires the program to be killed.  The following error in the event log may be related to this issue (although I only found this once, even though there are a few occurences of the problem): The description for Event ID 0 from source CVI cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: [15:02:18.149] [FATAL] [WSetVisibleEx] [..\mgsource\window2.c:1536] Assertion failed: 0 (Window moved while being made visible) If anyone could give some insight for either of these errors, I would appreciate it.  Thanks.

[Daniel-E]

Hey Double_D,

I'm not sure why you'd be seeing the 404 error--what kind of communciation is your program doing with other processes? Since it's on a server, I imagine there is some sort of communication with client machines. Is it possible that this is where the error is originating from?

As for the issue with the window when you minimize and maximize it, I'm not sure why we'd be seeing that--I'm asking around to some of my colleagues to find out what the reason for that could be.

[Double_D]

We are using a server because the program is running a 24/7 critical process.  The functions of the computer include reading data at 10-second intervals from a scanner/picoammeter combination, processing the information received, providing sample status data and receiving sample input parameters from users, and writing data and status information to disk (local and/or on a mapped network drive).  According to the event log, whenever these LabVIEW errors occur, they occur in bunches with the same timestamp (18 - 42 such errors at a given time), with 7 occurrences over the last couple of months.  Based on the timing of the errors, these don't appear to be related to the display problem.  

This is the code that runs when the screen problem is observed:

int CVICALLBACK DisplayMessagetoUser (void *userData)
{
    struct pairStrings *rcvdData;
    int ret_val = 0;
    
    rcvdData = userData;
                                                                
    ret_val = SetPanelAttribute (dataHandle, ATTR_DIMMED, TRUE);
    /* If an error is returned, write to the logfile and try to recover */
    if (ret_val)
    {
        WriteLogFile ("Error when dimming data panel!\n");
        SetPanelAttribute (dataHandle, ATTR_DIMMED, FALSE);
    }
        
    SetPanelAttribute (dataHandle, ATTR_WINDOW_ZOOM, VAL_MINIMIZE);
    /* If this call returns an error, do the same as above */
    if (ret_val)
    {
        WriteLogFile ("Error when minimizing data panel!\n");
        SetPanelAttribute (dataHandle, ATTR_WINDOW_ZOOM, VAL_NO_ZOOM);  
    }
    
    /* Set the dialogActive flag so that ProcessData does not redraw the main
       panel until the dialog has been dismissed, then play a wave file and
       display a message to alert the user. */
    dialogActive = TRUE;
    CVI_PlaySoundEx (rcvdData->sound, TRUE, TRUE, 0, 1);   
    MessagePopup ("", rcvdData->message);
    CVI_StopCurrentSound ();
    
    /* Return the main panel to its normal state */
    dialogActive = FALSE;
    SetPanelAttribute (dataHandle, ATTR_DIMMED, FALSE);
    SetPanelAttribute (dataHandle, ATTR_WINDOW_ZOOM, VAL_NO_ZOOM);  
    
    return (0);
}

The data panel is minimized so that the message box doesn't get hidden behind it when the main process updates the display.  No errors are returned by the SetPanelAttribute calls.  Normally, the data panel is restored correctly.  On multiple occasions, however, the panel returns as a white or light blue rectangle with no information displayed and the user is unable to interact with the panel.  All of the other panels are fine and the program seems to be working fine in all other respects, but it is useless without this panel.  We have to shut the program down, restart it, and restore the data for running samples.  One thing that I see that I need to do is check the return values of the SetPanelAttribute calls that restore the window.

[Daniel-E]

Double_D,

One thing I found that we sometimes recommend for this type of thing is to set the following attribute on your main panel:

SetPanelAttribute (mainUIPanelHandle, ATTR_MINIMIZE_OTHER_PANELS, 1);

This makes sure that all other panels are minimized when the main panel is minimized. I'm not sure if this will have the desired effect on your application, but it might prevent the issues we're seeing when you try to restore.

It would also definitely be a good idea to check the error status on that restore to make sure an error doesn't occur at that point in the process.

Finally, are you using the Windows Aero interface on your server? That's something that we'd like to know as we research this further.

[Double_D]

I have been troubleshooting this problem on my desktop PC.  This machine is running Windows 7 as opposed to Server 2008.  I have also been running the program in the debugger.  I haven't seen the exact same behavior as that observed on the production server, but there have been some inconsistencies that are similar.  First, the call to SetPanelAttribute (dataHandle, ATTR_MINIMIZE_OTHER_PANELS, 1); doesn't seem to work as expected.  The other panels were not minimized by this call.  I did manually minimize the other panels with SetPanelAttribute calls for each panel.  This seems to always work for these panels.  For the main panel, however, I have seen 3 different scenarios.  Most of the time, this panel is minimized and comes back when I dismiss the dialog box for the event alarm.  On other occasions, however, the panel is not minimized - it remains on screen with the message dialog box "on top" of it.  After dismissing the dialog, all panels return to normal.  Less frequently, the main panel is minimized but isn't restored when the other panels are.  Upon restoration, the panel appears in the upper right corner of the screen in a minimized form that requires manual resizing to return to its normal state.

Are there any function calls that operate on a panel that would cause a minimized panel to be restored?  For example, if I call SetActiveCtrl for a control in a minimized panel would that restore the panel?  It doesn't seem like it should, but I am trying to understand if there is anything in my code that could be causing this strange behavior.  I don't think this particular section of code has changed in quite some time, though.  The CVI version has changed.

[Double_D]

I forgot to add that we are not using the Windows Aero interface on the server.

[Anjelica-W]

Double_D,

I need to look into this issue some more to determine some next steps or additional things we can troubleshoot.

What version of CVI do you have now compared to the previous version where you did not experience this problem?

While setting ATTR_WINDOW_ZOOM to VAL_NO_ZOOM should restore the window, do you notice any difference in behavior by the setting the same attribute to VAL_MAXIMIZE?

[Double_D]

I have recently upgraded from CVI 2010 to CVI 2012.  I have had to save the .uir file in CVI 2009 format, however, in order for the program to run correctly on the server machine (I can't remember what the issue is right now; this was prior to the upgrade).  This display problem predates the CVI upgrade, however. 

If I use ATTR_VAL_MAXIMIZE, the behavior on my desktop machine is similar to before, with the exception that the data panel must be resized to see the other panels (since it takes up the whole screen).  I have put in some diagnostic code to call GetPanelAttribute to check the value of ATTR_WINDOW_ZOOM.  When the data panel is minimized correctly, ATTR_WINDOW_ZOOM is 1.  When it is not minimized, it is 0.  I haven't yet found anything in my code that changes this value from 1 prior to dismissal of the message dialog box, but it is changing on certain occasions.  Is there a way in the debugger to see what has happened in other threads when the condition occurs?  I set a breakpoint to catch this, but the stack trace only let me look at the thread where the breakpoint was located. 

[Anjelica-W]

You should be able to select the variables and call stack of the thread you wnat to view from the Threads window. You can access it by going to Window >> Threads. Please refer to the following link for more information.

http://zone.ni.com/reference/en-XX/help/370051V-01/cvi/usermanual/sierunthreads/

[Double_D]

I really wanted to go into the past and look at what was going on in threads that may have exited prior to the breakpoint, which doesn't seem possible.

I discovered why ATTR_MINIMIZE_OTHER_PANELS doesn't work consistently.  According to the CVI help, if ATTR_TASKBAR_BUTTON_VISIBLE is FALSE, then the other panels are not minimized.  I explicitly set this value TRUE near the beginning of main(), but it is FALSE (at least part of the time) when I attempt to minimize the other panels with SetPanelAttribute.  I'm not sure what would reset this value.  There is nothing in the code that does this explicitly.

I may have found the solution to the problem, however.  A secondary thread in my program is called every 10 seconds.  This thread collects data from instrumentation, does some processing, and then updates the user interface.  One of the function statements in this thread calls SetActiveCtrl for a control on the data panel.  This apparently restores the panel, which had previously been minimized.  If SetActiveCtrl is called before the message popup dialog box is dismissed, then the data panel is restored.  After putting a flag variable in the message display code to prevent the data panel from being redrawn until after the dialog box is dismissed, I have not seen the aberrant behavior.  I don't know yet if this code will fix the problem on the production server as well, though.  It seems to be the same problem, but the symptoms are slightly different on the Windows 7 machine running the code under the debugger.  The other issue is that even if the data panel is restored by SetActiveCtrl, that doesn't explain why the panel is not restored correctly on some occasions (i.e., the panel appears as a white rectangle on the screen, making user interaction impossible).