Terminal suddenly can't find the font Cascadia Mono

[johan-byggtjanst]

Windows Terminal version (or Windows build number)

10.0.19043.1288

Other Software

No response

Steps to reproduce

Just starting the Terminal on Windows 10. Not running as admin.

Expected Behavior

A new terminal window

Actual Behavior

Got this error

`Unable to find the selected font "Cascadia Mono".

"Consolas" has been selected instead.

Please either install the missing font or choose another one.`

[ChameleonDevil]

I added a comment on Cascadia Code font repo for a solution on the font installation, for Windows Terminal and VS Code:

https://github.com/microsoft/cascadia-code/issues/594#issuecomment-954565361

Please check there, I have discovered "Cascadia Mono" to be missing (can't even get it reinstalled currently), but show there how to update Windows Terminal and VS Code to use "Cascadia Mono PL"

[Peru-S]

Same issue: Windows Terminal automatically closed due to Windows Update (no restarts). Opening Terminal again resulted in "Could not find Cascadia Code" issue that OP raised.

On 21H1 19043.1288

(The other problem is that Terminal arbitrarily closes even if Windows Update is configured to restart at a later date: All other apps function properly)

[zadjii-msft]

this is the thread

We've tracked this in other threads in the past, and we've done work to mitigate this before, but we didn't get all of it. Every time we push an update, more folks start running into this again. We've got an idea of what's wrong here - one of the code paths does the right thing for the SxS font lookup, and the other path doesn't, and that leads to this warning.

In the past, we used #9375 to track this. #9734 attempted to mitigate. #10305 tracked the version of this that caused a crash on startup.

So this was the first thread for the issue during this update, congrats.

IF YOU'RE HITTING THIS

Try "Repairing" the Terminal app, by going to "Settings > Apps > {whatever Terminal Install you have} > Advanced Options > Repair". This shouldn't delete your settings. (But "Reset" will, so be careful!)

---

_{If you comment some variation of "me too" in this thread, ~you will be removed from the selfhost program~ your comment will be minimized as spam, thanks.}

[Peru-S]

I worked around by installing Cascadia manually. (Hopefully this message isn't marked as spam :) I searched for this issue before (opening a new one ) / commenting here btw. So if possible please sticky this. Also I wasn't sure if it was a Terminal issue or a Cascadia issue, so juggling between those two github repos as well. This could avoid unintentional 'spam' comments.

[barkermn01]

I would also like to confirm this issue is now present in the Windows 11 Version after a windows update but I'm not sure if that is related or not I did not have this issue until a couple of days ago after a windows update, I'm currently running Terminal version 1.11.2921.0, I'm on the Insider program on the Beta Channel, so whatever this issue is it's now coming through to Windows 11 versions...

Windows 11 is currently on: Edition Windows 11 Pro Version 21H2 Installed on ‎27/‎08/‎2021 OS build 22000.258 Experience Windows Feature Experience Pack 1000.22000.258.0

I do have a Windows Update pending will update this message if this update resolves the problem for me...

[zadjii-msft]

In general: We don't really need to know anything more about OS version and Terminal version for this one. We've got a good idea of what's causing this.

The Windows 11 data point is a little interesting, we thought that the underlying bug in the OS for migrating the font files from one version to the next was fixed, but alas, it seems it also regressed since when it was first fixed in Windows 11. So this will continue to plague users at random till we fix this.

[miniksa]

11032's mitigation will likely mitigate this too.

[DHowett]

This is still an issue and will continue to be an issue until we nail nearby font loading.

Notes from discussion:

But the heart of the issue is that our system collection contains a pointer to a font that is locked for deletion, because the app platform locked it for deletion since it's part of our package We needed to do fallback when we failed to actually load the font, to a collection that doesn't have the issue

[ghost]

:tada:This issue was addressed in #11764, which has now been successfully released as Windows Terminal Preview v1.12.3472.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

:tada:This issue was addressed in #11764, which has now been successfully released as Windows Terminal v1.11.3471.0.:tada:

Handy links:

• Release Notes
• Store Download

[srdjanjovcic]

This is not fixed on Windows 10 in 1.13.10983.0

[lhecker]

Reopening because I found a flaw in my implementation. In case people wonder how we're failing so hard at fixing this: It's partially my inability in figuring this out, but also partially because we're simply unable to repro this issue. All fixes are purely theoretic. Even my new fix is just made on an assumption (a pretty good one this time if I may say so). I'm really sorry about this! ☹️

[tylerszabo]

I'm not sure if it helps but the issue seems to be system-wide when it happens. This causes crashes in gVim when attempting to load "Cascadia Code" after Windows Terminal has updated on my Windows 11 box. I worked around using @Mindfulplays' suggestion to install manually.

I suspect the issue is less with loading the font incorrectly and something to do with installing the font incorrectly. I tend to be using the font somewhere at all times so perhaps there's some kind of issue with replacing it when it's being used in some way.

[lhecker]

@tylerszabo Yes, we know that the actual underlying issue certainly isn't our fault. I'm not sure what the current state of an fix for that is (I can faintly remember hearing it's fixed in a newer Windows 11 build?), but in the meantime we'd of course want to fix it ourselves as quickly as possible.

[ilor]

Happened for me again on 1.13.10983.0 on Windows 10 21H2, making for roughly the fourth time in a year I had this. Some additional data points:

• I've rebooted a few hours ago to install Windows updates
• This didn't break right on startup. In fact I have two shell tabs open where the font is okay, and only now (a few hours later) opening a new tab of the same type complains about the Cascadia Mono being MIA.

[ghost]

:tada:This issue was addressed in #12904, which has now been successfully released as Windows Terminal v1.13.1143.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

:tada:This issue was addressed in #12904, which has now been successfully released as Windows Terminal Preview v1.14.143.:tada:

Handy links:

• Release Notes
• Store Download

[AlpineWeezl]

Unfortunately, this issue still exists with completely updated system. I also did the reset as mentioned in the second post of this thread.

[ghost]

@lhecker You wrote:

because we're simply unable to repro this issue

Perhaps the steps below will help reproduce the issue. (Although @zadjii-msft mentioned you don't really need to know anything more about OS version, I should say I use Windows 11 ARM in a Parallels virtual machine on an M1 Mac).

STEP 1: Download and unzip Cascadia Mono PL:

# Download the archive file
$downloadsPath = "$Env:USERPROFILE\Downloads"
$zipFileName = "CascadiaCode-2111.01.zip"
$zipFilePath = "$downloadsPath\$zipFileName"
$url = "https://github.com/microsoft/cascadia-code/releases/download/v2111.01/$zipFileName"
Invoke-WebRequest -Uri $url -OutFile $zipFilePath

# Expand, then delete, the archive file
$expandedDirectoryPath = "$downloadsPath\CascadiaCode-2111.01"
Expand-Archive -Path $zipFilePath -Destination $expandedDirectoryPath
Remove-Item -Force -Path $zipFilePath

STEP 2: Copy and register the font such that it causes the issue in Windows Terminal:

# Ensure destination directory exists
$fontsDirectoryPath = "$Env:LOCALAPPDATA\Microsoft\Windows\Fonts"
if (-not (Test-Path $fontsDirectoryPath))
{
    $directory = New-Item -Force -ItemType Directory -Path $fontsDirectoryPath
}

# Copy font file
$fontFileName = "CascadiaMonoPL.ttf"
$fontFileSourcePath = "$Env:USERPROFILE\Downloads\CascadiaCode-2111.01\ttf\$fontFileName"
$fontFileDestinationPath = "$fontsDirectoryPath\$fontFileName"
Copy-Item -Path $fontFileSourcePath -Destination $fontFileDestinationPath

# Ensure the registry key exists
$fontsKey = "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Fonts"
if (-not (Test-Path -Path $fontsKey))
{
    $key = New-Item -Force -ItemType Directory -Path $fontsKey
}

# Add the registry key for the font file
$value = New-ItemProperty -Force -Name "Cascadia Mono PL Regular (TrueType)" -Path $fontsKey -PropertyType $type -Value $fontFileDestinationPath

STEP 3: Verify that Windows Terminal is not able to find the font.

STEP 4: Properly install the font such that it does not cause the issue in Windows Terminal:

(The Windows Shell should ask if you want to replace the 'Cascadia Mono PL Regular' font when you run the script below. You should answer Yes.)

# Create the Windows Shell's automation object and use the fonts namespace
$shell = New-Object -ComObject "Shell.Application"
$fonts = $shell.Namespace(0x14)

# Copy font file
$fontFileName = "CascadiaMonoPL.ttf"
$fontFileSourcePath = "$Env:USERPROFILE\Downloads\CascadiaCode-2111.01\ttf\$fontFileName"
$fonts.CopyHere($fontFileSourcePath, 20)

STEP 5: Verify that Windows Terminal is able to find the font.

STEP 6: Restart Windows.

STEP 7: Verify that Windows Terminal is again not able to find the font.

Hope this helps!

[cmschlenke]

If any poor soul has found their way here wondering why Windows Terminal can't find their font, let me assure you that this is actually not a Windows Terminal bug, or even a Windows bug. This behavior is caused by not having the font installed for all users. Follow these steps to remedy the problem... https://answers.microsoft.com/en-us/windows/forum/all/solution-installed-fonts-disappearing-after/146f4039-47c3-4017-a9b1-76f72badce39

[psxlover]

I just run into this issue. Version 1.18.2822.0. Windows 10. According to the Microsoft Store Terminal was updated today.

The previous comment does not apply in my case, there is no Fonts folder in %appdata%..\Local\Microsoft\Windows.

What's even more confusing is that in "Fonts" they are "there" but are invisible until I hove over them with the mouse in which case only the names appear:

[DHowett]

This was an issue on Windows 10 that Terminal had worked around. We recently (accidentally) broke our workaround. Stay tuned. :smile:

[psxlover]

Glad to hear it is a known issue and not just something wrong with my PC.

[barkermn01]

@DHowett i believe there is a specific term for that it's called a Regression :D

[stevenwong]

If anyone needs a temporary fix, uninstalling then reinstalling the Terminal app solved it for me. Neither repair or reset worked.

[IMB11]

I fixed this issue by making sure that the font being used was installed for all users instead of locally just for my user.