PowerShell 64-bit hanging on new machine
I recently got a new computer with plenty of horsepower and its works very fast everywhere except PowerShell.
Environment:
- Dell XPS 8930 (i7-8700K, 32GB RAM, 1TB NVMe SSD)
- Windows 10 Pro with latest updates (1809/10.0.17763)
- PowerShell 5.1.17763.316 and PowerShell Core 6.1.1
- I have plenty of memory left (>16GB) and CPU is near idle while it's hanging.
- Only Windows Defender (no other antivirus)
Some of the symptoms, which seem to be consistent:
- Opening PowerShell shows the copyright info and hangs there for 2 minutes before showing the prompt.
- I start typing a command and it takes almost a minute for the text to appear
- Once the text appears I can modify the command and it's responsive.
- I enter a simple command such as
echo 'hello'and hit enter, it takes about 45 seconds for 'hello' to appear on the screen and another 45 seconds to return to the prompt. - Once at the prompt typing a command is responsive, but the running it is slow again.
- Run the
dircommand in my home directory (few files/folders): about 2:30 before listing the directory, another 15 seconds to go back to the prompt.
Some attempted troubleshooting:
- PowerShell ISE: Takes about 5 minutes to get to prompt.
- PowerShell ISE (x86): It works fast!
- PowerShell (x86): Also works fast!
- PowerShell Core: Also very slow.
- PowerShell legacy console: No change.
- Opening up a regular command line and running
powershell -NoProfile: No change. -
sfc /scannow: No problems found, rebooting doesn't help. - Disable network connections: No change.
- Run Sysinternals procmon: Nothing obvious, but it always seems to hang right after some of the "Thread Exit" operations.
- Look at thread stacks in Sysinternals procexp: When it's hanging the main thread is always at ntdll.dll
ZwWaitForMultipleObjects. - Uninstall WSL/Hyper-V: No change.
- Ran "Microsoft .NET Framework Repair Tool" and rebooted, no change.
- Check
C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline, only one 4KB file. -
$PSModuleAutoloadingPreference = 'none': no change. I wouldn't imagine running one of the basic commands such asechomultiple times would always try to load modules. -
netsh http show iplist:
IP addresses present in the IP listen list:
127.0.0.1
- Enable WinRM (
winrm quickconfig): The service starts, but then it can't connect.- I can see port 5985 is being listened to by PID 4 when the service is started.
- The Windows Firewall has the two "Windows Remote Management (HTTP-In)" entries for port 5985 (allow any remote address when in a private network/profile).
- I can successfully
telnet localhost 5985 - After the WinRM service starts it takes about 7 minutes for it to respond with:
WSManFault ...
Error number: -2144108250 0x80338126 WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet.
The consistency in the delays makes me think there is some type of attempted connection and timeout, but I'm at a loss as to what that may be. Any gurus out there with ideas?
Solution 1:
There may be another installed 64-bit product that is slowing down PowerShell. To check, boot into Safe mode to disable all third-party products and drivers. If the problem disappears, you may use Autoruns to disable startup applications in bunches and reboot until you find the right one.
Another possibility is that the delay is caused by some 64-bit add-on that you have installed. The tool to use here is Process Explorer to compare the DLLs used by both the 64-bit and 32-bit versions of PowerShell.
In the View menu of Process Explorer, enable "Show Lower Pane" and in "Lower Pane View > DLLs", choose "DLLs". Use Ctrl+A to save the lists as text files, then use a file-compare product to compare both results after sort. You may simplify the search by limiting the displayed list to only the names of the DLLs, by right-click the header an choosing "Select Columns...".
Solution 2:
I have Acronis True Image with ransomware protection. I've found True Image to be somewhat buggy/unreliable so it wouldn't surprise me if that's the culprit.
I also have it installed. It is not the culprit.
when I run netsh http show iplist it displays the following information.
IP addresses present in the IP listen list:
-------------------------------------------
Which is what should be display when the command is ran.
Are there any gurus out there with ideas?
You need to run the following command in an elevated PowerShell prompt.
netsh http delete iplisten ipaddress=127.0.0.1
immediately the output of netstat -anp tcp will be the following:
> PS C:\> netstat -anp tcp
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:903 0.0.0.0:0 LISTENING
TCP 0.0.0.0:913 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49759 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49830 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49921 0.0.0.0:0 LISTENING
TCP 0.0.0.0:54235 0.0.0.0:0 LISTENING
TCP 0.0.0.0:54236 0.0.0.0:0 LISTENING
TCP 0.0.0.0:58091 0.0.0.0:0 LISTENING
TCP 0.0.0.0:58101 0.0.0.0:0 LISTENING
TCP 0.0.0.0:58607 0.0.0.0:0 LISTENING
TCP 0.0.0.0:62401 0.0.0.0:0 LISTENING
TCP 127.0.0.1:843 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1120 0.0.0.0:0 LISTENING
TCP 192.168.0.11:64811 24.105.29.76:443 ESTABLISHED
TCP 192.168.0.11:64828 52.114.76.37:443 TIME_WAIT
TCP 192.168.0.11:65133 23.79.18.217:443 CLOSE_WAIT
TCP 192.168.0.11:65135 17.248.136.9:443 CLOSE_WAIT
TCP 192.168.120.1:139 0.0.0.0:0 LISTENING
TCP 192.168.174.1:139 0.0.0.0:0 LISTENING
Source: Remote PowerShell, WinRM Failures: WinRM cannot complete the operation