Integrated Console Colors do not work on older Windows Versions without ANSI/VTY Support (2012R2 etc.)

[mhdevop]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.

Summary

VScode with this extension have worked great for roughly a year but at some point I'm not sure of, a weird issue started happening on my dev server (Windows Server 2012 R2). ANSI characters started showing up in the integrated console.

Expected:

PS C:\Users\me> get-host

Name : ConsoleHost
Version : 7.2.1
InstanceId : fd6bb11f-cb31-4266-a524-4ff936a460bf
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : en-US
CurrentUICulture : en-US
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace

Actual:

PS C:\Users\me> get-host

[32;1mName : [0mVisual Studio Code Host
[32;1mVersion : [0m2021.10.2
[32;1mInstanceId : [0mc1c2393e-ac91-4757-826e-b9cdb6392c14
[32;1mUI : [0mSystem.Management.Automation.Internal.Host.InternalHostUserInterface
[32;1mCurrentCulture : [0men-US
[32;1mCurrentUICulture : [0men-US
[32;1mPrivateData : [0mMicrosoft.PowerShell.EditorServices.Services.PowerShellContext.EditorServicesPSHost+ConsoleColorProxy
[32;1mDebuggerEnabled : [0mTrue
[32;1mIsRunspacePushed : [0mFalse
[32;1mRunspace : [0mSystem.Management.Automation.Runspaces.LocalRunspace

Things I've already tried:

Google of course
Un/Re install VScode
Upgraded PWSH
Tested the command directly in the native pwsh shell and works perfectly (seems to suggest something within the VScode integrated console)

PowerShell Version

PS D:\scripts> $psversiontable


[32;1mName                           Value[0m
[32;1m----                           -----[0m
PSVersion                      7.2.1
PSEdition                      Core
GitCommitId                    7.2.1
OS                             Microsoft Windows 6.3.9600
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

### Visual Studio Code Version

```console
PS D:\scripts> code --version

1.63.1
fe719cd3e5825bf14e14182fddeb88ee8daf044f
x64
PS D:\scripts>

### Extension Version

```console
PS D:\scripts> code --list-extensions --show-versions | Select-String powershell


ms-vscode.powershell@2021.10.2
ms-vscode.powershell-preview@2021.11.1
tobysmith568.run-in-powershell@1.1.1

PS D:\scripts>

### Steps to Reproduce

1.  Open VSCode on Windows Server 2012 R2
2.  Ensure the stable version of PowerShell is enabled with PowerShell 7.2.X installed
3.  Run a simple command like "Get-Host"

Extra info:
If I disable the "stable" version of the extension, reload, and enable the "preview" version, the ANSI characters are no longer displayed which is good. (No color though, not sure if it's supposed to or not. Also, another issue with Preview is that when a command finishes, the cursor is not visible until you hit enter on the keyboard so you're never sure if the command finished yet or not but that's another issue for Preview)

### Visuals

See the summary for a text preview

### Logs

What's weird is that when I enable "debug" logs, I do not see the issue (weird!). When I put it back to "normal" the issue happens again. I will send an email with the zipped files.

[StevenBucher98]

Thanks @mhdevop! Can you expand upon what you mean when you say Preview mostly works? Are you potentially changing your term env var set in your PowerShell profile?

Have you experienced this issue in the PowerShell terminal in VSCode (not integrated console)?

[andyleejordan]

Also, do you experience this on OS's other than Windows Server 2012 R2? We can't seem to reproduce this.

[Qbert777]

`PS C:\Users> $psversiontable

Name Value

---

PSVersion 7.2.1
PSEdition Core
GitCommitId 7.2.1
OS Microsoft Windows 10.0.19043
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

PS C:\Users> code --version

1.63.2
899d46d82c4c95423fb7e10e68eba52050e30ba3
x64
PS C:\Users> code --list-extensions --show-versions | Select-String powershell

ms-vscode.powershell@2021.12.0`

I am seeing the same issue on Win10 but only when writing to a file. The issue seems to have started around the same time as mhdevop's post. For example, this line which writes to a txt file:

$emails | Select-Object @{Name="Type";Expression={$_.SenderAddress}}, Subject | Sort-Object -Property Status | Out-File -FilePath $fn -Append

Outputs like this:

�[32;1mType Subject�[0m �[32;1m---- -------�[0m

[mhdevop]

Thanks @mhdevop! Can you expand upon what you mean when you say Preview mostly works? Are you potentially changing your term env var set in your PowerShell profile?

Have you experienced this issue in the PowerShell terminal in VSCode (not integrated console)?

Hopefully these 2 videos answer both your questions (if I misunderstood do let me know). Basically the raw shell by itself works fine but in VScode it generates ANSI. When I switch to the "preview" version, it resolves the ANSI issue but as you can see, the terminal doesn't show the terminal sequence indicating the command finished running until you hit enter and neither does it "clear" correctly. I'm making no "manual" changes to my env var or other settings beyond switching the plugin from PROD > Preview:

[mhdevop]

`PS C:\Users> $psversiontable

Name Value

PSVersion 7.2.1 PSEdition Core GitCommitId 7.2.1 OS Microsoft Windows 10.0.19043 Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0

PS C:\Users> code --version

1.63.2 899d46d82c4c95423fb7e10e68eba52050e30ba3 x64 PS C:\Users> code --list-extensions --show-versions | Select-String powershell

ms-vscode.powershell@2021.12.0`

I am seeing the same issue on Win10 but only when writing to a file. The issue seems to have started around the same time as mhdevop's post. For example, this line which writes to a txt file:

$emails | Select-Object @{Name="Type";Expression={$_.SenderAddress}}, Subject | Sort-Object -Property Status | Out-File -FilePath $fn -Append

Outputs like this:

�[32;1mType Subject�[0m �[32;1m---- -------�[0m

I can't "prove" it but I did see this issue semi-recently as well when looking in a log file I found a lot of ANSI characters. Can't remember where it was though or what generated it.

If it helps here's what I'm running:

PS D:\scripts> code --version
1.63.2
899d46d82c4c95423fb7e10e68eba52050e30ba3
x64

[andyleejordan]

Ok, I think that what's happening is that the PowerShell Preview extension has no support for console colors yet, as we haven't yet implemented that part of the host. So no ANSI escape codes (which represent the colors) are being emitted by the Preview. We're tracking that issue here: PowerShell/PowerShellEditorServices#1607

[mhdevop]

Ok, I think that what's happening is that the PowerShell Preview extension has no support for console colors yet, as we haven't yet implemented that part of the host. So no ANSI escape codes (which represent the colors) are being emitted by the Preview. We're tracking that issue here: PowerShell/PowerShellEditorServices#1607

Just FYI - I was able to exactly reproduce this issue on a different 2012 R2 server (updated VScode, updated PowerShell plugin, and same version of PowerShell 7). I have asked that the server do an in-place upgrade to OS 2019 which I suspect will resolve the issue but I'll find out in the coming days/weeks. I have an existing 2019 server that works perfectly fine with this setup, just that pesky 2012R2 has issues. I'll update this issue once I know more unless you all want me to try something in between then.