PowerShell 64-bit hanging on new machine

Question

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 dir command 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 as echo multiple 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

Comments

[Nelson Rothermel]

One other thing I've noticed which may or may not be related: when I download a file in Chrome, it will reach 100% and then sit there for almost exactly 30 seconds before I can open/show in folder.

[Ramhound]

What version of PowerShell do you have installed, PowerShell 5.1 is installed by default on Windows 10, but you might have PowerShell Core installed. Do you still have the same security product installed, if so edit your question, and include the vital information necessary to answer your question. Please provide the relevant information from, netsh http show iplist, which will verify a theory of mine.

[harrymc]

Try: (1) See if you have an enormous file in C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\PowerShe‌​ll\PSReadline and get rid of it. (2) Create a shortcut to %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe and in Properties > Options set Use legacy console, (3) Try to call PowerShell with the -NoProfile switch, (4) Turn Off PowerShell Module Autoload.

[Vomit IT - Chunky Mess Style]

@NelsonRothermel Additionally, I would try .... 1. from admin elevated command prompt run sfc /scannow let it complete, reboot, try again. 2. Still having problems, try running the microsoft.com/en-us/download/details.aspx?id=30135 tool just in case, run it, reboot, try again.

[Nelson Rothermel]

@harrymc: Yep, got busy with other things but just added more details. Only 4KB file in that path, I already tried legacy console and -NoProfile, disabling module autoload didn't help. @Ramhound: I no longer have Bitdefender, both PowerShell Core and regular are slow. I've included the netsh output in my question. @PimpJuice: Already tried sfc, the .NET repair tool didn't help.

[harrymc]

Questions: (1) Have you installed Visual Studio Code? (2) Have you PowerShell transcription logging? (3) Does it happen when starting PowerShell as admin? (4) Does this answer apply here?

[harrymc]

(5) Try to disable UAC, (6) Try to set ExecutionPolicy to Unrestricted.

[Nelson Rothermel]

@harrymc: I do have VS Code, I have not turned on transcription as far as I know (Software\Policies\Microsoft\Windows\PowerShell\Transcriptio‌​n didn't exist in both HKLM and HKCU), it does occur running as admin. Ngen didn't help [much?], ditto for UAC, I already have ExecutionPolicy set to Unrestricted (I tried yesterday).

[harrymc]

Try to uninstall and reinstall VS Code.

[Nelson Rothermel]

Uninstalled VS Code, rebooted, still slow. Installed again, still slow.

[harrymc]

Absolutely last ideas: (1) Use Process Explorer to see what it's doing while starting up, if this is I/O or Internet. (2) Create a new account and see if it works better there. (3) Try it without Internet connection.

[Nelson Rothermel]

@harrymc: I already used "procexp" (I saw lots of ZwWaitForMultipleObjects) and disabled all network connections. The new account was a great idea I hadn't thought of, but unfortunately didn't work.

[harrymc]

I was thinking of using Process Explorer to see which files it was using during the wait.

[Nelson Rothermel]

Thanks for the suggestion, but unfortunately it didn't make a difference. I had already tried disconnecting from all networks which I assumed would work in a similar way and any network requests would immediately fail.

[HackSlash]

I added a recommendation to reset.

[Nelson Rothermel]

Sure, reinstalling/resetting Windows would probably work. I'm dreading having to do that but it may just be the last option. If I do go ahead with that I'm going to open PowerShell every step of the way so that if it slows down again I know the cause. I've even considered opening a ticket with Microsoft since I'd like to understand what is causing it, but I think I'd reinstall first.

[Nelson Rothermel]

On second thought, before reinstalling I could try removing some lower-level software I have that is more likely to cause the issues. For example, 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.

[Nelson Rothermel]

I removed the entry and PowerShell is still slow. However, it did allow me to install WinRM without any error, though that also didn't help with the slowness.

[Ramhound]

I was addressing the error, to many variables, with regards to the speed issue.

[Nelson Rothermel]

You were right, Acronis was not the culprit.

[Nelson Rothermel]

I tried regular safe mode (no networking/command prompt) and it didn't work, but that was a great idea! I'll look into Process Explorer some more tomorrow.

[Nelson Rothermel]

Bingo! Just looking at the 64-bit list I saw a McAfee DLL which was suspicious since Dell had it preinstalled but I had uninstalled. I still compared the two lists and nothing else seemed out of place. Add/Remove Programs didn't have anything so I used the McAfee Consumer Product Removal tool, rebooted and now everything's fast again. Chrome also no longer pauses after a download. Now I need to figure out how to get you the bounty since I think it just expired. :( I may need to gain more rep and then restart one.

[Nelson Rothermel]

Specifically, the culprit McAfee DLL was AMSIExt.dll which was located at C:\Program Files\mcafee\mfeav\amsiext.dll.

[Nelson Rothermel]

And thanks for sticking with me! I know a few days you said "Absolutely last ideas" but still gave me a few more.

[Ramhound]

@NelsonRothermel - It’s not the culprit

[Nelson Rothermel]

@Ramhound: Software doesn't always behave the same for everyone, but you were right. I had McAfee remnants interfering.