Weird behavior for installed fonts after Windows 11 22H2 update

[mkvlrn]

TL;DR:

Fonts installed (they were installed before the update) appear to be installed but do not work - installing them manually from the cache folder works.

Not really sure if this should be opened here or elsewhere, could be a manifest problem? Here's what happened:

I have 2 NF fonts installed from this bucket: firacode-nf-mono for vscode and hack-nf-mono for the terminal. They are used with the names "FiraCode NFM" and "Hack NFM", respectively, and have been working fine for months.

Day after my windows 11 22h2 update, when I opened windows-terminal I've received the warning that "Hack NFM" coulndn't be found and it defaulted to Consolas. Checked scoop list, fonts still there. Checked the "Fonts" control panel applet, fonts are there.

But I cannot find them in a list, for example, trying to change Notepad's font. They are not there.

So I uninstall and reinstall both, restart computer, same problem.

BUT - after uninstalling them again, I go to scoops cache folder, see the .ttf files, and try to install them manually - by double clicking and hitting "Install". It worked! They appear exactly the same as before in the "Fonts" applet, but now are also listed on the font change dropdown for apps and work correctly as before.

Repeated the process 3 times to check my own sanity, it happened as described again and again.

[gitolicious]

Had the same problem and just now understood that it broke with the 22H2 update. Thanks for the workaround which at least temporarily fixes the problem.

[mrjohannchang]

I believe the root cause is: microsoft/terminal#3257

[mkvlrn]

I believe the root cause is: microsoft/terminal#3257

It's not only on windows-terminal, it's system wide. It also happens to vscode, notepad, any applications. It's like the font was never installed to begin with.

[hfziu]

Same issue here. I just did a fresh re-install of Windows 11 22H2. I then installed JetBrainsMono NF font via scoop. This puts the font files into %LOCALAPPDATA%\Microsoft\Windows\Fonts.

I can even successfully set the font in Windows Terminal. The weirdest part is that the setting won't survive a system reboot.

After reboot:

• I navigated into %LOCALAPPDATA%\Microsoft\Windows\Fonts, and the font files are still there;
• I can still select the fonts in Windows Terminal settings, and the font preview in the settings page works well:
• However, Windows Terminal complained that the font could not be found when I clicked 'Save'.
  
• Other apps, e.g., VS Code, could not recognize the fonts either.

[FDUZS]

Same issue here.

And for me, it happens after the installation of
2022-10 Cumulative Update for Windows 11 Version 22H2 for x64-based Systems (KB5018427)
yesterday.

---

ADD:
It seems like this issue only happens to nerd-fonts like JetBrainsMono-NF (scoop install JetBrainsMono-NF), while JetBrains-Mono (scoop install JetBrains-Mono) has no such thing. Can you guys reproduce this?

[rozbo]

me too......

[hfziu]

It seems like this issue only happens to nerd-fonts like JetBrainsMono-NF (scoop install JetBrainsMono-NF), while JetBrains-Mono (scoop install JetBrains-Mono) has no such thing. Can you guys reproduce this?

For me, none of the fonts (installed by scoop into %LOCALAPPDATA%\Microsoft\Windows\Fonts) survive a reboot, including JetBrains-Mono.

[Dabombber]

There's nothing wrong with the font installation, it's an issue with the Windows font cache. You can use the following command to get them working again.

 Restart-Service -Name FontCache

[hfziu]

Seems like Windows has a feature that can block untrusted fonts from loading outside of the %windir%/Fonts directory. However, the last time I checked, this feature was Not configured on my system.

https://learn.microsoft.com/en-us/windows/security/threat-protection/block-untrusted-fonts-in-enterprise

[DavidZhang73]

TL;DR sudo scoop install -g <font> instead of scoop install <font>
I encountered this issue after upgraded to 22H2, Restart-Service -Name FontCache does not help, untrusted fonts was also not configured, but microsoft/terminal#14231 (comment) seems to be a workable solution.
BTW, following that comment, I found #161, which introduces installing font in user scope instead of system level. I suspect it conflicts with 22H2 upgrade. However, I have another desktop PC, which also upgraded to 22H2 recently, the font works fine.

[gitolicious]

Great hint, thanks a lot for that! Solved the problem for me.

[jonz94]

Hi there,

Sorry for being late...
and BIG THANKS to everyone here for providing so much useful information!

Base on DavidZhang73's comment and #180.
It seems that the best solution for now is using sudo scoop install -g <font> to install font for all users.

[hungpham3112]

According to this issue, it seems we need to install Nerd Fonts for all users instead of current user.

[felipecrp]

I think the problem is that the installer is trying to install the fonts in the user space. Installing to the system to all users, apparently, solve the problem.

More info available here -> microsoft/cascadia-code#137 (comment)

[felipecrp]

#200 will probably solve this issue.

[mkvlrn]

Alright, so it's definitely not an issue in this repo, but the discussion finally got to a solution. Thanks! Closing this.

[jonz94]

I think I may have found the root cause of the original issue.
It appears to caused by misconfigured permissions of the user font install folder (%LOCALAPPDATA%\Microsoft\Windows\Fonts), which is preventing the fonts from functioning properly.

Investigation

On a fresh installed Windows (Windows 10 1809 onward), if we install a font using the normal way:

• Double-click the font file, and then press the Install button on the font viewer app.
• Or, right-click the font file, and then select Install (not Install for all users) on the menu.

Windows will automatically create the user font install folder (%LOCALAPPDATA%\Microsoft\Windows\Fonts) for us.
And the important part is that Windows will give it the proper permission settings,
which included permissions for ALL APPLICATION PACKAGES and ALL RESTRICTED APPLICATION PACKAGES.

Screenshot of the correct permission settings:

On the other hand, if we manually create this folder using File Explorer,
or in the case of the PowerShell script introduced in #161, using New-Item PowerShell command:

scoop-nerd-fonts/bucket/FiraCode-NF-Mono.json

Lines 42 to 45 in 58f791f

	"$fontInstallDir = if ($global) { \"$env:windir\\Fonts\" } else { \"$env:LOCALAPPDATA\\Microsoft\\Windows\\Fonts\" }",
	"$registryRoot = if ($global) { \"HKLM\" } else { \"HKCU\" }",
	"$registryKey = \"${registryRoot}:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Fonts\"",
	"New-Item $fontInstallDir -ItemType Directory -ErrorAction SilentlyContinue | Out-Null",

The folder will not have the same permission settings as the user font install folder created by Windows.
In particular, the permissions for ALL APPLICATION PACKAGES and ALL RESTRICTED APPLICATION PACKAGES will be missing.

Screenshot of the wrong permission settings:

The mysterious part is that if the user font install folder has the misconfigured permissions problem:

• On Windows 10 1809 to Windows 11 22H1, everything works just fine.
• But on Windows 11 22H2 onward, it makes all the fonts installed in this folder malfunction and cannot be accessed by any Windows apps.

Solution

To address this issue, we just need to make sure the user font install folder has the correct permission settings.

There are a few ways to do this:

1. Use Set-Acl PowerShell command to add back the missing permissions

$userFontInstallFolder = "${env:LOCALAPPDATA}\Microsoft\Windows\Fonts"

$accessControlList = Get-Acl $userFontInstallFolder

# ALL APPLICATION PACKAGES
$allApplicationPackagesAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule([System.Security.Principal.SecurityIdentifier]::new("S-1-15-2-1"), "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow")

# ALL RESTRICTED APPLICATION PACKAGES
$allRestrictedApplicationPackagesAccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule([System.Security.Principal.SecurityIdentifier]::new("S-1-15-2-2"), "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow")

$accessControlList.SetAccessRule($allApplicationPackagesAccessRule)
$accessControlList.SetAccessRule($allRestrictedApplicationPackagesAccessRule)

Set-Acl -AclObject $accessControlList $userFontInstallFolder

Q: What does "S-1-15-2-1" and "S-1-15-2-2" mean?

A: These are the security identifiers for ALL APPLICATION PACKAGES and ALL RESTRICTED APPLICATION PACKAGES respectively.

References I used to write this script:

• https://stackoverflow.com/a/70129197
  • The first google search result I checked
• https://devblogs.microsoft.com/oldnewthing/20220502-00/?p=106550
  • Figure out what the hell is "S-1-15-2-1" and "S-1-15-2-2"
• https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
  • Ensure that "S-1-15-2-1" and "S-1-15-2-2" is a real thing
• https://petri.com/how-to-use-powershell-to-manage-folder-permissions/
  • Attempt to compose a working script for solving this issue
  • Learn that we can use (Get-Acl $folder).Access | Format-Table command to get the permission settings of a given folder
• https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.filesystemaccessrule.-ctor#system-security-accesscontrol-filesystemaccessrule-ctor(system-security-principal-identityreference-system-security-accesscontrol-filesystemrights-system-security-accesscontrol-inheritanceflags-system-security-accesscontrol-propagationflags-system-security-accesscontrol-accesscontroltype)
  • The API usage for System.Security.AccessControl.FileSystemAccessRule helped me to understand the meaning of each parameter:
    • The 2nd parameter is "File System Rights", which is map to Access in the screenshot.
    • The 3rd is "Inheritance Flags", which is map to Applies to.
    • The 4th is "Propagation Flags", which is map to Inherited from.
    • The 5th is "Access Control Type", which is map to Type.

2. Remove the existing user font install folder and let Windows create a new one

1. Go to the user font install folder (%LOCALAPPDATA%\Microsoft\Windows\Fonts).
2. Copy all of the fonts inside the user font install folder to another location (e.g. Desktop) for later use (for step 5).
3. Open Registry Editor, go to Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Fonts, and then delete all of the font entries except for the first (Default) entry.
4. Delete the entire user font install folder.
5. Select all of the fonts that you copied in step 2, right-click, and click Install.
6. Done!

---

I will probably send a PR using the first solution (maybe this weekend), so users who have used this Scoop bucket to install fonts before can retrive the fix by updating/reinstalling the font using Scoop.

[iquiw]

@jonz94 Awesome!!
The first solution fixed the problem for me!

just a typo.

- $accessControlList = Get-Acl $userFontInstallDir
+ $accessControlList = Get-Acl $userFontInstallFolder