LabVIEW crash with Copy.vi from network path (windows 10 1803)

[Ironman_]

This was working perfectly on windows 10 1709, LabVIEW 2015.

Yesterday I updated to 1803.

My softwares crash on startup. Investigations led to this Copy.vi that makes LV development AND runtime crash when source path is a network path (for example: \\server\configs\product_xyz

If Source Path is a local folder (C:\blabla), it works.

This was tested with failure on EVERY LabVIEW 2015, 2016 and 2018.

It crashes both development and on EXE (application builder).

I noticed that some files are indeed copied, then cursor turns busy, then crash.

No error output.

Pls investigate.

[Bob_Schor]

Can you describe what you mean by "crash"?  Is there a LabVIEW Error pointing to this sub-VI and function?  Does LabVIEW "hang" (become unresponsive), so you need to manually stop it?  Do you get a "We apologize for the inconvenience" message?

Since this happened with a new release of Windows, I wonder if there is some strange "permission" thing going on.  What happens if you use Windows Explorer to do the copy -- does it succeed, or are you "blocked" at some point?  Are all of the machines involved running the same OS and version of the OS?

I'm away from my office, working just on a Laptop (with Win 10 x64 1803), so cannot directly test.

Bob Schor

[Ironman_]

Can you describe what you mean by "crash"? 

CRASH = both in LabVIEW development enviroinment and in exe (built with application builder), the copy vi (with a network path as source input) copies some files, then I see cursor turning "busy" (spinning circle for 2 seconds), then it quits abruptly. No errors, just a kill task.

If I restart developement, I just get the recover windows, but no details about the error.

This bus is sistematic, it happens always, just create a vi like in my first post, just call copy.vi with input "\\server\folder"

Is there a LabVIEW Error pointing to this sub-VI and function?

NO.

Does LabVIEW "hang" (become unresponsive), so you need to manually stop it?  Do you get a "We apologize for the inconvenience" message?

NO, LV just quits itself. I think the OS (Windows 10) quits it, that is "kill task", because some low level pointer, or unmanaged error.

Since this happened with a new release of Windows, I wonder if there is some strange "permission" thing going on.  What happens if you use Windows Explorer to do the copy -- does it succeed, or are you "blocked" at some point?  Are all of the machines involved running the same OS and version of the OS?

I can perfectly copy folder and files from that network share folder.

there is no permissions problems

I can use windows explorer fine.

My productions machines are with Windows 10 1609, 1703 and 1803

If I build an EXE ---> it works on 1609 and 1703, but copy.vi CRASH only and always on 1803

[rolfk]

And what is the server running? What Windows version, or is it possibly a Linux computer with Samba? 

[MichaelBalzer]

What if you map a network drive, then try to copy to the network drive? Does this also crash?

[Ironman_]

Windows server 2016

Can't map network drive, I have 150 software on production already deployed.

I need to copy (recursiverly) a shared folder like \\server\folder  into C:\myfolder

[rolfk]

It still would be a helpful test to try if the problem also happens with a mapped network drive!

[Ironman_]

There is something REALLY odd going on.

I think the bug is in the RECURSION.

If I use Copy.vi to copy one single file from network share, it works.

So I made a VI that uses Copy.vi only to copy single files , and use manual recursion for the subfolder.

This is the algorithm:

https://docs.microsoft.com/en-us/dotnet/standard/io/how-to-copy-directories

I took the time to implement it with LabVIEW.

Test is as you like, with N subfolders.

My VI has "show front panel", and you can see that recursion is ENDED.

BUT

with share folder as source, I see INFINITE clones windows.

If I don't set the "show front panel", I get this windows after a  while:

I don't understand why. It has NO SENSE.

The algorithm is finite, and it's demonstrated by the local folder input.

Why LV goes nuts with network folders??!?!?!?!??!?!?!?!?!

[RavensFan]

Is there any chance there is a shortcut in those folders that point to other folders?  Particularly ones in the same folder tree?

[GerdW]

Hi Ironman,

are there any links in those folders?

I don't understand why. It has NO SENSE.

Can you implement a logfile function in your DirectoryCopy function?

Like writing source and destination path to file each time that VI is called? This way you can check how many recursions are created and which path it is stopping.

Btw. when creating recursion you ALWAYS should limit the recursion depth to reasonable values - and not trust on any expectations…