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

[danielniccoli]

Windows 10 1809 breaks Powershell's console settings. Powershell keeps opening with raster fonts. You can change the settings and see the result, but when you open the settings again (with or without closing the powershell inbetween) the font has reset to raster fonts in size 12.

Edit: Upgraded from 1803. German Locale.

https://aka.ms/AA37kk1

[winstliu]

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.

[danielniccoli]

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

[zadjii-msft]

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?

[SteveL-MSFT]

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

[danielniccoli]

• 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.

[miniksa]

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.

[doctordns]

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

[cloudhan]

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

[bitcrazed]

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

[winstliu]

@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)

[danielniccoli]

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

[danielniccoli]

@doctordns which font?

[doctordns]

@doctordns which font?

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

[danielniccoli]

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.

[bitcrazed]

This was likely fixed by @lzybkr's recent work: PowerShell/PSReadLine#542

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

Thanks.

[winstliu]

@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.

[danielniccoli]

@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.

[danielniccoli]

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

[lzybkr]

@bitcrazed linked to the issue that caused the problem.

The fix is in this PR: PowerShell/PSReadLine#771

[danielniccoli]

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

[lzybkr]

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.

[kid1412621]

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!

[ghost]

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.

[xhxgit]

Same here. Both my Surface & desktop PC.

[offero]

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.

[kkm000]

@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

2. 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).
3. 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%.

[SteveL-MSFT]

@kkm000 This was fixed in PSReadLine (PowerShell/PSReadLine#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

[winstliu]

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?

[sebgod]

@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.

[danielniccoli]

@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.

[God-damnit-all]

@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.

[SteveL-MSFT]

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.

[bitcrazed]

@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]

@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"

2. 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

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)

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.

[sergei-bondarenko]

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

[edyu]

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.

[CHerSun]

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.

[dermoritz]

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.

[marcelomgarcia]

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.

[doctordns]

@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?

[marcelomgarcia]

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.

[alex-jitbit]

Observation: if you have a BAT file where you call powershell script.ps1 two times the second call resets font to raster.

Inserting chcp 437 between the calls helps.

More info https://superuser.com/questions/706562/why-does-running-powershell-change-my-console-font

[God-damnit-all]

Observation: if you have a BAT file where you call powershell script.ps1 two times the second call resets font to raster.

I've confirmed it and I can see why this happens. Here's a script that illustrates the issue (and I tossed in my sleep function for funsies):

@echo off && @echo|set /p="chcp; Write-Host "$args run complete"" > "%TEMP%\test.ps1"

echo/This test assumes your default code page is 437 and your console font is set to Consolas (or another font that the raster font bug occurs with)
call:sleep 5
echo/
echo/This should say the active code page is 437 . . .
chcp
call:sleep 3
echo/
echo/Running test.ps1 for the first time . . .
call:sleep .25
powershell.exe -ExecutionPolicy Unrestricted -File "%TEMP%\test.ps1" "First"
call:sleep 3
echo/
echo/As you can see, the code page in PowerShell was changed to 65001, but after exiting, it still persists . . .
call:sleep 1.5
chcp
call:sleep 3
echo/
echo/Now, watch what happens when we go into PowerShell with the code page already set to 65001 . . .
call:sleep 4
echo/
echo/Running test.ps1 for the second time . . .
call:sleep .25
powershell.exe -ExecutionPolicy Unrestricted -File "%TEMP%\test.ps1" "Second"
del "%TEMP%\test.ps1"
call:sleep 3
echo/
echo/Assuming the bug is replicated, the console is now using a raster font
call:sleep 3
echo/
echo/This concludes the test
call:sleep 1.5
echo/
echo|set /p="[Done]" & runas /user:# "" >NUL 2>&1
exit /b0

::Sleep function
:sleep
setlocal EnableDelayedExpansion
set x=%1.
set dec=%x:*.=%
set int=!x:.%dec%=!
set dec=%dec:.=%
set dec=%dec:~0,3%
if "%dec%"==".=" set dec=1000
if "%dec%"=="~0,3" set dec=1000
if %dec% LSS 10 set dec=%dec%00
if %dec% LSS 100 set dec=%dec%0
ping 203.0.113.0 -n 1 -w %int%%dec:~-3% >NUL
endlocal

Inserting chcp 437 between the calls helps.

You can also put chcp 437 >$NULL in the ps1 file to prevent it as well.

[alabuzhev]

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.

@SteveL-MSFT, after #10472 & #10477 this is no longer the case - Consolas should be able to render everything.
You might want to reconsider this and other similar workarounds, if any.

[githubkuyaya]

If your default codepage is 65001, this fix worked for me:
run intl.cpl -> Administrative -> Change system locale -> Uncheck "Beta: Use Unicode [...] language support -> reboot

This resets the codepage for PowerShell from 65001 to your local codepage (e.g. 437, 850) and it won't reset to raster font again.
For reference, see this post

[CHerSun]

If your default codepage is 65001, this fix worked for me:
run intl.cpl -> Administrative -> Change system locale -> Uncheck "Beta: Use Unicode [...] language support -> reboot

This resets the codepage for PowerShell from 65001 to your local codepage (e.g. 437, 850) and it won't reset to raster font again.
For reference, see this post

This is a system-wide setting, which breaks older apps, that use regional code pages. I mean enabling the UTF-8. Should be off by default (beta).

[magiblot]

In case it may be useful:

If you want to work around this issue but you also need PowerShell to print Unicode text, you may switch to codepage 437 before running PowerShell and then change the console encoding from within PowerShell.

For example, to get the clipboard contents in UTF-8:

chcp 437 > NUL
powershell -NoProfile -NoLogo -NonInteractive "([Console]::OutputEncoding = [System.Text.Encoding]::UTF8) -and (Get-Clipboard -Raw | Write-Host -NoNewLine) | Out-Null"

This works for me using PowerShell 5.1.19041.1682, Windows 21H1.

[NikitaBeloglazov]

chcp 437 > NUL
powershell -NoProfile -NoLogo -NonInteractive "([Console]::OutputEncoding = [System.Text.Encoding]::UTF8) -and (Get-Clipboard -Raw | Write-Host -NoNewLine) | Out-Null"

@magiblot, Thank you so much! This helped me a lot ❤️