Vscode-powershell: Extension/Integrated Console hangs on startup before prompt

Created on 6 Jun 2019  Â·  35Comments  Â·  Source: PowerShell/vscode-powershell

Issue Type: Bug

Open Visual Studio Code (the terminal window won't load after five minutes with 30 gb of RAM).

Extension version: 2019.5.0
VS Code version: Code 1.35.0 (553cfb2c2205db5f15f3ee8395bbd5cf066d357d, 2019-06-04T01:17:12.481Z)
OS version: Windows_NT x64 10.0.17763


System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (4 x 2808)|
|GPU Status|2d_canvas: disabled_software
checker_imaging: disabled_off
flash_3d: disabled_software
flash_stage3d: disabled_software
flash_stage3d_baseline: disabled_software
gpu_compositing: disabled_software
multiple_raster_threads: disabled_off
native_gpu_memory_buffers: disabled_software
rasterization: disabled_software
surface_synchronization: disabled_off
video_decode: disabled_software
webgl: disabled_off
webgl2: disabled_off|
|Load (avg)|undefined|
|Memory (System)|23.87GB (12.35GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|


Area-Startup Issue-Bug Needs-Repro-Info OS-Windows vscode-bug

Most helpful comment

From my side the problem has been solved by running x86 version of the
language extension.
x64 version always hangs.

But, I also have to mention that my corporate laptop has security component
(like beyondtrust privilege guard) that is upgraded very often without
notification.
So, I don't know if these upgrades have not also help solving this issue.

HTH

Le jeu. 2 avr. 2020 à 19:54, Tyler James Leonhardt notifications@github.com
a écrit :

For those of you on Windows PowerShell that see this issue, can you please
send me your event logs for Windows PowerShell? I wonder if that has
anything important... ALSO If you see the issue & you have an anti-virus,
can you please check the logs of your AV for anything suspicious?

Thanks for your patience... this has been very hard to troubleshoot
without a repro on my end.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/vscode-powershell/issues/2014#issuecomment-608011117,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJCYS2D6P443SR7PXVZ5UY3RKTGONANCNFSM4HVICWCA
.

All 35 comments

I second this motion. Was about to open an issue myself. The console window just shows PowerShell Integrated Console and that's it.

Thanks for opening an issue. If we can find a way to reproduce it, we can hopefully fix it.

the terminal window won't load after five minutes with 30 gb of RAM

This is likely not a performance issue.

A couple of questions:

  • If you go to the Integrated Console and press Enter, does it then continue?
  • When did this last work for you? Did it stop working when VSCode (not the extension) updated? Or when the PowerShell extension updated at the end of May?
  • In @metalmensch's case, does it display anything in the terminal? Do you have a PowerShell file open?
  • In @MarkKharitonov's case, what operating system (and version) are you running?
  • If you try to restart the PowerShell extension session (with Ctrl+Shift+P PowerShell: Restart Current Session), what happens?
  • If you open a native powershell or pwsh terminal, does a similar problem occur?

We're aware of a Windows bug that's been affecting recent VSCode builds in which the terminal doesn't behave properly, so that's my current suspicion.

It looks like it was being stopped by a pending windows update on my end. I
rebooted, and it seems to have gone back to working.

On Thu, Jun 6, 2019 at 1:24 PM Robert Holt notifications@github.com wrote:

One test is: if you go to an ordinary native powershell terminal, does
something similar happen?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/vscode-powershell/issues/2014?email_source=notifications&email_token=AGUA7HPI6VOVBAHPXJ6CUATPZFW75A5CNFSM4HVICWCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEBWAY#issuecomment-499653379,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGUA7HNSFF5GREBENDQTSZ3PZFW75ANCNFSM4HVICWCA
.

I would like to answer the questions:

  • If you go to the Integrated Console and press Enter, does it then continue?

No, still stuck at PowerShell Integrated Console

  • When did this last work for you? Did it stop working when VSCode (not the extension) updated? Or when the PowerShell extension updated at the end of May?

Sorry, but I do not know.

  • In @MarkKharitonov's case, what operating system (and version) are you running?

I have two machines. On the "good" the Powershell console opens OK., On the "bad" - it is stuck. In both cases it is Windows 10.
Here is the info:
"Bad" Machine
Powershell Integrated Console hangs, pressing Enter does not help. At least not in the first N minutes, where N is sizeable (10?)
VS Code

Version: 1.34.0 (system setup)
Commit: a622c65b2c713c890fcf4fbf07cf34049d5fe758
Date: 2019-05-15T21:59:37.030Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Powershell extension

Name: PowerShell
Id: ms-vscode.powershell
Description: Develop PowerShell scripts in Visual Studio Code!
Version: 2019.5.0
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode.PowerShell

"Good" Machine
VS Code

Version: 1.34.0 (system setup)
Commit: a622c65b2c713c890fcf4fbf07cf34049d5fe758
Date: 2019-05-15T21:59:37.030Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.16299

Powershell extension

Name: PowerShell
Id: ms-vscode.powershell
Description: Develop PowerShell scripts in Visual Studio Code!
Version: 2019.5.0
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode.PowerShell
  • If you try to restart the PowerShell extension session (with Ctrl+Shift+P PowerShell: Restart Current Session), what happens?

Same thing - it hangs.

  • If you open a native powershell or pwsh terminal, does a similar problem occur?

No.

Hmmm it certainly looks like the only difference between machines is the Windows version (which implies it may be the Windows bug).

Another thing it might be worth doing is turning the logging up to Diagnostic and seeing how far you get through startup

Actually on the "bad" machine hitting many times Enter does force the console to show the prompt. So, yes - hitting multiple times Enter shows the console. But, it does not load the profile.

I will get the logs later.

hitting multiple times Enter shows the console

Yeah that sounds like the relevant Windows bug.

But, it does not load the profile

Which profile is that? The PowerShell extension looks for the profile in ~\Documents\PowerShell\Microsoft.VSCode_profile.ps1. I assume this works on the good machine?

Yes, it does not load the $PROFILE, whatever it should be in this context. Does load on the "good" machine.

Note that once the prompt is shown explicitly loading $PROFILE works fine.

Note that once the prompt is shown explicitly loading $PROFILE works fine.

Ohhhh, as in it loads once you press Enter?

Yeah that's because this Windows bug just stops the startup from proceeding (it's a bug in the Windows console APIs), before it can get to the profile execution stage. It's like if you put Wait-Debugger at the start of your profile.

The fix lies below the extension -- it's something we depend on VSCode and Windows for. From what I can tell, the fix is to run Windows update.

Well, it does not load when I press Enter. But when I run . $PROFILE at the prompt it loads without a problem.

So, who knows what happens with this bug? Is it the Windows team? The VS Code team? Who is the address to get some info on ETA of the fix?

Well, it does not load when I press Enter

Ah, I misunderstood earlier. Given that, we still need more information to determine the bug.

If it's a Windows/VSCode terminal API problem, the fix is almost certainly already available and it's just a matter of you getting it.

But when I run . $PROFILE at the prompt it loads without a problem.

Is this still the Integrated Console? What's the value of $profile? Do you get PS extension features like intellisense and diagnostics?

I think the best option is to make sure you have a clean, up-to-date environment:

  • Uninstall VSCode
  • rm -fo -r ~\.vscode
  • Install any pending Windows updates
  • Restart your machine
  • Install VSCode
  • Install the PowerShell extension
  • Check for the bug
  • If it persists, Install VSCode Insiders
  • Install the PowerShell extension in VSCode insiders
  • If the bug's still there at that point, turn on diagnostic logging and upload your logs here. Particularly of interest would be the terminal's execution trace from the startup script.
  • If we still find nothing, I would suspect security policy or some kind of system lockdown that causes PowerShell to lock up when trying to execute some step. Antivirus software sometimes likes to silently stop execution in our startup script

@MarkKharitonov were you able to resolve this with @rjmholt's suggestion of uninstalling, and reinstalling VSCode or are you still facing this issue? Thanks!

It is a bit heavy for me right now. Did not have time to do it yet.

I can only say that I no longer have the "good" machine - both are "bad" :-(.

I am having the same issue. I've found that when manually running the "args" command from Powershell itself, this code hangs indefinitely.

C:\Users\jrichardson\.vscode\extensions\ms-vscode.powershell-2019.5.0\modules\PowerShellEditorServices\Start-EditorServices.ps1 -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2019.5.0' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'C:\Users\jrichardson\.vscode\extensions\ms-vscode.powershell-2019.5.0\modules' -EnableConsoleRepl -LogLevel 'Normal' -LogPath 'C:\Users\jrichardson\.vscode\extensions\ms-vscode.powershell-2019.5.0\logs\1561381335-dcf17219-d54a-40bc-bdd5-bad88ba69ed21561381331557\EditorServices.log' -SessionDetailsPath 'C:\Users\jrichardson\.vscode\extensions\ms-vscode.powershell-2019.5.0\sessions\PSES-VSCode-21768-408591' -FeatureFlags @()

PS displays "PowerShell Integrated Console" and then does not proceed any further.

VSCode with debug enabled shows:

VERBOSE: 
#-- Console Encoding ---------------------------------------------------------
VERBOSE: System.Text.ASCIIEncoding
VERBOSE: 
#-- Updated PSModulePath to: -------------------------------------------------
VERBOSE: P:\Documents\WindowsPowerShell\Modules
VERBOSE: C:\Program Files\WindowsPowerShell\Modules
VERBOSE: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
VERBOSE: C:\Users\jrichardson\.vscode\extensions\ms-vscode.powershell-2019.5.0\modules
VERBOSE: 
#-- Check required modules available -----------------------------------------
VERBOSE: Testing module availability PowerShellGet 
VERBOSE: Loading module from path 'C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1'.
VERBOSE: PowerShellGet  found
VERBOSE: 
#-- Start up PowerShellEditorServices ----------------------------------------
VERBOSE: Importing PowerShellEditorServices
VERBOSE: Loading module from path 'C:\Users\jrichardson\.vscode\extensions\ms-vscode.powershell-2019.5.0\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'.
VERBOSE: Loading module from path 'C:\Users\jrichardson\.vscode\extensions\ms-vscode.powershell-2019.5.0\modules\PowerShellEditorServices\PowerShellEditorServices.psm1'.
VERBOSE: Exporting function 'Start-EditorServicesHost'.
VERBOSE: Exporting function 'Compress-LogDir'.
VERBOSE: Exporting function 'Get-PowerShellEditorServicesVersion'.
VERBOSE: Importing function 'Compress-LogDir'.
VERBOSE: Importing function 'Get-PowerShellEditorServicesVersion'.
VERBOSE: Importing function 'Start-EditorServicesHost'.
PowerShell Integrated Console

VERBOSE: Invoking Start-EditorServicesHost
VERBOSE: Start-EditorServicesHost returned Microsoft.PowerShell.EditorServices.Host.EditorServicesHost
VERBOSE: Writing session file with contents:
VERBOSE: {"languageServiceTransport":"NamedPipe","languageServicePipeName":"\\\\.\\pipe\\PSES_zz3sudvm.tgn","debugServiceTransport":"NamedPipe","status":"started","debugServicePipeName":"\\\\.\\pipe\\PSES_sk3vhecb.1ba"}
VERBOSE: Wrote out session file
VERBOSE: 
#-- Waiting for EditorServicesHost to complete execution ---------------------

@JR70386 If you're running the startup script directly, that's intended behaviour. The script starts the backend and then waits patiently for a client to connect before proceeding. If there's no client, it will just wait indefinitely. Are you having trouble starting PowerShell from VSCode?

@MarkKharitonov Did you get a chance to try out those steps?

I have the same behaviour here and just tried something out (please see attached images):

1: Started VSCode with a Powershell Script ==> the prompt doesn't show up
2: Typed a character (in this case: "c") ==> the prompt is there
3: Made the Terminal window larger and restarted Code ==> everything's fine without the need to type a character or pressing enter twice.

So it looks like the shell is there, it's just not showing up correctly.
Can you check this out on your machine(s)?

1: after initial start
01 - start vscode

2: after pressing "c"
02 - type any character

3: after initial start with a larger terminal
03 - resize terminal then start code again

@rjmholt Yes, I'm having trouble starting a PS terminal in VSCode. The behavior is similar, so that's why I brought up my manual tests.

Have just been thinking on this issue.

The commonalities seem to be:

  • Running on Windows 10, not newer than 1809
  • Windows PowerShell (i.e. not PS 6+)

Because this seems to be quite platform- and version-dependent, we need to collect more information (because we aren't able to reproduce it ourselves).

For everyone affected, please turn your log level up to diagnostic and send through your logs after a fresh startup/hang of the extension. It's also important to know which log files aren't generated, so be sure to list the log files you find (the easiest way is usually to zip the log directory and send that).

To properly debug this, it's likely you'll need to collect a dump. The easiest way is to use procdump -ma $psesPid where $psesPid is the PID of the powershell.exe process running the language server (try gps *powershell* | ? { $_.Parent -like '*code*' } to get this).

If you are able to send a dump of the hang through to us, it should be straightforward to work out where the problem lies. Please note that dumps can contain a lot of information, so you can send them directly (probably with a download link) to [email protected].

Hi rjmholt,

Please find below a link containing a procdump of the powershell process hanged
https://netapp-my.sharepoint.com/:u:/p/masson/EV3R7hRefdtDvdSgb0rcQJgBD20DCP9RGYWcuC5MI92QLw?e=EKjFE6

HTH

@oliviermasson thanks for that!

It looks like at the point you've obtained the dump, the EditorServices module has not yet been loaded and it's still running the startup script.

Specifically, the pipeline thread is performing module discovery for autoloading for Split-Path (the command seems to be Split-Path $LogPath -Parent) and is enumerating files on the module path (under C:\Program Files (x86)\WindowsPowerShell\Modules). The file under the enumerator in that moment is C:\Program Files (x86)\WindowsPowerShell\Modules\VMware.VimAutomation.Cis.Core\10.0.0.7893915\VMware.VimAutomation.Cis.Core.psd1. The console host thread is waiting for this to complete.

That looks like here:

https://github.com/PowerShell/PowerShellEditorServices/blob/fd77c0d85b237f89a532430c130561a04ff5e221/module/PowerShellEditorServices/Start-EditorServices.ps1#L116

This is a bit mystifying, since it's very early on and in code we don't control.

There are a couple of possibilities I can think of:

  • A performance problem has been introduced in autoloading and this isn't a true hang, but is just extremely slow
  • There is a cycle in the enumeration of the module directory (like a symlink or a hardlink) causing it to loop forever
  • There's some kind of silent block on one of the files being looked at

To determine what's going on, we'll have to collect more information through dumps. Some scenarios to try are:

  • Pre-importing (put Import-Module at the top of the file) modules for commands needed
  • Setting log level lower to change this code path
  • Setting the module path to only include $PSHome in the script

I would try those modifications to the startup script first and then if the hang doesn't reproduce, let us know. Otherwise see if you can get another stack dump. Feel free to send them by email to [email protected] if you prefer not to link them publicly.

Hopefully, we can find a common state we're getting stuck in and determine why it doesn't happen in the Windows PowerShell console.

Hi rjmholt,

I've send you a new procdump by email.
I've tryed to modify the script with
Pre-Import at the very begining of Start-Editorservice.ps1
And set log level to verbose only.

But for your last request regarding module path, i'm not sure to have done what you expected.

I've copied all modules files available from extension folder to my $PShome\Modules folder

The issue is still there, with same behaviour.

But once again i'm not sure to have done correctly all modifications you request.
Could you send me the code you want me to include (or delete) from the extension.
And i will applied it excalty.

I hope this new procdump will help, but i think it will contains same think as previous dump.

Regards

I've send you a new procdump by email.

Thanks for that!

But for your last request regarding module path, i'm not sure to have done what you expected.

Ah I should have explained better. If you set $env:PSModulePath = $PSHome at the start of the script, it will stop PowerShell from looking for modules elsewhere (which in this case might help because we don't depend on anything you might have installed).

But based on this procdump, I'm not sure that would help; it seems to be processing much earlier than before, and is still initialising the registry provider.

That suggests that the hang isn't stable, and may not be a hang at all, but rather a performance issue of some kind. With that in mind there are a few more data points we should fill in:

  • How long after startup did you take the procdump?
  • What was the CPU and memory usage of the process?
  • What kind of hardware are you running this on (CPU, memory)?
  • Are other processes or applications running slow on the system?
  • Does Windows PowerShell in the console behave as normal?

Given that the two procdumps so far show quite different states (but in both cases, the process busy within PowerShell's own codebase and quite early on in PSES startup), if you can collect two dumps of the same process 2 seconds apart, we can hopefully establish whether it's making progress or not.

I just spoke to @PaulHigin offline about this, and it sounds like there have been other reports of extreme performance degradations in PowerShell in some Windows patches.

So another piece of important information would be the Windows build number, which you can get by running winver.

You might also be able to attach a debugger to the PowerShell process in Visual Studio and actually watch it in real time.

After that, the recommendation would be to ensure you have any pending Windows updates installed.

Hi rjmholt,

I've sent a new archive with 4 dump taken at different interval during the issue.

I can't or i don't know how to attach a debugger inside visual studio code, because when i try to run the debugger it claims that i need to have a powershell session started...
image
and it's no more the case because of this issue.

Secondly i don't understand how the language service is executed automaticaly by VS code, because i'm not sure is executing the code i modify.
By example, i've added inside C:\Users\masson.vscode\extensions\ms-vscode.powershell-2019.5.0\modules\PowerShellEditorServices\Start-EditorServices.ps1
a wait-debugger:
image

But once it failed execute the powershell integrated console, the output log contains the following:

12/08/2019 13:41:01 [NORMAL] - Visual Studio Code v1.37.0 64-bit
12/08/2019 13:41:01 [NORMAL] - PowerShell Extension v2019.5.0
12/08/2019 13:41:01 [NORMAL] - Operating System: Windows 64-bit
12/08/2019 13:41:01 [NORMAL] - Language server starting --
12/08/2019 13:41:01 [NORMAL] -     exe: C:\WINDOWS\SysWow64\WindowsPowerShell\v1.0\powershell.exe
12/08/2019 13:41:01 [NORMAL] -     args: C:\Users\masson\.vscode\extensions\ms-vscode.powershell-2019.5.0\modules\PowerShellEditorServices\Start-EditorServices.ps1 -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2019.5.0' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'C:\Users\masson\.vscode\extensions\ms-vscode.powershell-2019.5.0\modules' -EnableConsoleRepl -LogLevel 'Normal' -LogPath 'C:\Users\masson\.vscode\extensions\ms-vscode.powershell-2019.5.0\logs\1565610061-e803b851-0a7a-408a-a461-a234b4b6484e1565610054120\EditorServices.log' -SessionDetailsPath 'C:\Users\masson\.vscode\extensions\ms-vscode.powershell-2019.5.0\sessions\PSES-VSCode-24092-924852' -FeatureFlags @()
12/08/2019 13:41:06 [NORMAL] - powershell.exe started, pid: 12264
12/08/2019 13:43:01 [NORMAL] - Language server startup failed.
12/08/2019 13:43:01 [ERROR] - The language service could not be started: 
12/08/2019 13:43:01 [ERROR] - Timed out waiting for session file to appear.

Nothing related to the wait-debugger i've inserted in the code.
I imagine that it must halt on the wait-debugger line i inserted, but it seems it's like thata line does not exist in the code executed???

During all this test my CPU was not above 60% (peak @60% avg @45%) and memroy not above 48%

Winver return the following:
image

I don't have any windows update pending.

@oliviermasson thanks for providing so much information...one more question, do you run PowerShell in an "all signed" environment?

Hi @SydneyhSmith

Here is my executionpolicy config :

PS C:\Users\masson\OneDrive - NetApp Inc\GitHub\svmtool> Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser          Bypass
 LocalMachine          Bypass

Since my first use of VS code with Powershell language extension, i have never changed this setting and it has always worked...until we encountered this issue.

I hope this answers to your question?

@oliviermasson Did you ever figure this out? I'm having the same problem.

Does anyone have a solution for this? I've got the same "Timed out waiting for session file to appear" error, and the extension reports there was an error during session initialization.

EDIT: Looks like it works if I switch to PS 5.1. There's something it doesn't seem to like about PowerShell Core on my machine. 🤔

Having the same issue too!

For those of you on Windows PowerShell that see this issue, can you please send me your event logs for Windows PowerShell? I wonder if that has anything important... ALSO If you see the issue & you have an anti-virus, can you please check the logs of your AV for anything suspicious?

Thanks for your patience... this has been very hard to troubleshoot without a repro on my end.

From my side the problem has been solved by running x86 version of the
language extension.
x64 version always hangs.

But, I also have to mention that my corporate laptop has security component
(like beyondtrust privilege guard) that is upgraded very often without
notification.
So, I don't know if these upgrades have not also help solving this issue.

HTH

Le jeu. 2 avr. 2020 à 19:54, Tyler James Leonhardt notifications@github.com
a écrit :

For those of you on Windows PowerShell that see this issue, can you please
send me your event logs for Windows PowerShell? I wonder if that has
anything important... ALSO If you see the issue & you have an anti-virus,
can you please check the logs of your AV for anything suspicious?

Thanks for your patience... this has been very hard to troubleshoot
without a repro on my end.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/vscode-powershell/issues/2014#issuecomment-608011117,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJCYS2D6P443SR7PXVZ5UY3RKTGONANCNFSM4HVICWCA
.

From my side the problem has been solved by running x86 version of the language extension. x64 version always hangs. But, I also have to mention that my corporate laptop has security component (like beyondtrust privilege guard) that is upgraded very often without notification. So, I don't know if these upgrades have not also help solving this issue. HTH Le jeu. 2 avr. 2020 à 19:54, Tyler James Leonhardt notifications@github.com a écrit :
…
For those of you on Windows PowerShell that see this issue, can you please send me your event logs for Windows PowerShell? I wonder if that has anything important... ALSO If you see the issue & you have an anti-virus, can you please check the logs of your AV for anything suspicious? Thanks for your patience... this has been very hard to troubleshoot without a repro on my end. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2014 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJCYS2D6P443SR7PXVZ5UY3RKTGONANCNFSM4HVICWCA .

Hi,

You're right about BeyondTrust Privilege Management having something to do with this. I could not find anything in its' logs that would point to this issue though.

This issue went away after we upgraded to BeyondTrust Privilege Management for Windows (x64) 5.6.126.0. Previously we had 5.4.230.0 and I could reproduce the issue on a clean image with just Privilege Management 5.4.230.0, Visual Studio Code 1.45.1 and the PowerShell extension 2020.4.0 installed.

Stopping the "Avecto Defendpoint Service" service also makes the issue go away (that's the older name for the product).

If anyone's still running into BeyondTrust/Avecto issues, we're following up on that in https://github.com/PowerShell/vscode-powershell/issues/3077, since there's new discussion on it. I'm going to close this issue now, so we can deduplicate discussions.

Was this page helpful?
0 / 5 - 0 ratings