vscode-powershell: The Language Service Could not be started

I had a same issue (Avecto on business laptop) and last night found a solution. I installed latest PS7 and in VSC under “Configure PowerShell language based settings” I changed the path to use pwsh: “terminal.integrated.shell.windows”: “C:\Program Files\PowerShell\7\pwsh.exe” It is a bit leggy but it works.

@rjmholt @richardm1 @TylerLeonhardt @tastrsks

Avecto/BeyondTrust got back to me yesterday. Creating a workstyle that allows code.exe and all subprocesses to execute, either passive or with added admin rights, typically gets my powershell server to start within two minutes. Avecto experimented with our policy set and found if we moved that workstyle farther up to be processed before some other workstyles, that delay was down to 20 seconds.

This solution seems specific to our policy set, and to me does not resolve the problem. I’ve pushed back on Avecto for a better solution.

Powershell 5.1 x86 and Powershell 7 seem unaffected. But in a corporate environment where developers are afflicted with BeyondTrust/Avecto Privilege Guard, I’m not sure VS Code is a viable platform for 5.1 x64 development. Getting the corporate security team to experiment with the Avecto policies to get things running, let alone get BeyondTrust to dig into them, is beyond most developers.

BeyondTrust recommended I update to version 5.6.126, and similarly to what was reported at #2014 (comment)] I got dramatically better results. I did continue to have sporadic lockups starting PowerShell 5.1 x64 servers, and sometimes x86 as well. However, reordering my workstyles combined with upgrading seems to have fixed things. Although I haven’t worked under this configuration for long.

@SydneyhSmith, I passed on that email address to BeyondTrust.

Another Avecto DefendPoint victim here. Same issue. I’m going to make a bunch of noise here and see if I can get someone to rattle Avecto’s cage and push for a fix.

Yeah so the difference between the “+” button and our server is that we are providing extra parameters to the call to powershell.exe (you can see it in the log)… Of all the parameters we specify, the most notable I think is -Command with the command we run to start the server.

My guess is that Avecto sees that we’re using -Command and tries to analyze it to make sure the command we are asking to run isn’t malicious… That mixed with the fact that the parent process is VS Code and not simply Conhost.exe could also be tripping it up.

This is my best guess given what we know.

I hope BeyondTrust looks into this because I think you’re right, I don’t know what else we could do at our layer.

You could try downloading and trying PowerShell 7 to see if it’s any better (it could be. It’s generally faster).

If they come back and have any sort of action item on us, please don’t hesitate to reach out!

I guess what we know is that the PowerShell extension is doing it’s job, and when createTerminal() is executed the request to the operating system to startup powershell.exe for it to create the server is submitted promptly.

And once powershell.exe starts executing it does so promptly.

There is a delay between the operating system being asked to startup powershell.exe and the operating system actually doing so. One has to suspect Avecto is the culprit there, although not certain.

At any rate, this doesn’t seem to be the PowerShell extension’s problem. Maybe there’s a different way to start the server? But I expect you are using best practice there.

Let me know if I’m missing something. I’ll let you guys know when I hear from BeyondTrust, I hope they take the interest in this you guys have. Thanks for your work @TylerLeonhardt and @rjmholt.

I don’t know how to broker this issue between Microsoft and BeyondTrust. My University has issued a support ticket to them, but if they say it is an MS problem, and MS says it’s a BeyondTrust issue, then Code simply stays broken for a not-insignificant number of enterprise users. I do hope this gets fleshed out, I’ve about expended all my abilities to get to the root of it, and remain mystified.

Thanks for your efforts here!

I’ve got a PR out that ups the time out and warns after 30s that “privilege enforcement software” can cause slowness.

I think this is good enough to close this issue while we still have other issues around start up performance.

I’d highly recommend giving feedback to these pieces of software that slow it down. Only my machine, the extension takes 3 seconds to start up. 2-3min absolutely wild.

@JoeBrunsTR @kihtov23 @ZonderP @AkosBatorfi

Thanks for your reports. Please note that “The Language Service Could not be started” is a generic message indicating the extension could not communicate with the language server. This particular GitHub issue was closed last year as it was a different bug report, and the issue with the Visual Studio Code 1.54 update is actually #3227. Please use caution in commenting on old, closed issues; most likely you need to find an existing open issue, or open a new issue. The good news is that the issue with VS Code has been resolved https://github.com/microsoft/vscode/issues/117649 and will be in the next VS Code release.

Visual Studio Code v1.54.1 64-bit

3/6/2021 4:47:38 PM [ERROR] - Could not start language service: 3/6/2021 4:47:38 PM [ERROR] - Error: Connection to server got closed. Server will not be restarted.

Same thing has happened again.

In the PowerShell extension, there are 2 processes involved:

VS Code (aka the client) PowerShell Editor Services (aka the server)

VS Code starts up PowerShell Editor Services (btw this is what supplies the PowerShell Integrated Console) and waits until it (PSES) creates a session file in a well known location.

Once PSES creates the file, it waits until VS Code reads the file and connects to the named pipe details that are inside the session file.

So if you’re running that command outside of VS Code, nothing will happen because it’s waiting for VS Code to connect to it.

What might be nice is to turn on Diagnostic logs and just watch what takes a long time (“I noticed it took a while between these 2 log statements”).

Another thing that privilege enforcement might care about is DLLs loaded into PowerShell… Which we do in order to run PowerShell Editor Services… But I’m just shooting in the dark with that theory.

I get to the “Waiting for session file” step quite quickly, it’s what happens during that wait where the problem lies. I don’t understand what is happening behind the scenes at that time, or what is creating that session file.

PowerShell Editor Services (the server process started with the invocation above) creates the session file to communicate back to the client that it’s ready to accept connections (the client must start the process, but because of the integrated console we have to use something other than stdio to communicate with it and the server has to own the transport, meaning it must create it). Those connections are made over named pipe. So the sequence of events is:

• Client starts server
• Server creates named pipes and starts listening
• Server writes session file
• Client sees session file and starts sending LSP messages over the named pipes

The server is doing pretty much all the heavy lifting there.

I’m not sure which step a program like BeyondTrust doesn’t like about that though. If you can procdump the powershell.exe running a PowerShell extension startup on your machine that might provide some details as to where it’s stuck, but I’ve looked over a few of those when we’ve investigated those before and they didn’t seem to tell us much. Might be worth it anyway, especially now that we’ve started to see what the commonality is among those affected by the issue.

I think if we can understand why BeyondTrust is stalling the startup of Windows PowerShell then we might be able to work around it. The missing piece of the puzzle is why does BeyondTrust slow down our process startup when it doesn’t seem to affect powershell.exe startups on the same machine. If we can understand that, we might be able to work around it or register ourselves with it. We’d definitely be willing to work with them to alleviate the issue.

Beyond Trust Privilege Management - guys, this could be the common link for this issue. My corporate laptop has this installed. How would I classify it? Hard to say. It enforces least privilege on endpoints, so it’s security related, but not the same as an AV solution.

Thanks everyone, while we investigate the start-up performance we will include a higher timeout, and a warning when it is taking longer than usual (with a warning that anti-virus could potentially be effecting startup)

Hey @EdCallahan did you see my comment here https://github.com/PowerShell/vscode-powershell/issues/2526#issuecomment-616882721

@EdCallahan if you think it’s that 2min isn’t enough, can you try these steps:

1. open the following file:

~\.vscode\extensions\ms-vscode.powershell-2020.4.0\out\src\utils.js

or if you have preview:

~\.vscode\extensions\ms-vscode.powershell-preview-2020.4.2\out\src\utils.js

search for innerTryFunc(60, 2000); in that file.

change it to: innerTryFunc(120, 2000); which will try to connect an additional 60 times every 2 seconds.

Let me know how it goes. If this is something we need to extend, we can do that… though frankly I’m curious why it’s so slow.

I will have some time this afternoon to repeat this with the fusion logs enabled.