LabVIEW executable takes a long time to open File Explorer

[CDuck]

I am deploying a LabVIEW executable to various PCs with an Installer.

• The executable works properly all the time on my dev PC
• On Test PCs, the executable works properly at first.  However the longer that the program is open, the longer it takes file explorer to open (Up to a maximum amount of time, roughly 10 seconds)
• All PCs are the same hardware wise, notable differences are in the software:
  • Dev PC has LabVIEW development environment
  • Test PCs require Admin rights to open the executable.  Otherwise it doesn't have rights to read/write disk files
• Test PCs ran with out an issue prior to a patch I did that involved adding a numeric control and text changes to string constants. I right clicked the pre-existing executable in the labview project tree and selected build.  Did the same thing with the installer after the executable was built.

Any ideas as to what could be the problem?

[RTSLVU]

---

@CDuck wrote:

Any ideas as to what could be the problem?

---

Not without seeing your code.

[altenbach]

---

@CDuck wrote:

• On Test PCs, the executable works properly at first.  However the longer that the program is open, the longer it takes file explorer to open (Up to a maximum amount of time, roughly 10 seconds)

---

• What has explorer to do with your executable?
• Since you say "works properly at first", does it work "improperly" after a while or is the problem isolated to windows explorer?
• How are you opening file explorer? Are you talking about a file dialog opened by the exe or something else? If this is a file dialog, how is it triggered?
• How is memory and CPU use over time?
• What is your code architecture?
• ...

As has been said, it would really help to see some code.

[thols]

I would go back to the version that worked and see if it still works like it did before you made the change. If it doesn't, then something changed in Windows or outside of your code. If it works, then you know it is in your code.

Is the CPU usage very high? Maybe you have a much faster CPU and don't experience the same behavior as on the test PCs. Maybe your fix introduced a bug hogging the CPU.

[CDuck]

The task manager was not showing anything abnormal.  I have heard from users that this issue has occurred on older version, less often.  Now it seems to happen more often.  Very confusing, resolved with non-code related solution below, yet there is clearly something that has changed whether it be installation method or code because it is happening more often than before.

It seems I am not able to reproduce the issue after unmapping the network drives as mentioned here. 

https://forums.ni.com/t5/LabVIEW/File-Dialog-Box-often-takes-a-long-time-to-execute/m-p/2454400/high... 

[rolfk]

Sounds

---

@CDuck wrote:

It seems I am not able to reproduce the issue after unmapping the network drives as mentioned here. 

https://forums.ni.com/t5/LabVIEW/File-Dialog-Box-often-takes-a-long-time-to-execute/m-p/2454400/high... 

---

That sounds about right. It seems LabVIEW uses some Windows functions when using the OS provided file dialog to prepare the dialog and then get back the user selected path after the dialog was dismissed that somehow deep down in the belly of Windows shell32, the component that implements your entire desktop and explorer process, attempts to enumerate the drives or something similar and that enumeration stumbles over a fixed, non-changeable timeout (aside maybe from some obscure registry hack) whenever it encounters a drive that is connected to a non-accessible network path. The Windows shell is full of such "unfixable" timeout delays when using some functions that intuitively should not even have to bother about such things as unreachable network shares or printers.

My Explorer process needs to be reset (killed) regularly as it tends to get into a fit about file transfers to and from network attached devices and sometimes the good old power cycle is the only thing that gets Explorer back to behave properly. I have resolved to live with it and that is totally independent of LabVIEW. In fact I have surprisingly few problems with LabVIEW itself.

[JÞB]

---

@CDuck wrote:

The task manager was not showing anything abnormal.  I have heard from users that this issue has occurred on older version, less often.  Now it seems to happen more often.  Very confusing, resolved with non-code related solution below, yet there is clearly something that has changed whether it be installation method or code because it is happening more often than before.

It seems I am not able to reproduce the issue after unmapping the network drives as mentioned here. 

https://forums.ni.com/t5/LabVIEW/File-Dialog-Box-often-takes-a-long-time-to-execute/m-p/2454400/high... 

---

Just spitballing.  (but sometimes I even surprise myself)

Provide a Start Path input to the prompt dialog.  It might help your situation and almost certainly provide a better UX anyway. 😉

I'll let rolfk explain why that might work, or give me a lesson on why I just opened my mouth and proved myself ignorant 🙃

[rolfk]

---

@JÞB wrote:

Provide a Start Path input to the prompt dialog.  It might help your situation and almost certainly provide a better UX anyway. 😉

I'll let rolfk explain why that might work, or give me a lesson on why I just opened my mouth and proved myself ignorant 🙃

---

That might indeed improve things a lot. With a defined AND valid start path the file dialog does not have to do as much when initializing itself and may even skip some of the enumeration of available resources such as disk volumes. It would however likely influence the startup time of the dialog when invalid network shares are still mounted, not so much the return time of the dialog after the user selected a file.

But who knows! Most of the functionality in Shell32 was an afterthought that tried to centralize all the functionality from the File Manager replacement called Explorer, the shell integration from Internet Explorer and a few other Microsoft internal projects back in Windows 95/98/2000 times. It does quite a few things very differently than the underlying NT kernel would want to, and put the virtual Desktop structure on top of the lower level file system that in fact turns things on its head in many ways. While most other systems use file system extensions to handle such things, the Windows Shell invented an entire DCOM based virtual file system on top of the real file system to try to hide that Windows was still DOS based and operating with a very limited amount of drive letters that could not be extended in anyway without totally throwing away much of the internal workings at that time.

[JÞB]

---

@rolfk wrote:

---

@JÞB wrote:

Provide a Start Path input to the prompt dialog.  It might help your situation and almost certainly provide a better UX anyway. 😉

I'll let rolfk explain why that might work, or give me a lesson on why I just opened my mouth and proved myself ignorant 🙃

---

That might indeed improve things a lot. With a defined AND valid start path the file dialog does not have to do as much when initializing itself and may even skip some of the enumeration of available resources such as disk volumes. It would however likely influence the startup time of the dialog when invalid network shares are still mounted, not so much the return time of the dialog after the user selected a file.

But who knows! Most of the functionality in Shell32 was an afterthought that tried to centralize all the functionality from the File Manager replacement called Explorer, the shell integration from Internet Explorer and a few other Microsoft internal projects back in Windows 95/98/2000 times. It does quite a few things very differently than the underlying NT kernel would want to, and put the virtual Desktop structure on top of the lower level file system that in fact turns things on its head in many ways. While most other systems use file system extensions to handle such things, the Windows Shell invented an entire DCOM based virtual file system on top of the real file system to try to hide that Windows was still DOS based and operating with a very limited amount of drive letters that could not be extended in anyway without totally throwing away much of the internal workings at that time.

---

So, worth a shot!  If you want suspenders with that belt, you can toss in a test FIle or Folder Exists.vi on the default start path then handle disconnected drive exceptions more intelligently.  All good for preventing damage to the mouse from excessive pounding on the desktop (Better UX)

Thanks for the lesson Sir Rolf!

[CDuck · Accepted solution]

OK So I figure I should come back and update this thread because we started seeing the issue again even after unmapping the network drives.  We later realized that the issue of slow file explorer was actually only occurring when we had our hardware communicating with the program.  Thus I thought the problem was solved at first, this also explains why it worked on my dev PC, as I only have simulated hardware.

Here is what solved my issue:

• Opened NI package manager, there was a notice at the top to install updates for package manager
• I notice something interesting, NI Package Manager is not showing Runtime 2020! Yet I built the code on LV 2020
  • After update, LabVIEW runtime engine 2020 was now showing
  • Issue still persists
• Back into NI package manager, I hit repair all

FIXED!

Here is what I think happened.  When I was patching a bug in this software, I took the code that I developed on LabVIEW 2019 and imported it to LabVIEW 2020.  When I finished patching I simply right clicked the existing exe and installer and built it.  This might be the source of the issue.  The other potential issue could be that NI package manager was not auto updating on target PCs.  I can't say for sure what the source of the issue is, but I know what solved it