Import-Module with UNC path crashes PowerShell Studio 2016

[blinkfink182]

Product, version and build: PowerShell Studio 2016 5.2.127
32 or 64 bit version of product: 64-bit
Operating system: Win7 Enterprise
32 or 64 bit OS: 64-bit

Very simple to reproduce this issue. Our company (we've actually purchased the software, but I have not applied the license to my install yet) has several custom PowerShell modules that we use in our scripts, and all the scripts we have written import them via "Import-Module \\path\to\module.ps1" - any script with this line in it crashes PowerShell Studio with a pop up error "Object reference not set to an instance of an object." If I copy the same module file to my local hard drive (C:\Temp for example) and run "Import-Module C:\Temp\module.ps1" it works as expected.

[blinkfink182]

This looks to be related to our company's internal redirection of profiles. I tested using a local account on my workstation (without network redirection) and was able to open the files.

[blinkfink182]

Further details - this ONLY happens when Source Control is turned on (we use Team Foundation Server). If that is turned off, the problem goes away. The problem also went away if I turned off the option for "Enable dot sourcing PrimarlSense". Obviously these are two critical features we need. Is there a log somewhere I can send you to help troubleshoot this?

[davidc]

Thank you for reporting the issue.

When you get the exception dialog, please expand the details post the contents. This will help us locate the source of the issue.

[blinkfink182]

Unfortunately, it's just a simple pop-up. No details like I've seen others have with a stack trace. Is there a log file somewhere that could help narrow it down?

[davidc]

Unfortunately, this isn't logged. When you get the popup does the application stop working or does it continue to run?

We will try to reproduce this on our end.

[blinkfink182]

If I hit "OK" on the pop up, it repeats, seemingly forever. I've hit OK upwards of 30 times and it continued, so I wind up just killing the app via Task Manager. I can share one of the files that this happens with if that will help.

[davidc]

Interesting.

I have a few more questions for you:

1. Is the script part a project or just a stand-alone file? Note: You can zip and upload the script or project here:
https://www.sapien.com/support/upload

2. Are you able to check-in file and check-out files without issue?
3. What happens when you toggle the following option:

Options->General->Enable remote file status check

Thank you,

[blinkfink182]

1. Stand alone files. I haven't started working with projects yet.
2. Yes, I can check-in and check-out fine. Although accessing a file's history gets a little weird (I can open a separate issue for this if you want).
3. I checked the options to enable source control and the "dot checking" I mentioned previously, and then disabled the option you mentioned and the issue is not occuring any longer.

[Alexander Riedel]

Is the path to the module a personal path? Is the module signed? blocked? What is your powershell execution policy? If it is remotesigned, then a module would work locally but not from a remote location.
Is this custom module a script module or a binary module? .NET is sensitive to security zones and will very often not load assemblies from a remote location without specifically designating that remote location 'safe'.

In general it is a best practice to deploy modules via an installer and install them on the machines needed within the designated locations for modules.