LabVIEW
LabVIEW sure loves to crash for stupid reasons.
I have these (almost) deadlocks regularly. But it is not limited to LabVIEW. What I have found as common nominator in every case is VmWare. It's not a total deadlock in the sense that sometimes other applications keep working for a little while but eventually completely freeze too. That includes Teams, Chrome and other applications. And after 30 seconds or sometimes a minute, all the applications suddenly refresh and everything is back to normal. Without VmWare active, I have not encountered these lock ups yet, but I work a lot with VmWare so not sure this is a significant indication. Once this starts not even Ctrl-Alt-Del seems to make a real difference. Once everything comes back it will then switch to the lock screen that you get with Ctrl-Alt-Del, but usually that doesn't happen immediately.
@Intaris wrote:
Rolf, you get a full system lockup?
Not immediately. One application starts to freeze (usually LabVIEW as that is were I work most in) then I try to switch to another, that still seems to work for a few moments, and so on until every window on the system is frozen. Usually all the VmWare windows freeze first, then the rest. Then I can wait. Somewhere it returns to normal after 30 seconds or a minute, sometimes I get impatient and press Ctrl-Alt-Del but even that usually doesn't immediately react. Then suddenly every window on the system refreshes in a frenzy and everything seems back to normal, with the lock screen enabled if I was impatient enough to press ctrl-alt-del. Sometimes I simply go and fetch a coffee and by the time I return, things are usually back to normal.
I can't really comment on the refresh disturbing the Z order very much. I have a compulsive disorder that makes me close windows more often than not, so I seldom end up having lots of VIs in LabVIEW open. Altogether there are usually several applications open however, including one or two browser windows with usually several tabs. Outlook, Teams, Notepad++ and sometimes Excel or Word belong to that list too. And they are all affected, although often they seem to all still be kind of responsive for a short while when that condition occurs. I've tried various things including tweaking the VmWare settings but so far I haven't found anything that seems to make a definitive difference.
@tst wrote:
Yes, that definitely happens when running on a native OS. I assume that's more of a LabVIEW bug. I'm guessing LV or Windows sees the freeze and tries to do a kind of reset (maybe they're then ordered by window title or handle, but I never tried to figure out the new order).
That's probably a good guess. A Windows application needs to continuously call the GetMessage() Windows API function in a loop to query for new events (mouse, keyboard, devices, OS, etc, etc). Windows has some monitoring logic in there that detects if an application is still calling this function regularly. This loop runs in the LabVIEW root loop and main thread. And Windows did not like this function being called from different threads so this design was mandated. I suppose that the Windows NT API since has been made fully threading save even here, but that will certainly come at a cost as there will be semaphores and/or mutexes to protect this and there would be some performance decrease if these functions were not called from the same main thread all the time.
Anyhow, Windows will usually redraw the window frames of an affected application in a shaded color when it detects that the processes main window loop has stopped calling this function and eventually post the message box that the application has been getting unresponsive and you can wait if it returns or abort it. But it's likely that there are situations where it considers that a force redraw of all windows might be also an option.
But the lock I usually see goes a lot deeper and affacts sooner or later every single application in Windows. And knowing how deep VmWare likes to hook into Windows to do its thing, I can very much envision that one of these hooks is responsible, most likely with one of its device drivers that somehow gets in a mutual exclusion lock until the underlaying function to communicate between the host and the virtual client instances eventually times out.
