Built Application Occasionally Freezes on Windows Open/Save Dialog

[mje]

I'm wondering if any of you see this behavior. I have an application that from time to time locks up when attempting to show the Windows open/save dialog:

 

 

As far as I can tell if this happens I'm at a permanent deadlock: I've never seen the application recover. This happens very rarely so I don't have a use case to reproduce or troubleshoot, but I've seen it happen a few times and some of our customers have complained about it as well. I only mention it now because it just happened to me today...

 

I'm using the File Dialog express VI (cough) to get the prompt. Has anyone else seen this behavior or possibly know how to prevent it?

[ShaunR]

What is the default path or current path? Is it pointing to a networked drive? Are all drives actually available that are mapped?

I've seen in windows (not specifically LabVIEW) that file dialogues can be "flakey" when network locations are invoked on drives that are unavailable or NAS locations that are asleep. Basically any network access failure will bring windows to it's knees and is usually facilitated by a file action (browse or open/save). When a file dialogue is invoked, it will try to enumerate drives and you only need one to not respond.

 

If you look carefully, you will see that all the indicators are there, they are just not populated (they appear as "discolourations")-classic symptom of struggling to enumerate the drive list. You may find something in the windows event log.

Edited June 22, 2013 by ShaunR

[mje]

Yeah, I'm afraid it might be a Windows and not a LabVIEW problem as well. Afraid because then there's probably nothing I can do about it. The default path in my case likely isn't a network drive, but it could be a USB location. I say "probably" because for my various file dialogs I store the last used path in a feedback node so each dialog starts in the last used location, so I can't say where that dialog was trying to point to initially.

 

When this happens the first thing I do is rush to another application and see if I can reproduce the issue, but I'm never able to.

[ShaunR]

Yeah, I'm afraid it might be a Windows and not a LabVIEW problem as well. Afraid because then there's probably nothing I can do about it. The default path in my case likely isn't a network drive, but it could be a USB location. I say "probably" because for my various file dialogs I store the last used path in a feedback node so each dialog starts in the last used location, so I can't say where that dialog was trying to point to initially.

 

When this happens the first thing I do is rush to another application and see if I can reproduce the issue, but I'm never able to.

 

Well. It's fairly easy to eliminate if that is a suspected problem. Just put a check path exists and log the path before the dialogue is invoked. Then, if you see the dialogue again, you will be able to see whatf the path was and whether the app thinks it exists. You can them paste it into a browse window and see if explorer complains.

[mje]

Well this is interesting, on my development computer, my built application has been rendered unuseable by this bug. The word "built" is important because that means nothing has changed with respect to the logic that makes the call to the dialog.

I now start my application, do a File Open command, and the dialog freezes. The behavior persists even after a full system reboot. It is obvious that some information is serialized permanently for the dialog because it opens to a non-default size for example. I'm not in control of this information, so either Windows or LabVIEW is serializing it and something about it is corrupt and freezing the modal dialog, in turn freezing my application.

Argh. This is going to be annoying to debug since it's a released application with no debug info.

[mje]

If only it were that easy. The first thing I did was unmap all of my network locations and disconnect everything I could with a "net use" command. We have a "My Documents" library which is remote and I left intact. Out of desperation I've also run the System File Checker tool (sfc /scannow from an elevated command prompt) but nothing was found.

 

Later today I'll try to do a full uninstall, clean the application's file system location out manually if it remains, and reinstall in hopes that whatever that serialized information is will get nuked. An hour of google searching has turned up no other hints. I can't find any documentation on what data is stored, other than people pointing out the same thing as me-- that data must be stored somewhere and it appears to be application and folder specific.

[mje]

Nice read indeed, thanks!

More info:

Renaming the executable "fixes" the problem, if I run the application once I've renamed the exe and I present the open dialog, it appears as the default size, in the default position. However shutting the application down, renaming it back to the original name and trying again results in the same problem.

Changing the path of the executable (but not the name) has no effect. If I rename the folder containing the application, the freezing behavior persists. It appears the serialized data is tied to the image name.

Uninstalling the application, ensuring the folder which contained the application is gone, rebooting, then reinstalling does not clear the problem either. So it appears whatever data is being serialized is not removed during uninstallation. I'll add that our installer/uninstaller is created by a third party application due to a defect in the NI product which prevents us from using it.

 

At this point I'm hesitant to call renaming the executable a workaround: yes, it clears the bug, but should a customer inquire about this is telling them to go to their PF folder and rename an EXE really a good "solution"? Obviously no...

I'll post here if further spelunking turns up clues and/or fixes.

[todd]

What about the registry? Procmon lets you filter on "Process Name" (<yourapp.exe>) and "Operation" (RegQueryKey). Dropping a single File Dialog on a blank VI and running it shows lots of key queries - not that they're all related to File Dialog...

[mje]

What about the registry? Procmon lets you filter on "Process Name" (<yourapp.exe>) and "Operation" (RegQueryKey). Dropping a single File Dialog on a blank VI and running it shows lots of key queries - not that they're all related to File Dialog...

 

Well.

 

This morning I got into work, fired up my application and tried to open a document, sure enough the dialog froze. Excellent, I'll use procmon to try to figure out what's wrong.

 

Right.

 

Open my app. Fire up procmon. Start capturing. Try opening a document. And everything works. I. Just. Don't. Know.

 

I reproduced this bug dozens of times over the last few days, in fact I have not been able to use my application on our workstation all week due to the bug. And the first honest attempt at capturing information about where things are going wrong and the bug vanishes. Sigh...

 

Well, procmon did capture literally tens of thousands of events when I triggered the dialog, so at least if the problem creeps up again I now have a needle in a haystack to look for, rather than nothing at all to go on.

 

Still not sure how to debug this next time a customer has this issue. I really want to know if it's something I'm triggering from my LabVIEW code. I suspect not, since it crept up on a system that had functioned for over a year, and the problem survives reinstalls, reboots, and clearing any serialized data that I (directly) access.

[Yair]

I don't expect that this would help, but it could be worth a try - go into the WindowsPrefetch folder and muck about. Delete the relevant file. Delete all files. Go crazy (actually, scratch that. You should probably not go crazy, and you probably also want to be careful. My understanding is that nothing bad will happen if you delete stuff there, but I'm not a Windows expert by any stretch of the imagination).

 

I have no reason to believe this will help, but it's the only mechanism I can think of which is affected by the EXE name, and maybe it caches some kind of dependency which screws things up? You might want to keep the original file so that it can be analyzed.

[Ton Plomp]

I have noticed that a symlinked folder in a library where the symlink target does not exist (non-available network folder) can cause browse dialogs to load slower.

 

Ton

[mje]

Resurrecting this thread, the problem re-emerged on the same application today. I would start it up, execute my File > Open command and the dialog would appear half-drawn and deadlocked in a non-default position and size. Repeat this a few times to the same result, the dialog always appears in the same location only partially rendered.

 

Fire up my application again, then start up procmon.exe with appropriate filters in place to catch only stuff from the target PID and...the problem goes away. The dialog appears in the default centered position on the active monitor and is responsive. From this point on the application works normally with or without procmon.exe running.

 

Maybe there's some underlying race condition in opening that dialog and setting position/style/etc that deadlocks, but when procmon hooks into things timing may be nudged just enough to allow dialog initialization to execute to completion. Maybe it's a security thing and with the procmon hooks in place default initialization data is used.

 

I really don't know. Grasping at straws here.

 

I wish I knew if it was LabVIEW or Windows that is responsible for serializing that data. Let's be clear, data most definitely is being serialized: window size, position, and style are consistent each time the dialog is called. This information survives application restarts, system restarts. It persists any scope over which I have control.

 

This data must exist somewhere and is causing me grief. I'd like to have way to clear it in situations like this. Relying on procmon.exe to "nudge" things enough to sort things out is most definitely not a solution that is acceptable, even if it is what works (for an unscientific sample size of two).

 

Well, at least I didn't lose a week this time around.

[ShaunR]

Still no good advice as to what to look out for. (You haven't said what version and bitness you are seeing this behaviour in).

 

One of the first things I do when I get peculiar behavior like this is load it up and do a mass compile in the other bitness and/or do a save for previous version. Sometimes extra problems pop out like complaints about a corrupted VI (happened last week to me), a conflict that wasn't being raised before (happened about 3 months ago) or it will go off hunting for a VI it suddenly decides it needs which you removed during the last ice age. Long shot, I know, but it has caught some things in the past..

Edited October 20, 2014 by ShaunR

[mje]

The application in question was compiled in LabVIEW 2011 64-bit (Windows). I can't recall what level of patches or service packs were used to create it.

[ShaunR]

The application in question was compiled in LabVIEW 2011 64-bit (Windows). I can't recall what level of patches or service packs were used to create it.

 

Patches only fix the known issues but I've found they have never fixed my issues...lol

 

2011 was renowned for funnies. I had one code base that would compile fine in 64 bit but not in 32 bit.  - the IDE just disappeared. On a couple of machines, the debug highlighting wouldn't highlight unless you set one of the VIs on the diagram to "Suspend When Called" and one of my colleagues reported that his LabVIEW ini file kept on getting wiped out.

 

Is this a mature product? Are you still using 2011 for new projects? If you have moved on and it only happens in 2011, then I would suggest just calling the windows dialogue directly with API calls and put a note in the documentation. Even if you found a reproducible way of showing NI, it is unlikely they will address it and the best you could probably hope for is one of the perpetual CARs.to go with those from 8.x.

 

Not very helpful but maybe solace in shared misery with the "Stability and Performance" release that was neither

[mje]

Hah, yeah, this is a mature product. I had considered yanking the express VI call in favor of the direct Win API calls when we iterated the development cycle to 2013 but have yet to see the issue since we've moved on.

 

Speaking of which we are days from freezing the code base on this cycle. Timely resurface of this bug: early enough to make me nervous, but late enough that I can't do anything about it. *Sigh*...I regret not moving to the API since this is a Windows-locked application. At least the bug surfaced on the legacy 2011 build, I still have no indicators this is an issue with 2013.