Share via

Why does PowerShell ISE go into an infinite loop at start up when mapped network drive is not available when I am off site?

Question

Thursday, January 12, 2017 1:33 PM | 2 votes

Why does my mapped network drive (S: in this case) cause the PowerShell 5.1 ISE to go into an infinite loop in the form of its “Loading…” splash screen that never finishes whenever that mapped network drive is not available, such as when I take my laptop to a coffee shop that has no access to that shared network drive?

My theory is that PowerShell’s start up mechanism is trying to find and connect to the drive specified in registry key HKCU:\Network\S, which will work only when I’m at the physical location where that network drive exists.

However, if I take my laptop somewhere else, such as a coffee shop or somewhere other than where the mapped network drive is available, PowerShell 5.1 ISE stalls at start up as previously described.

As soon as I shell out to a CMD prompt and issue the following command and reboot, I can start PowerShell 5.1 ISE without it stalling in the splash screen.

Net use s: /delete

However, that means when I return to the location where the network drive is available, I have to remember to manually issue the net use command to reestablish the mapping of S: to the UNC of the network drive, which is frustrating.

Shouldn’t PowerShell 5.1 ISE gracefully fail with a warning or error message saying that the mapping for shared drive S: is not currently available and will not be established?

My environment:

Windows 10 Pro 64-bit, fully patched through and including the January 2017 "Patch Tuesday" patches.

If you think development is tough now, think how hard it was using punched cards :-)

All replies (14)

Friday, January 13, 2017 6:27 AM | 1 vote

Hi Wisdom,

Why didn't you use the UI method as below?

If your network path is available, it will reconnect when sign in. If the network path is unavailable, it would show red cross indicates the connection unavailable.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Friday, January 13, 2017 11:22 AM | 1 vote

I used the UI method to initially set up the mapping when I got this new computer on January 4, 2017, so no, your answer is not acceptable.

The problem is, when I'm not in a location where the mapped drive is available, such as a coffee shop or when traveling, the PowerShell ISE stalls during start up.  In fact, it never even makes to C:\windows\system32\windowspowershell\v1.0\profile.ps1 or even a local profile.ps1.

What I need to figure out is:

1. Is PowerShell ISE B.A.D. (Broken As Designed) or W.A.D. (Working As Designed) by Microsoft?

2. Either way, at least for now, I probably will need to cobble together a work-around script that contains logic to perform a Test-Path on the UNC of the would-be mapped drive and, if the result is $false, issue a NET USE S: /DELETE.  If the result is $true I can NET USE S: //unc-of-my-drive /PERSISTENT:YES.  I would use the PowerShell equivalents of NET USE but the the Remove-PSDrive cmdlet doesn't remove the mapped drive IMMEDIATELY like its DOS counterpart.  And if I'm forced to use NET USE to remove the mapped drive (to allow PowerShell ISE to not stall during startup), I might as well use NET USE instead of New-PSDrive to reestablish it.

I want this all to be a scripted, automated/automatic process, based upon the location where I sitting when I start the PowerShell ISE.  At least until Microsoft fixes their broken PowerShell ISE startup logic.

What disappoints me about Microsoft is that I cannot put the above logic in my profile.ps1 because IT NEVER GETS THE CHANCE TO RUN.

If you think development is tough now, think how hard it was using punched cards :-)

Friday, January 13, 2017 2:47 PM | 1 vote

I can not reproduce your issue. I mapped a folder from my NAS as Z: drive,
then shut down the NAS. Explorer displays a progress bar when accessing Z:, until it finally displays an error message.
But PowerShell ISE starts with the same performance as before.
Do you perhaps have some addon installed in the ISE?
You can either use ProcessMonitor to log what Powershell ISE is accessing before it hangs,
or take a process dump and analyse it.

When you write "infinite loop": how do you now this? Did you inspect the call stack?

Friday, January 13, 2017 3:46 PM | 1 vote

I know it's in an infinite loop because the PowerShell ISE "splash screen" appears and never goes away when I'm at a location where there is no hope of using the S: drive because it's underlying device, the UNC, is not available.

I read somewhere that the PowerShell ISE tries to enumerate the PSDrives (I assume that's based on HKCU:\Network\ and the minute I unmap the S: drive when I'm not near the actual device (such as when I'm at a coffee shop), I can start PowerShell ISE without it "stalling" in the splash screen, presumably because it's not in an infinite loop trying (with no hope of succeeding) to access the S: drive.

I can replicate this issue every time, so the symptoms are well known and repeatable.

For now, I can write a "kludge work-around" script that checks the existence of the UNC and reacts by defining or undefining (via NET USE) the mapping of the S: drive.

I resent that I have to do that, but until Microsoft makes their PowerShell ISE gracefully warn that the mapped drive it's looking for is unavailable instead of stalling in an infinite loop, I don't see a quicker way to resolve this.

If you think development is tough now, think how hard it was using punched cards :-)

Thursday, January 19, 2017 3:05 AM | 1 vote

Hi,

If so, please ask in script forum to see if your script has any problem:

https://social.technet.microsoft.com/Forums/windows/en-US/home?forum=winserverpowershell

The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Thursday, January 19, 2017 1:21 PM | 1 vote

"... if your script has any problem:"

There is no script.

No scripts, including profile.ps1 ever get a chance to run because the Microsoft-supplied PowerShell ISE executable is stuck in an infinite loop, presumably trying to enumerate non-accessible PSDrive's.

This appears to be a permanent issue with no cure in sight.

There is only the following work-around:

1. Before shutting down at the location where the S: drive's underlying UNC is accessible, issue the following command:

NET USE S: /DELETE

2. Shutdown

3. Go to a location where there is no access to the UNC of the underlying drive.

4. Boot

5. Fire up the PowerShell ISE (does not matter if it's elevated or regular), and it will work.

If the NET USE S: /DELETE is not performed (such as when I'm in a hurry), once I reach a remote location (coffee shop, public library, etc.), I have to perform the following steps.

1. Power on the computer.

2. Launch a PowerShell or CMD prompt.  It does not matter whether it is elevated or not.

3. Issue the following command:

NET USE S: /DELETE

4. Restart computer.

5. Login

6. Launch PowerShell ISE with no "stall in the splash screen".

Failure to perform step #3 above will result in the "infinite loop in the splash screen" when I try to launch the PowerShell ISE.

The issue is repeatable and rears its ugly head every time I forget to "unmap" the S: drive before shutting down the computer prior to going to a remote location.

I do not know how long this issue will exist.  I assume it will require Microsoft to put some logic into the binaries that comprise the PowerShell ISE to quit trying to access a mapped drive after so many attempts, followed by perhaps a Write-Warning explaining that \whatever\whatever, mapped to drive letter "something:" is not accessible and will not be available during the current PowerShell ISE session.

I'd love to put the work-around logic mentioned above into my profile.ps1 (or the global one), but since the profile.ps1 never gets a chance to run because the PowerShell ISE never escapes its own infinite loop in the splash screen, that is not an option.

If you think development is tough now, think how hard it was using punched cards :-)

Wednesday, May 3, 2017 9:29 PM

This is still a problem as of early May 2017.

I have my fingers crossed hoping Microsoft will fix the PowerShell ISE infinite loop at start up when a PSDrive is not accessible in one of their regular "Patch Tuesday" set of patches.

If you think development is tough now, think how hard it was using punched cards :-)

Wednesday, May 3, 2017 9:40 PM

where did you find " PowerShell 5.1 ISE"?
On my system "%WINDIR%\System32\WindowsPowerShell\v1.0\powershell_ise.exe" has the version 10.0.15063.0

Wednesday, May 3, 2017 10:21 PM

where did you find " PowerShell 5.1 ISE"?
On my system "%WINDIR%\System32\WindowsPowerShell\v1.0\powershell_ise.exe" has the version 10.0.15063.0

1. Open up a PowerShell prompt.

2. $PSVersionTable <enter>

On my computer the output displays as follows:

Name                           Value                                                                                   
                                                                                                              
PSVersion                      5.1.14393.1066                                                                          
PSEdition                      Desktop                                                                                 
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                 
BuildVersion                   10.0.14393.1066                                                                         
CLRVersion                     4.0.30319.42000                                                                         
WSManStackVersion              3.0                                                                                     
PSRemotingProtocolVersion      2.3                                                                                     
SerializationVersion           1.1.0.1

If you think development is tough now, think how hard it was using punched cards :-)

Monday, July 10, 2017 11:58 AM

This is still happening as of July 10, 2017.

Fingers still crossed that one of the monthly "Patch Tuesday" Windows Updates will eventually (perhaps with no fan fare in the way of an official KB article) fix the issue.

If you think development is tough now, think how hard it was using punched cards :-)

Thursday, August 24, 2017 2:16 AM | 2 votes

I have this issue as well.

To add additional info that might shed some light: I use the Task Scheduler to map a my NAS drive under the SYSTEM account (I do this so my backup software will back up data on my NAS drive). Under my normal user account this shows up as a Disconnected Network Drive.

When I launch the PowerShell console I get an error message saying, "Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed." but the console is otherwise fine.

The PowerShell ISE however, will not get past the loading splash screen, presumably for the same reasons as discussed here.

Perhaps the issue can be reproduced using this set up; use the Task Scheduler to map a drive under the SYSTEM account. Then try to launch PowerShell ISE

Thursday, August 24, 2017 10:05 AM

I have found, almost by accident, the following work-around until Microsoft ever decides to fix this issue:

  1. Power on the laptop at the remote location where there is no way to get to the mapped drive (coffee shop, library, etc.).
  2. Log in normally.
  3. Launch PowerShell ISE and wait for it to stall in the Loading... screen.
  4. Reboot the computer.
  5. Login in normally.
  6. Launch PowerShell ISE.  This time it runs normally, despite the fact that the mapped network drive is inaccessible.

Somehow, PowerShell ISE "remembers" that there is not a snowball's chance in hell of connecting to the mapped network drive and just keeps going.

Microsoft needs to change the PowerShell ISE to emit the FileSystem initialization warning message during step #3 above instead of me having to perform the "workaround dance" of steps 4-6. 

If you think development is tough now, think how hard it was using punched cards :-)

Sunday, August 27, 2017 7:02 AM

This is exactly my situation. I don't know what to do further. MS are you listening?

Tuesday, June 19, 2018 2:43 PM

I had been scratching my head too with this one and I finally know what is causing the problem.
In my case I noticed that on some newly installed test SQL servers when opening Powershell ISE, it did hang at startup.
Coincidentally these were all servers where I get an error when opening powershell:
Error: Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed.
This error means that powershell found a System drive or Mapped Share that it does not have permission to connect to.

This only happens when I mapped a shared drive THROUGH SQL service account.

After hours of investigation I finally noticed that the test SQL servers that had the problem were all running under the LocalSystem service account(dangerous and not recommended). And the ones that did not have the problem were running under the NetworkService account.

This means that the LocalSystem account creates mapped drives that are visible but not accessible by Powershell, so they are probably created in a different elevated security contexts.

If I disconnect the SQL mapped drive then Powershell ISE starts normally but of course this is not the solution.

In my case the correct solution is to run SQL services on the test servers with the NetworkService account and not with the LocalSystem account so that when I map a shared drive through SQL that it is mapped in a security context that is hidden from powershell.

I do agree with WisdomGuidedByExperience that Microsoft needs to change the PowerShell ISE to emit the FileSystem initialization warning message.

  • Last updated on