Trying to understand the blocking behavior of BeyondTrust/Avecto DefendPoint

Issue Description

Visual Studo Code freezes completely for 4 minutes while starting up the PowerShell extension and then the extension fails to start up. It shows the infamous dialog ‘The window is no longer responding’ multiple times:

After analyzing your troubleshooting guide (https://github.com/PowerShell/vscode-powershell/blob/master/docs/troubleshooting.md) my hypothesis is that the language server is simply not able to start in the allotted time window and therefore the client will not find a session file in time. I guess BeyondTrust/Avecto is delaying the process for some reason. Refer to the log file:

vscode-powershell.log

28-11-2020 16:33:14 [NORMAL] - Language server starting --
28-11-2020 16:33:14 [NORMAL] -     PowerShell executable: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
28-11-2020 16:33:14 [NORMAL] -     PowerShell args: -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command Import-Module 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2020.9.0' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\modules' -EnableConsoleRepl -StartupBanner '=====> PowerShell Preview Integrated Console v2020.9.0 <=====
' -LogLevel 'Normal' -LogPath 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\logs\1606577594-22dda057-f65c-444d-b276-7edc00d0a1d11606577351760\EditorServices.log' -SessionDetailsPath 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\sessions\PSES-VSCode-24032-911679' -FeatureFlags @() 
28-11-2020 16:33:14 [NORMAL] -     PowerShell Editor Services args: Import-Module 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2020.9.0' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\modules' -EnableConsoleRepl -StartupBanner '=====> PowerShell Preview Integrated Console v2020.9.0 <=====
' -LogLevel 'Normal' -LogPath 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\logs\1606577594-22dda057-f65c-444d-b276-7edc00d0a1d11606577351760\EditorServices.log' -SessionDetailsPath 'c:\Users\caveld\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.9.0\sessions\PSES-VSCode-24032-911679' -FeatureFlags @() 
28-11-2020 16:33:14 [NORMAL] - powershell.exe started.
28-11-2020 16:33:14 [NORMAL] - Waiting for session file
28-11-2020 16:37:14 [NORMAL] - Timed out waiting for session file to appear.
28-11-2020 16:37:14 [NORMAL] - Language server startup failed.
28-11-2020 16:37:14 [ERROR] - The language service could not be started: 
28-11-2020 16:37:14 [ERROR] - Error: Timed out waiting for session file to appear.

I would like to understand why this is happening. The PowerShell terminal window inside vscode is immediately usable. So how is the creation of this PowerShell terminal window different than the PowerShell session the extension is trying to create?

Additionally, when I start the language server from this PowerShell terminal window, using the executed command shown in the log, it just immediately creates the session file.

So again the question, why is BeyondTrust/Avecto trusting this immediately?

Interestingly, when starting vscode elevated, BeyondTrust/Avecto immediately pops up with to a dialog to confirm ‘powershell.exe’. This immediately enables the PowerShell terminal window to run. The extension takes longer, eventually (1 minute?) BeyondTrust/Avecto pops up with a dialog to confirm ‘powershell.exe’ again. After confirmation, eventually (after 15 seconds?) the process proceeds.

Interestingly, when I wait with confirming the dialog, the same dialog ‘The window is no longer responding’ pops up 😉

I see this behavior only occurring with PowerShell 5.1 64-bit. With PowerShell 5.1 32-bit there is no observable delay, as well as with PowerShell 7.1.

Can you shed some light in which process is being delayed by BeyondTrust/Avecto?

Environment Information

Visual Studio Code

Name	Version
Operating System	Windows_NT x64 10.0.18363
BeyondTrust/Avecto DefendPoint	5.3.219.0
VSCode	1.52.0-insider
PowerShell Extension Version	2020.9.0

PowerShell Information

Name	Value
PSVersion	5.1.18362.1171
PSEdition	Desktop
PSCompatibleVersions	1.0 2.0 3.0 4.0 5.0 5.1.18362.1171
BuildVersion	10.0.18362.1171
CLRVersion	4.0.30319.42000
WSManStackVersion	3.0
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1

Visual Studio Code Extensions

Visual Studio Code Extensions(Click to Expand)

Extension	Author	Version
powershell-preview	ms-vscode	2020.9.0
remote-wsl	ms-vscode-remote	0.51.4

[rjmholt]

Ok, I’ve gotten in contact with BeyondTrust support. I’m not sure how far it will go, but they’ve asked for a PGCaptureConfig and a Service/Hook/Driver test.

Given that I’m an intermediary here, I’m not sure how well this will go (I would encourage anyone seeing issues here to contact BeyondTrust support directly and discuss the issue with them, because I asked them directly in the email what we can do to prevent the issue and they’ve told me there are no best practices), but I’d like to give it a shot.

Please email [e-mail] if you want to follow up and I can send you instructions on how to capture logs (instructions I can’t read since I’m not a BeyondTrust customer).

EDIT: The BeyondTrust support representative I contacted told me that it’s best that anyone experiencing this issue contact BeyondTrust directly. Probably at [e-mail].

[cveld]

My BeyondTrust/Avecto enterprise support team just upgraded my client to 5.6.148.0 and the problem went away!