After a Windows Update and the usual reboot, Visual Studio 2026 greeted me with a red bar on top of the editor:

The editor can’t access the font Cascadia Code. Right now, we’re using a default system font. Restarting your operating system might help fix the issue.

I wanted to have a look at the font in the Windows Settings (ms-settings:fonts), but the panel crashed as soon as I opened Cascadia Code. So I downloaded the latest release of Cascadia Code and reinstalled it for all users. No change.

The font files were fine

I asked Claude Code to diagnose the issue on my Windows 10 machine. The fonts in C:\Windows\Fonts were valid and readable. And yet, the failure could be reproduced without Visual Studio, with three lines of PowerShell:

1Add-Type -AssemblyName PresentationCore
2$family = [Windows.Media.Fonts]::SystemFontFamilies | Where-Object Source -eq 'Cascadia Code'
3@($family.GetTypefaces()).Count

1An error occurred while enumerating through a collection: Attempted to perform an unauthorized operation.

Cascadia Code and Cascadia Mono failed, whereas Cascadia Code PL and Cascadia Code NF did not. Querying DirectWrite showed that some fonts of the family returned DWRITE_E_FILEACCESS (0x88985004) and, more surprisingly, that the family was built from files belonging to several versions of Windows Terminal.

Windows Terminal brings its own Cascadia

Windows Terminal ships with its own copy of Cascadia Code and Cascadia Mono (but not the PL and NF variants). It shares them with the other applications by registering them in a subkey named after the package:

HKEY_CURRENT_USER
  \Software
    \Microsoft
      \Windows NT
        \CurrentVersion
          \Fonts
            \Microsoft.WindowsTerminal_1.24.11911.0_x64__8wekyb3d8bbwe
            \Microsoft.WindowsTerminal_1.24.12741.0_x64__8wekyb3d8bbwe
            ...

I had 17 of these subkeys, going back to version 1.8, and yet only version 1.24.12741 was installed.

The event log Microsoft-Windows-AppXDeploymentServer/Operational told the rest of the story:

• For days, the update of Windows Terminal from 1.24.11911 to 1.24.12741 had been failing with 0x80073D02, because Terminal was running.
• After the reboot, the update finally went through while I was logging in. By then, the fonts of the old package were already in use.
• The folder of the old package could not be moved away (0x80070005) and its four font files were left in a delete pending state: still listed in the folder, but impossible to open (STATUS_DELETE_PENDING, which Win32 reports as access denied).
• The registration of the old package was not removed, so DirectWrite kept listing files which nobody could open.

WPF throws when it runs into one of these files while enumerating the family, and Visual Studio falls back to a default font. The crash of the Settings panel happens in SettingsHandlers_Fonts.dll (access violation 0xc0000005); I did not analyze a dump, but I suspect it trips over the very same fonts.

Cleaning up

I exported the Fonts key as a backup, then removed every subkey which did not match the installed package (Get-AppxPackage Microsoft.WindowsTerminal tells you which one to keep):

1$fonts = 'HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Fonts'
2Remove-Item "$fonts\Microsoft.WindowsTerminal_1.24.11911.0_x64__8wekyb3d8bbwe" -Recurse

The four files in limbo disappeared, the PowerShell test above succeeded and Visual Studio was happy again after I restarted it – no need to reboot. The Settings panel stopped crashing too, which confirms my suspicion.

The clean-up also called RemoveFontResource on every font file of the removed packages and broadcast a WM_FONTCHANGE message. I don’t know if this was required.
Rebooting, as suggested by Visual Studio, might have been enough to get rid of the pending files. I did not try.

Sixteen stale registrations on a single machine tell me that this clean-up fails quite often when Windows Terminal gets updated. I would not be surprised to see the red bar again.