Repository: microsoft/terminal (language: cpp)

Issue:
Terminal suddenly can't find the font Cascadia Mono
### 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.`


Discussion / hints:
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"**
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)
### 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!)

<hr>

<sub>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. </sub>
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.
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...
_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.
#11032's mitigation will likely mitigate this too.
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
: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](https://github.com/microsoft/terminal/releases/tag/v1.12.3472.0)
* [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
: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](https://github.com/microsoft/terminal/releases/tag/v1.11.3471.0)
* [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
This is not fixed on Windows 10 in 1.13.10983.0
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! ☹️

Fix patch:
diff --git a/src/renderer/base/FontCache.h b/src/renderer/base/FontCache.h
index e7a5c4134ca..163da0239d5 100644
--- a/src/renderer/base/FontCache.h
+++ b/src/renderer/base/FontCache.h
@@ -62,13 +62,16 @@ namespace Microsoft::Console::Render::FontCache
 
                 wil::com_ptr<IDWriteFontSetBuilder1> fontSetBuilder;
                 THROW_IF_FAILED(factory5->CreateFontSetBuilder(fontSetBuilder.addressof()));
-                THROW_IF_FAILED(fontSetBuilder->AddFontSet(systemFontSet.get()));
 
                 for (const auto& file : nearbyFontFiles)
                 {
                     LOG_IF_FAILED(fontSetBuilder->AddFontFile(file.get()));
                 }
 
+                // IDWriteFontSetBuilder ignores any families that have already been added.
+                // By adding the system font collection last, we ensure our nearby fonts take precedence.
+                THROW_IF_FAILED(fontSetBuilder->AddFontSet(systemFontSet.get()));
+
                 wil::com_ptr<IDWriteFontSet> fontSet;
                 THROW_IF_FAILED(fontSetBuilder->CreateFontSet(fontSet.addressof()));
 


Test patch: