Terminal: Windows 10 1809/19H1/20H1 breaks Powershell's console settings. Keeps opening with raster fonts.

The same happens to me only when using the Consolas font. If I use anything else - Courier New, Lucida Console, etc. - the settings are retained.

@50Wliu I can confirm that behaviour. Consolas resets to raster font. Lucida Console stays Lucida Console.

I'm almost certain this has to do with the fact that the new version of PSReadline is using the UTF8 codepage for displaying it's prompt, and when it does that, the console tries to recalculate the font.

I thought we had some issues tracking this previously, but I can't seem to find them. @bitcrazed do you remember where they were? Or was it an internal mail thread with @lzybkr and @SteveL-MSFT?

Can someone provide an exact repro? Like what font are you setting to the shortcut. What font is it being set to?

• Win-R and run powershell.
• It starts with raster font.
• Go into settings and set the font to Consolas. Click OK.
• Consolas is being applied.
• Close Powershell.
• Reopen powershell like before.
• Font is raster font again.
• Go into default settings and set the font to Consolas. Click OK.
• Close Powershell.
• Reopen powershell like before.
• Font is raster font again.

I don't think this was even Powershell's fault. I have a note sitting around here somewhere that one of the most recent .NET Frameworks (4.7something) suddenly decides to use 65001 as the default code page for all apps and when that flips back and forth with other tools and codepages as they start and exit, we recalculate the font.

I have a bug on me to try to make that less painful, but it's really the sudden flipping between codepages that is making this be a problem.

I can't reproduce this here. Both Windows PowerShell and Powershell both start up in the font I set.

@Borkason Have you tried concfg clean
https://github.com/lukesampson/concfg

@borakson - what locale is your Windows configured to use?

@bitcrazed I'm not @Borkason but since I'm experiencing this issue I'll answer as well.

My display language is Spanish (Spain), and so is my regional format. The language for programs that don't support Unicode is English (United States), and I have the beta checkbox selected for UTF-8 Unicode. (Hope that's what you're looking for...let me know if you were asking for something else)

@bitcrazed German. And I upgraded from 1803. Forgot to meantion that.

@doctordns which font?

@doctordns which font?

I use Lucida Console (18 pt). But I've tested others and they too work after a restart of Windows PowerShell.

The same happens to me only when using the Consolas font. If I use anything else - Courier New, Lucida Console, etc. - the settings are retained.

This was likely fixed by @lzybkr's recent work: https://github.com/lzybkr/PSReadLine/issues/542

@Borkason & @doctordns - can you please confirm and close if fixed?

Thanks.

@bitcrazed it looks like the issue you're referencing was fixed back in 2017 and as far as I can tell is included in the version of PSReadLine that 1809 ships with. Additionally, this issue is still occuring for me as of Windows Insiders build 18277.

@bitcrazed That's one year older then the 1809 release. I wouldn't call that "recent".

And for me nothing changed. I'm on Windows 10 build 17763.107

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17763.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

But as @50Wliu already sayd, it's not even fixed in the current preview.

Here is a link to the Feedback: https://aka.ms/AA37kk1

@bitcrazed linked to the issue that caused the problem.

The fix is in this PR: https://github.com/lzybkr/PSReadLine/pull/771

Fair enough. Is it known with what build the fix will ship?

I'll try to release another beta to the PowerShell Gallery before the end of the year, but I don't know about Windows (I don't work on Windows).

@SteveL-MSFT owns the bits that ship in Windows, so maybe he can comment.

Name Value
---- -----
PSVersion 5.1.17763.134
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.134
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

same here...ready to re-install windows, REALLY painful!

This problem seems links to fonts. I got the problem in Powershell with windows(cmd and Powershell core don't have this problem) when I set the font as 'Console', but when I change the font as 'Sarasa Mono SC', all work perfectly. I use 'Sarasa Mono SC' to show UTF-8 character, Windows 10 doesn't have a default font can show enough UTF-8 characters.

Same here. Both my Surface & desktop PC.

Strangely I think I am experiencing this same issue but from a different way. Whenever a subprocess is opened to run powershell.exe, the console font changes to raster from Consolas.

Example 1: I have vim running (WSL) and it runs a powershell sub command to get the system clipboard. Every time I run that command, it resets the console font to raster fonts.

Example 2: I have a shell script that runs powershell as a subprocess to get the system nameservers. It causes the same thing to happen to the console, a switch to raster fonts. Nothing is output to the console. Everything happens in the subprocess.

The really strange part is that if I run powershell manually from the console (WSL), then it's fine and the font does not change.

@bitcrazed, @SteveL-MSFT, @lzybkr: I have a good minimal repro. This started happening right after I upgraded the machine to Windows 1809. I had the font and console CP set before, as below, to Consolas and 65001 respectively, and everything worked just fine. I work with UTF-8 files, so the CP 65001 has been essential to me. My locale is plain old en-US, English language Windows 10 x64 Pro, and the OEM CP is the default 437.

1. Set the following registry keys (save as .reg and import). For some reason, it i important to change FontFamily, as the default may be different, and the font won't be applied.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Console]
"FaceName"="Consolas"
"FontFamily"=dword:00000036
"FontSize"=dword:000f0000
"FontWeight"=dword:00000190
"CodePage"=dword:0000fde9

1. Win+R cmd.exe ENTER. Console starts with the correct font and code page. Type chcp; it prints 65001 (if does not, run chcp 65001).
2. in the console, type powershell -noprof ('-noprof' to confirm that the issue is not related to anything I load in my profile).

As PowerShell starts, the console font immediately changes to a raster font, and the window resizes to accommodate. The raster font selected is Terminal, and does not even even have WGL4 characters (no Cyrillic or Greek). So this is certainly a bug.

The behavior reproduces even if running a non-interactive command, so it's rather doubtful that the bug is related to PSReadLine:

powershell -noprof -nonint -command "echo foo"

Also, the console font changes similarly (essentially, the console opens in a raster font) if PowerShell is ran via a shortcut, or from the Win+R dialog, or by double-clicking in Explorer.

Also, some negatives. The font is not changed if either:

• I run chcp 437 before invoking powershell from cmd.
• The console font is set in the registry to "Lucida Console" (everything else stays same as above). That this font is somehow "special" has been already noted in the comments in this ticket.

The common theme in the comments in this issue has been, I believe, a non-US, European locale (German ans Spanish were mentioned). So i tried the following:

1. Start cmd.exe
2. Set console code page with chcp NNN (see below):
3. Run powershell -noprof.

• With NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - no font change
• With NNN = 65001, 858, and non-WGL4 Hebrew 862, Arabic 864 - font does change.

What sets the CP 858 apart? My guess is this may be the key. The CP name is "OEM Multilingual Latin 1 + Euro symbol".

Also notable is that chcp 1255 and chcp 1266 (Hebrew and Arabic) change font to "Courier New" even in cmd.exe. So PowerShell may be only somehow more susceptible, not the main culprit?

Obligatory version info:

C:\Users\kkm> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17763.134
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.134
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Also, I should mention, although this is most likely irrelevant: I have a high-DPI display with the display scale set to 150%.

@kkm000 This was fixed in PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771), but isn't in the build of Windows you are using, although the fix was checked into a newer build of Windows. I believe the newest public Beta of PSReadLine has the fix, so you can install it in Windows PowerShell using:

install-module psreadline -AllowPrerelease -Repository PSGallery -Force
# restart PowerShell to load the new one

If it complains that -AllowPrerelease isn't found, you'll have to update PowerShellGet:

install-module powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber
# restart PowerShell to load the new one

although the fix was checked into a newer build of Windows.

Does this mean that the fix will be coming to a future (19H1) Insiders release?

@50Wliu yes

@SteveL-MSFT i have the same version like @kkm000 , i ran you commands and not work for me, i miss something?

@SteveL-MSFT I find it very disappointing that this cannot be shipped with a regular Windows Update. If Microsoft breaks something with an update, it's their responsibility to fix it with an update and not postpone it for over six months and plan to ship it with the next Windows version, or have people jump through hoops to get a hotfix from a pre-release repository (which doesn't even work for everyone).

so.... I had to run that command more than once

install-module powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber

with powershell running as admin, taskmgr to kill powershell and then do it again since it failed two or three times. And … looks like its working! The customized display settings in my $PROFILE are now behaving as they were before the upgrade.

This has just started to happen to me after the upgrade to the latest 1809 17763.292 build from the previous 1809 cumulative update. I followed the instructions to install the new PSReadLine and it seems to be there:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
I have

PSVersion 5.1.17763.134

Consolas font gets replaced with raster fonts.

UPDATE

this seems to by unstable fix. Now after reboot the fix is holding/working, regardless of run level.

Interesting behavior I am now seeing. After running the 'fix' on my laptop
Name Value
---- -----
PSVersion 5.1.17763.134
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.134
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

when running PS in user mode, fix is fine; when running PS as admin, fix does not work.

Doesn't work for me even in user mode.

@SteveL-MSFT, looks like the fix does not work for me. Also, it does not seem that the Install-Module has changed anything. I already have a pretty latest PowerShellGet (-AllowPrerelease certainly works; my key bindings depend on a recent PSReadLine). I've initially installed PSReadLine a few months ago (before upgrading Windows!), so I expected that I will get an upgrade today with your suggested command, but I have no idea how to confirm if anything has been in fact changed. Could you please help? I took the version of PSReadLine before attempting the upgrade:

C:\WINDOWS\system32> date

Saturday, February 2, 2019 13:46:02

C:\WINDOWS\system32> Get-Module PSReadline | fl Version

Version : 2.0.0

C:\WINDOWS\system32> Get-Module PSReadline | fl *

LogPipelineExecutionDetails : False
Name                        : PSReadline
Path                        : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.psm1
ImplementingAssembly        :
Definition                  : function PSConsoleHostReadLine
                              {
                                  Microsoft.PowerShell.Core\Set-StrictMode -Off
                                  [Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
                              }

Description                 : Great command line editing in the PowerShell console host
Guid                        : 5714753b-2afd-4492-a5fd-01d9e2cff8b5
HelpInfoUri                 : https://go.microsoft.com/fwlink/?LinkId=528806
ModuleBase                  : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0
PrivateData                 : {PSData}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    : https://www.powershellgallery.com/api/v2/
Version                     : 2.0.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0.0
CompanyName                 : Microsoft Corporation
Copyright                   : (c) Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      : 4.6.1
ExportedFunctions           : {[PSConsoleHostReadLine, PSConsoleHostReadLine]}
Prefix                      :
ExportedCmdlets             : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
ExportedCommands            : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {Microsoft.PowerShell.PSReadLine}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : PSReadLine.psm1
ExportedVariables           : {}
ExportedAliases             : {}
ExportedWorkflows           : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.format.ps1xml}
ExportedTypeFiles           : {}

Then I upgraded, as you suggested:

C:\WINDOWS\system32> install-module psreadline -AllowPrerelease -Repository PSGallery -Force
C:\WINDOWS\system32> exit

The Install-Module churned for a while, and a progress bar with the sting of 'o's streaked at the top of the screen. I do not believe this means anything, but repeating the Install-Module also causes the progress bar to appear for a brief moment. But the new console still suffers from the original problem. Also, I do not see any changes here, maybe you could spot something? I can certainly look at file versions etc. that I have, I only do not know what to look for.

This did not do anything either:

C:\WINDOWS\system32> Update-Module PSReadLine -AllowPrerelease
C:\WINDOWS\system32>

In the new console, the new(?) PSReadLine seems same:

C:\WINDOWS\system32> Get-Module PSReadline | fl *

LogPipelineExecutionDetails : False
Name                        : PSReadline
Path                        : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.psm1
ImplementingAssembly        :
Definition                  : function PSConsoleHostReadLine
                              {
                                  Microsoft.PowerShell.Core\Set-StrictMode -Off
                                  [Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
                              }

Description                 : Great command line editing in the PowerShell console host
Guid                        : 5714753b-2afd-4492-a5fd-01d9e2cff8b5
HelpInfoUri                 : https://go.microsoft.com/fwlink/?LinkId=528806
ModuleBase                  : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0
PrivateData                 : {PSData}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    : https://www.powershellgallery.com/api/v2/
Version                     : 2.0.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0.0
CompanyName                 : Microsoft Corporation
Copyright                   : (c) Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      : 4.6.1
ExportedFunctions           : {[PSConsoleHostReadLine, PSConsoleHostReadLine]}
Prefix                      :
ExportedCmdlets             : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
ExportedCommands            : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {Microsoft.PowerShell.PSReadLine}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : PSReadLine.psm1
ExportedVariables           : {}
ExportedAliases             : {}
ExportedWorkflows           : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.format.ps1xml}
ExportedTypeFiles           : {}

Also, due to @mjoyce6500 and @wigster comments above, I checked the user (non-admin) console, and it also shows the bug as it did before.

Please, I'll appreciate any help/thoughts you might share!

@SteveL-MSFT, @lzybkr, I do not think there is an update in PSGallery. The latest beta had been published a month before the issue lzybkr/PSReadLine#771 was merged:

C:\WINDOWS\system32> Find-Module PSReadline -Repository PSGallery -AllVersions -AllowPrerelease | ft name,ver*,pub*

Name       Version     PublishedDate
----       -------     -------------
PSReadLine 2.0.0-beta3 2018-09-04 21:59:13
PSReadLine 2.0.0-beta2 2018-06-04 20:28:42
PSReadLine 2.0.0-beta1 2017-12-06 07:22:16
PSReadLine 1.2         2016-01-25 20:43:22
PSReadLine 1.0.0.13    2015-02-18 00:28:18
PSReadLine 1.0.0.12    2014-08-26 19:04:26
PSReadLine 1.0.0.11    2014-06-13 21:15:30
PSReadLine 1.0.0.10    2014-06-13 02:21:13
PSReadLine 1.0.0.9     2014-06-11 21:20:46
PSReadLine 1.0.0.8     2014-05-07 22:20:52

Unfortunately, it does not include ReleaseNotes any more, like beta2 did. But timing certainly excludes this possibility.

Unrelated note, Author and Company are apparently swapped:

C:\WINDOWS\system32> Find-Module PSReadline -req 2.0.0-beta3 -Repository PSGallery -AllowPrerelease | fl author,compan*

Author      : Microsoft Corporation
CompanyName : lzybkr

The 'fix' still has mixed results for me. Powershell in user mode is working fine, no change to my custom colors/fonts after running the command noted above. Though Powershell in Admin mode not fixed, shows the behavior noted in this bug.

@mjoyce6500 can you give me exact repro steps? Also note what build of Windows and PSReadLine you are using. Thanks.

@SteveL-MSFT, could you please have a look at my comment above? I cannot even find the updated version of PSReadLine in PSGallery, while other people report "mixed results." As of right now, the highest available version is still PSReadLine 2.0.0-beta3 18-09-04 21:59:13, published a month before the fix was merged.

Also, how do I find out the version that I am using? On another machine, where I never attempted your update suggestion, checking the first line of the file Changes.txt from the installed package:

C:\WINDOWS\system32> Get-Module PSReadline | fl version,modulebase

Version    : 2.0.0
ModuleBase : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0

C:\WINDOWS\system32> gc "C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\Changes.txt" | select -first 1
### Version 2.0.0-beta2

Then, Install-Module indeed attempts to install 2.0.0-beta3, confirm by running without -force:

C:\WINDOWS\system32> install-module psreadline -AllowPrerelease -Repository PSGallery
WARNING: Version '2.0.0-beta2' of module 'PSReadline' is already installed at 'C:\Program
Files\WindowsPowerShell\Modules\PSReadline\2.0.0'. To install version '2.0.0-beta3', run Install-Module and add the -Force parameter, this command will install version '2.0.0-beta3' side-by-side with version '2.0.0-beta2'.

Is it possible that I am getting the update not from somewhere other people do?

After the update, the Changes.txt has 2.0.0-beta3 header as the first line:

C:\WINDOWS\system32> gc "C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\Changes.txt" | select -first 1
### Version 2.0.0-beta3

And the same reproduction as before, admin console or not. From cmd.exe console with Consolas font:

C:\WINDOWS\system32>chcp 65001
Active code page: 65001

C:\WINDOWS\system32>powershell -noprof -nonint
==== BOOM! font changes ===
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\WINDOWS\system32>

Of course, I do not expect it to work, as I do not have the updated DLL. My question is, how it is possible that other people may have it.

Having the same problem here, and the above fix has had no effect.

It is still mindboggling how the fix worked (at least partially) for the minority of people, given that it was never released, looking from behind this pair of eyes. To say I am baffled is to say nothing. My current thinking is there are TWO PS galleries, and the fix has been published to the one of them which only a few people are accessing.

@kkm000 There is one PSGallery and beta.3 is the latest PSReadLine published. The version of PSReadLine 2.0.0 that ships in Win10 is a fork of PSReadLine 2.0.0 with some newer specific fixes taken so in that sense it is ahead of the one published on PSGallery.

@SteveL-MSFT
I installed beta3 and nothing is resolved.
Both with Windows 1809 and 1903 (Build 18334.1)

@Borkason the fix for not changing the font if not using a raster font should already be in that build. What font are you using?

I'm using Consolas. It switches back after every restart of the PowerShell.

@Borkason what locale are you using? en-US or something else?

de-DE

It's suddenly working now. Took me like 10 times closing and opening the powershell, but now it seems to stick.

It broke again. So apparently it randomly decides to break again, or work. 💢

I had it happen with 18334 -- completely randomly. Didn't happen again.

Okay, so the difference is that when I run powershell via ALT-R, then the font stays the same. When I run it from the start menu, then it resets the font to raster, even when I changed it to consolas in the previous session that I ran from the start menu.

(And by start menu I actually mean that I press the Windows key on the keyboard and then type 'powershell' and press enter.)

@SteveL-MSFT - I have not published a release with the font fix to the PowerShell gallery. The fix is available in the PSReadLine repo though, so you can build it yourself or grab a build from AppVeyor.

@Borkason - If you're using Consolas then I think you shouldn't be seeing the font bug.

It remains difficult to set console defaults because of backwards compatibility. Defaults can be set in the registry (per console application) or in the shortcut used to start the console application. I know the console team wants to solve that problem, but it is apparently a hard problem.

If you're using Consolas then I think you shouldn't be seeing the font bug.

Then this bug is not resolved, because I am using Consolas and the shortcut does, too.

It remains difficult to set console defaults because of backwards compatibility.

Then Microsoft should provide a script/FixIt-tool for those who just want their console to work again, regardless of backwards compatibility ...

I know the console team wants to solve that problem, but it is apparently a hard problem.

Apparently. And it's obvisouly also excruciatingly hard to put the damn PowerShell half-fix into 1809, not to mention 1903 ...

😠

I just updated to 18342 and the issue seems to be fixed (18334 still reset to raster fonts each time).

I still agree that the fix should be backported to 1809.

EDIT: Misconfiguration issue on upgrade (see https://github.com/Microsoft/console/issues/280#issuecomment-474917761). The bug still isn't fixed.

I just did a fresh install of 20H1. Problem is still there. 🤣 This is a joke, right?

This can be fixed by installing the 1809 windows 10 Rsat tools.
You cannot install RSAT on computers that are running Home or Standard editions of Windows.
You can install RSAT only on Windows 10 Professional or Enterprise editions.

Method 1 – Using Add a Feature Install RSAT Tools on Windows 10 version 1809

To install RSAT Tools on Windows 10 version 1809, click Start. Click Settings and from the settings page, click Apps.
On the right pane, under Apps & features, click Manage optional features.
Now click + Add a feature.Wait for the list of features to be populated.
Scroll down until you see RSAT features.
Now select any of the RSAT feature that you wish to install. In this case, I am selecting RSAT: Group Policy Management Tools feature.
Click Install.
Click the back icon and wait until the feature is installed.
Now you should find Group Policy Management Tools under Start > Windows Administrative Tools.

works sited.... Install RSAT Tools on Windows 10 version 1809 and later
By Prajwal Desai Last updated Jan 31, 2019

Hope this helps....

@RobRoberson you really understand what you are saying, right?

I have the same issue on windows 1809 17763.316.
zh_Hans_CN with the UTF-8 option enabled.

Will preview versions solve the problem ?

Will preview versions solve the problem ?

No.

I take back what I said in https://github.com/Microsoft/console/issues/280#issuecomment-465837677. What actually happened was that all my language settings got reset, which turned off the 65001 codepage. I just realized that today, switched it back on, and...hello raster fonts.

@SteveL-MSFT this comment of yours seems incorrect by the amount of people still saying that this issue is unresolved, even on the latest Insider builds (I'm on 18361 right now, for example).

Would love a fix on this. Really like Consolas for development under Windows.

Using the internal Microsoft 1903 release can confirm this bug still exists for Consolas and UFT8. Lucida Console font works though and will be my workaround

We're working on a new update to PSReadLine, then we'll see about getting it into Windows

On pwsh 6.2.0, this issue seemed to have been resolved, but it's come back after I use msbuild 2017 to build anything (the 2015 version was fine). I'm not sure where exactly this is happening because it's from node-gyp, but if native modules need to be (re)built, my console will revert back to raster fonts.

Thankfully, I no longer have to reset the fonts every single time I open the terminal, only when running node-gyp.

PSReadLine 2.0.0-beta4 was published that should address many issues (although it has a few new ones) . https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@SteveL-MSFT 2.0.0-beta4 didn't fix this bug.

I use regular CMD terminal with git's bash.exe + phpunit = same problem. It appear after few seconds of script start working.
Not sure the reason in PowerShell...

@SteveL-MSFT 2.0.0-beta4 does not fix the bug for me either.

@sebgod Thanks for the tip, I've switched from Consolas 16 to Lucida Console 14, it's about the same to my eyes.

I'll have someone look into this again

@SteveL-MSFT To replicate this, open a command prompt, set your font to Consolas,
and then run cmd /c chcp 65001 >NUL && powershell

Ok, I think I identified the actual issue and it doesn't have anything to do with PSReadLine. There is a check in Windows PowerShell to see if the code page is supported by the Consolas font. The list is here. UTF-8 65001 isn't in that list, so whenever Windows PowerShell identifies a code page that isn't supported by Consolas, it will change the font to Terminal. PowerShell Core 6.x doesn't have this code anymore so you don't see this behavior. I'm hesitant of changing this code as it may break something else. For my own notes, this is in ConsoleControl.cs line 2648.

Ok, I think I identified the actual issue and it doesn't have anything to do with PSReadLine. There is a check in Windows PowerShell to see if the code page is supported by the Consolas font. The list is here. UTF-8 65001 isn't in that list, so whenever Windows PowerShell identifies a code page that isn't supported by Consolas, it will change the font to Terminal. PowerShell Core 6.x doesn't have this code anymore so you don't see this behavior. I'm hesitant of changing this code as it may break something else. For my own notes, this is in ConsoleControl.cs line 2648.

Not sure how can this break something, as UTF-8 was not supported prior to the most recent Windows 10 versions.

@sebgod break something here means incorrect rendering as I'm sure Consolas doesn't have all the glyphs needed by UTF-8

@SteveL-MSFT Lucida Console, Courier New and all the other available fonts that are not affected by this issue although they also do not support codepage 65001 either. Coincidentally, Consolas even supports more codepages than Lucida Console. So why does this happen with Consolas only?

But generally speaking, it should be the users decision what font is used for display. If glyphs are not present, they are displayed as � and the user can make a decision to change the font.

@Borkason I think it's a very clear-cut issue from a native English-speaker's perspective, but there is no doubt a fear of causing problems for international users that we are not able to foresee.

As an example, when @bitcrazed (another member of the Microsoft Terminal team) introduced a PR to cURL that would implement Windows VT support https://github.com/curl/curl/pull/3011 (which involved changing the code page to 65001), it ended up causing an issue for international users: https://github.com/curl/curl/issues/3211

This necessitated a patch that writes UTF-8 in the current code page using wide string APIs instead: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9

It doesn't surprise me that the Microsoft Terminal team is wanting to approach this very carefully after that.

@sebgod break something here means incorrect rendering as I'm sure Consolas doesn't have all the glyphs needed by UTF-8

OK, there is not a single font supplied by Windows that covers all Glyphs defined in UTF-8. Cmd.exe relies on a technology called font linking to provide rendering for all glyphs.
Prior to the inclusion of setting UTF-8 as the system codepage, one had to use chcp 65001 manually, but it was working properly. The font linking bit has to be done manually in the registry to get it working in any case.

@ImportTaste I don't think that has anything to do with it. The fallback only comes in effect if Consolas is used. If any other font is used like Lucida Console or Courier New, then this does not happen. At least Lucida Consolas has the same code page support as Consolas, so it's hard to understand why it was done this way. If there would be an issue for international users (and by the way, I am not a native english-speaker like you assume) it would still affect all the users that are not using Consolas.

The way I see it, the fallback shouldn't be there in the first place (see PWSH 6+7) or was implemented sloppy (why only Consolas?).

@SteveL-MSFT And I believe fixing it is not a risk at all, because the bug was introduced only with Windows version 1809 and apparently it's an undocumented change a.k.a. no one knows why specifically it was changed.

@Borkason As I said, it was a relatable example of something unexpected going wrong.

I'm surprised to hear it's supposedly only an 1809 change, I've had issues with the console font changing itself to raster in the past.

It was only detected in 1809 because the default font for the console was Consolas. Prior to that, I believe it was Lucida Console? And the code worked the same way for that font. My understanding of that code (which has been there since forever and prior to my team on the PowerShell Team) is that in the Windows sources, we only have one shortcut used for PowerShell and that shortcut defines the default font. So when the default font was changed, East Asian users complained as their glyphs weren't being rendered since the font doesn't support it. So this code detects that the font and locale aren't compatible and switches it to one that will render.

I'm hesitant on making any changes in Windows PowerShell as even seemingly small changes like this lead to unexpected regressions.

@sebgod & all: A few things here:

Clarifications

1. There is no single font on any platform that includes every glyph for every code-point that can be represented in UTF-8.
2. Cmd.exe knows nothing about fonts - Cmd.exe is a shell
3. Console (ConHost.exe) provides the traditional 'terminal-like' command-line UX in Windows
4. Console's current text rendering engine does not support font-fallback and cannot render most emoji - try it and you'll see the non-displayable character (question mark in a box)

Terminal & Console

Windows Terminal is our new next-gen Terminal UX. It shares several common components with the in-box Console, plus it adds several new features including a text buffer and text renderer which can/will store and display practically all Unicode glyphs.

These components will, eventually, be re-ingested into the in-box Console, but not until after we've released Terminal v1.0 and they've had time to be well-tested in real world use.

PowerShell

As @SteveL-MSFT points out, PowerShell Core (PSCore) does not exhibit this issue and since PSCore is the future of PowerShell, we encourage you to use it wherever possible.

Changing the behavior of PowerShell for Windows (PS) is potentially difficult because as we know from trying to fix/change the behavior of Cmd, even small seemingly innocuous changes can result in surprising breakage in the real world.

This said, I'll discuss with Steve & Team and we'll explore if PS could be modified to choose a non-raster font (e.g. Consolas/Lucida/etc.) for code-page 65001.

@sebgod & all: A few things here:

Clarifications

1. There is no single font on any platform that includes every glyph for every code-point that can be represented in UTF-8.

Yes, that is why I said "there is not a single font supplied by Windows that covers all Glyphs defined in UTF-8"

1. Cmd.exe knows nothing about fonts - Cmd.exe is a shell

Yes sorry for being lazy I just meant to refer to what happens if you type "cmd.exe" in the Windows search box

1. Console (ConHost.exe) provides the traditional 'terminal-like' command-line UX in Windows
2. Console's current text rendering engine does not support font-fallback and cannot render most emoji - try it and you'll see the non-displayable character (question mark in a box)

As I understood the current engine cannot render any characters from higher Unicode planes, which includes (most) emoji characters.

Now I have to be nit picky, I was talking about Font Linking, which is supported or at least working:

By adding the value Lucida Console under key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
with type REG_MULTI_SZ and the following data (or similar, should be monospaced fonts):

MSGOTHIC.TTC,MS UI Gothic
MINGLIU.TTC,PMingLiU
SIMSUN.TTC,SimSun
GULIM.TTC,Gulim
YUGOTHM.TTC,Yu Gothic UI
MSJH.TTC,Microsoft JhengHei UI
MSYH.TTC,Microsoft YaHei UI
MALGUN.TTF,Malgun Gothic
SEGUISYM.TTF,Segoe UI Symbol

It is possible to show most Unicode basic plane glyphs when using chcp 65001 or since 1803 by setting the system codepage to UTF-8 (beta but working so far), which I personally prefer to use the specific code pages for each language as I use multiple languages.

Now I prefer to use Consolas which was not working since 1903 due to it switching to raster fonts.

Terminal & Console

Windows Terminal is our new next-gen Terminal UX. It shares several common components with the in-box Console, plus it adds several new features including a text buffer and text renderer which can/will store and display practically all Unicode glyphs.

These components will, eventually, be re-ingested into the in-box Console, but not until after we've released Terminal v1.0 and they've had time to be well-tested in real world use.

Yes I have used the new Terminal UX already and it is of course extremely pleasant to use, but it does not allow to input Chinese characters at the moment (I hope this will be fixed eventually)

PowerShell

As @SteveL-MSFT points out, PowerShell Core (PSCore) does not exhibit this issue and since PSCore is the future of PowerShell, we encourage you to use it wherever possible.

Changing the behavior of PowerShell for Windows (PS) is potentially difficult because as we know from trying to fix/change the behavior of Cmd, even small seemingly innocuous changes can result in surprising breakage in the real world.

This said, I'll discuss with Steve & Team and we'll explore if PS could be modified to choose a non-raster font (e.g. Consolas/Lucida/etc.) for code-page 65001.

If changes can break something and we even can not know what exactly, so nothing can be changed in the terminal ever again?

I "fixed" the problem by using Powershell Core. I first noticed that none of the Powershell settings does anything (but it did change the settings on cmd.exe). After a couple hours of trying different things I stumpled upon Powershell Core and as soon as I downloaded it, the settings I saved before took effect as soon as I opened the Powershell core preview.

Got the same issue while running some of commands (including scoop) from FAR manager - this effect just ruins how FAR is shown. Happens only with Consolas font and beta option enabled to use UTF-8 (65001) codepage in console. My locale is Russian.

As end-user - It's really annoying when program tries to be smarter than me. I can live with question marks instead of some of UTF-8 symbols, but this font changing just ruins display of programs that shouldn't be affected at all, like FAR manger. This is a pain.

For now I had to revert to Russian locale for console (back from UTF-8), yet this limits working with files named using symbols of other locales. I hope you can remove that special Consolas treating.

I have the same issue but only if i try to use consolas. probably @SteveL-MSFT is right.
I tried Lucida Console and this is working fine. So i guess Consolas is missing some glyphs for utf-8 (my codepage)?!
Powershell Core 7 works fine with all fonts.

Incredible, I bought a Windows laptop in 2020 (xps15) and I have the same issue. Probably hundreds of Windows updates later, and the problem persist. If PS Core was the future in 2019, why is not installed in 2020? The PS Core could be default, and maybe the old PS could be installed as fall back in case some one need for compatibility issue. Anyway, I installed the Windows Terminal and let's try it.

@marcelomgarcia FWIW, the reason that PowerShell 7 is not installed in Windows by default is due to support and liability issues. Windows and PowerShell 7 have different support and so far as I can tell, the lawyers have not figured out a way to do it. For now, anyway. I am sure that everyone would love to see PowerShell 7 shipped inside Windows 10 or Windows Server.

Rember: Windows PowerShell is a core component of Windows 10 and the default installer adds it to your installed on your laptop. It is a fully supported component FWIW. IF you want PowerShell 7, however, that is a separate and non-integrated installation process.

What language is your computer?

Thanks for the explanation @doctordns. It's just somewhat frustrating issue, and for someone outside seems to be a "simple" problem. I'm install PowerShell 7.

I use English US.