Windows Aero theme and lockup

[John Niezgoski]

This is something I experienced some time ago on a project that really put me through the ringer.  We worked with NI R&D for 6 weeks at an elevated support level to finally get to the bottom of the issue.  The symptoms were my front panels (both in code and exe) would become 'detached' from the block diagram.  In other words, the GUI would appear locked while the code behind was actually executing just fine.  CPU was very low (3-5%) on all cores.  For a long-time monitoring application it was especially problematic as the user wouldn't interact with the GUI for long periods of time; the information on the display would simply quit updating and it would be difficult to detect the condition.

 

The solution ended up being something out of left field - the Windows Aero theme, which is default for Win 7.  R&D finally stumbled across this and was able to turn the issue on off by changing the theme away from Aero.  I gave a presentation at NIWEEK just recently and it seems I had 3 people in the audience that were experiencing this same/similar issue.  Therefore, I thought I would post this and maybe I could help some others.

 

All LabVIEW versions including 2012 are affected it seems.  I was developing in 2010 at the time, but R&D tried many versions to see if it was version-specific.

[shoneill]

I've had this problem, cool to hear there's a solution for it.

[Yair]

Here's something ironic - I liked this post in the hope that it will make it easier for me to remember this in the future, but when someone came to me with a similar problem recently (it might have actually been before this thread started) I didn't make the connection (although, to be fair, the problem there appears rarely and I had a DLL which returns a 1097 error to suspect. In fact, I still suspect it and will need to find the source of that error regardless of the UI issue).

 

I asked the user now to change the theme and I will see if it helps. Maybe posting this reply will help me remember it better for the next time.

 

In case it helps with diagnosing the problem, I can say that in my case the UI only fails to responds to user input and that it always happens in the same VI. The VI itself and the rest of the code keep running (which I can see because I put a loop iteration indicator on the panel and because the VI still updates the display based on stuff which happens elsewhere in the code and isn't controlled by pressing the screen).

[OlivierL]

Hi John,

 

Thank you for sharing this solution with us.  It affected one of my clients recently and the solution has worked thus far.

[Yair]

Update - My contact told me that they did change the theme after I asked him, but the problem was still happening. I was there a couple of weeks ago and saw that someone changed the theme back. I changed it to classic myself and looked at the log files for the past week today - they indicate that the problem didn't happen at all, so I guess that means that I also ran into exactly the same problem, so thanks for that.

 

I will give some more details again about what exactly I was seeing, in case it will help someone else as well - when this happened, the entire program was still running fine (I could see the iteration counter I added to the loop incrementing and the LED which corresponds to a DI was updating as I changed the DI), but the UI was completely unresponsive to mouse clicks, not just for the subpanel that the current VI was in, but for all the others subpanels as well and for the only button available at that point in the main VI. I had to crash the program through the Windows task manager.

 

The program would always get stuck at exactly the same point - you press "start" to start a process, the first screen of that process appears in the subpanel and bam - the UI is stuck. Most of the time this would work perfectly (and it worked just fine for a few years on a PC with Win XP, although there it was 8.6 and for the new machine it was upgraded to 2011), but on rare occasions, it got stuck.

[shoneill]

This seems to be a bit of a recurring problem.  We've seen the exact same problem.

 

I've recently also seen that a lot of the time on my machine the "Acquire Input" VI which uses DirectX (apparently) calls to get the mouse information loses all mouse clicks.  It reports mouse coordinates fine, but the clicks seem to vanish.

 

The thought that these issues could be interrelated only occurred to me today.  Could it all be related to a problem somewhere in the mouse input routines in LabVIEW?