Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Borkason opened this issue Oct 11, 2018 · 78 comments

Comments

@Borkason
Copy link

commented Oct 11, 2018

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

@50Wliu

This comment has been minimized.

Copy link

commented Oct 14, 2018

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.

@Borkason

This comment has been minimized.

Copy link
Author

commented Oct 15, 2018

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

@zadjii-msft

This comment has been minimized.

Copy link
Member

commented Oct 15, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 15, 2018

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Oct 15, 2018

  • 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

This comment has been minimized.

Copy link
Member

commented Oct 15, 2018

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

This comment has been minimized.

Copy link

commented Oct 17, 2018

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

@cloudhan

This comment has been minimized.

Copy link

commented Oct 17, 2018

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

@bitcrazed

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2018

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

@50Wliu

This comment has been minimized.

Copy link

commented Oct 17, 2018

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Oct 19, 2018

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Oct 19, 2018

@doctordns which font?

@doctordns

This comment has been minimized.

Copy link

commented Oct 19, 2018

@doctordns which font?

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Oct 19, 2018

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 comment has been minimized.

Copy link
Contributor

commented Nov 12, 2018

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

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

Thanks.

@50Wliu

This comment has been minimized.

Copy link

commented Nov 13, 2018

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Nov 15, 2018

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Nov 15, 2018

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

@lzybkr

This comment has been minimized.

Copy link
Member

commented Nov 15, 2018

@bitcrazed linked to the issue that caused the problem.

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Nov 15, 2018

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

@lzybkr

This comment has been minimized.

Copy link
Member

commented Nov 15, 2018

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

This comment has been minimized.

Copy link

commented Nov 29, 2018

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!

@WenqiangXieIgg

This comment has been minimized.

Copy link

commented Dec 13, 2018

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

This comment has been minimized.

Copy link

commented Dec 26, 2018

Same here. Both my Surface & desktop PC.

@offero

This comment has been minimized.

Copy link

commented Jan 13, 2019

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

This comment has been minimized.

Copy link

commented Jan 13, 2019

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

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Jan 15, 2019

@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
@50Wliu

This comment has been minimized.

Copy link

commented Jan 15, 2019

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?

@RobRoberson

This comment has been minimized.

Copy link

commented Mar 11, 2019

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

@yw662

This comment has been minimized.

Copy link

commented Mar 11, 2019

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Mar 11, 2019

Will preview versions solve the problem ?

No.

@50Wliu

This comment has been minimized.

Copy link

commented Mar 20, 2019

I take back what I said in #280 (comment). 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).

@wbeeftink

This comment has been minimized.

Copy link

commented Apr 16, 2019

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

@sebgod

This comment has been minimized.

Copy link

commented Apr 20, 2019

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

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Apr 24, 2019

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

@miniksa miniksa added the Mass-Chaos label May 17, 2019

@msftbot msftbot bot added the Needs-Tag-Fix label May 17, 2019

@msftbot msftbot bot removed the Needs-Tag-Fix label May 18, 2019

@50Wliu

This comment has been minimized.

Copy link

commented May 20, 2019

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.

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented May 23, 2019

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Jun 15, 2019

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

@SailorMax

This comment has been minimized.

Copy link

commented Jun 27, 2019

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

@ghost

This comment has been minimized.

Copy link

commented Jul 24, 2019

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

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Jul 25, 2019

I'll have someone look into this again

@ghost

This comment has been minimized.

Copy link

commented Jul 30, 2019

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

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Aug 2, 2019

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.

@sebgod

This comment has been minimized.

Copy link

commented Aug 2, 2019

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.

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Aug 3, 2019

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Aug 3, 2019

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

@ImportTaste

This comment has been minimized.

Copy link

commented Aug 3, 2019

@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 curl/curl#3011 (which involved changing the code page to 65001), it ended up causing an issue for international users: curl/curl#3211

This necessitated a patch that writes UTF-8 in the current code page using wide string APIs instead: mattn/curl@1d39418

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

@sebgod

This comment has been minimized.

Copy link

commented Aug 5, 2019

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

@Borkason

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

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

@ImportTaste

This comment has been minimized.

Copy link

commented Aug 6, 2019

@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

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.