starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 07:54:35 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

DirectWrite warnings IDWriteFontFamily::GetFont … 0x88985004 in Windows Terminal Preview 1.24.3504.0; not present in 1.23.13503.0 #23939

New Issue
Closed
opened 2026-01-31 08:56:48 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 08:56:48 +00:00
Owner
Copy Link

Originally created by @sba923 on GitHub (Jan 5, 2026).

Windows Terminal version

1.24.3504.0

Windows build number

10.0.19045.6691.amd64fre.vb_release.191206-1406

Other Software

PowerShell 7.5.4
Graphviz 14.1.1

Steps to reproduce

Running dot.exe -Tpng with a .dot file using [fontname="Sans italic"] (or [fontname="Segoe UI Italic"]) produces warnings.

This was not the case before Windows Terminal.Preview v1.24.3504.0

This doesn't repro with Windows Terminal 1.23.13503.0.

Switching to software rendering makes the warnings disappear.

"experimental.rendering.forceSoftwareRendering": true

Expected Behavior

No warnings

Actual Behavior

** (process:55144): WARNING **: 12:09:32.543: IDWriteFontFamily::GetFont failed with error code 88985004

** (process:55144): WARNING **: 12:09:32.615: IDWriteFontFamily::GetFont failed with error code 88985004

** (process:111992): WARNING **: 12:09:36.362: IDWriteFontFamily::GetFont failed with error code 88985004

** (process:111992): WARNING **: 12:09:36.411: IDWriteFontFamily::GetFont failed with error code 88985004

Originally created by @sba923 on GitHub (Jan 5, 2026). ### Windows Terminal version 1.24.3504.0 ### Windows build number 10.0.19045.6691.amd64fre.vb_release.191206-1406 ### Other Software PowerShell 7.5.4 Graphviz 14.1.1 ### Steps to reproduce Running `dot.exe -Tpng` with a `.dot` file using `[fontname="Sans italic"]` (or `[fontname="Segoe UI Italic"]`) produces warnings. This was not the case before Windows Terminal.Preview v1.24.3504.0 This doesn't repro with Windows Terminal 1.23.13503.0. Switching to software rendering makes the warnings disappear. `"experimental.rendering.forceSoftwareRendering": true` ### Expected Behavior No warnings ### Actual Behavior ** (process:55144): WARNING **: 12:09:32.543: IDWriteFontFamily::GetFont failed with error code 88985004 ** (process:55144): WARNING **: 12:09:32.615: IDWriteFontFamily::GetFont failed with error code 88985004 ** (process:111992): WARNING **: 12:09:36.362: IDWriteFontFamily::GetFont failed with error code 88985004 ** (process:111992): WARNING **: 12:09:36.411: IDWriteFontFamily::GetFont failed with error code 88985004
claunia added the Needs-TriageIssue-BugNeeds-Attention labels 2026-01-31 08:56:49 +00:00
claunia commented 2026-01-31 08:56:50 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 5, 2026):

This is DWRITE_E_FILEACCESS which is

A font file exists but could not be opened due to access denied, sharing violation, or similar error.

First off:

  • Open C:\Windows\Fonts in Explorer
  • Search for and open "Segoe UI"
  • Open the "Segoe UI Italic" variant

Does it load properly? If not, your Windows installation is damaged. Your HDD/SSD is likely failing. Do the usual of chkdsk and sfc (you find instructions on the internet) and possibly even dism.

There's a chance that your Cascadia font is broken. In that case:

  • Make a backup of your settings.json (Ctrl+Shift+,) and anything else you may need
  • Uninstall all versions of Windows Terminal (Regular, Preview, Canary)
  • Open C:\Windows\Fonts in Explorer again, remove any fonts that start with "Cascadia"
  • Open regedit, go to HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Fonts and ensure that all WindowsTerminal keys are gone
  • Reboot (important!)
  • Reinstall Windows Terminal
@lhecker commented on GitHub (Jan 5, 2026): This is `DWRITE_E_FILEACCESS` which is > A font file exists but could not be opened due to access denied, sharing violation, or similar error. First off: * Open `C:\Windows\Fonts` in Explorer * Search for and open "Segoe UI" * Open the "Segoe UI Italic" variant Does it load properly? If not, your Windows installation is damaged. Your HDD/SSD is likely failing. Do the usual of `chkdsk` and `sfc` (you find instructions on the internet) and possibly even `dism`. There's a chance that your Cascadia font is broken. In that case: * Make a backup of your `settings.json` (Ctrl+Shift+,) and anything else you may need * Uninstall all versions of Windows Terminal (Regular, Preview, Canary) * Open `C:\Windows\Fonts` in Explorer again, remove any fonts that start with "Cascadia" * Open `regedit`, go to `HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Fonts` and ensure that all `WindowsTerminal` keys are gone * Reboot (important!) * Reinstall Windows Terminal
claunia commented 2026-01-31 08:56:50 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Jan 7, 2026):

Thanks for following up on this.

Yes, the Segoe UI Italic font was loading properly:

Image

I've cleaned up every trace from Windows Terminal, Cascadia (Code, Mono...), Caskaydia Cove... -- which required help from IT staff as this cannot be done from an elevated PowerShell prompt, rebooted and reinstalled Windows Terminal Preview.

It seems the problem's gone.

What's weird, though, is that the Cascadia font family doesn't show up in File Explorer's Fonts UI, but I can use Cascadia Code in Windows Terminal, VSCode, WinMerge, Ditto...

Next step will be to restore a font that has the glyphs oh-my-posh needs...

@sba923 commented on GitHub (Jan 7, 2026): Thanks for following up on this. Yes, the `Segoe UI Italic` font was loading properly: <img width="1131" height="627" alt="Image" src="https://github.com/user-attachments/assets/66fc2c94-94f0-4ab0-b43d-7d495e7f1c14" /> I've cleaned up every trace from Windows Terminal, Cascadia (Code, Mono...), Caskaydia Cove... -- which required help from IT staff as this cannot be done from an elevated PowerShell prompt, rebooted and reinstalled Windows Terminal Preview. It seems the problem's gone. What's weird, though, is that the Cascadia font family doesn't show up in File Explorer's Fonts UI, but I can use Cascadia Code in Windows Terminal, VSCode, WinMerge, Ditto... Next step will be to restore a font that has the glyphs `oh-my-posh` needs...
claunia commented 2026-01-31 08:56:50 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Jan 7, 2026):

Problem doesn't seem to have returned after installing the Nerd Fonts from https://github.com/microsoft/cascadia-code/releases/download/v2407.24/CascadiaCode-2407.24.zip and switching Windows Terminal Preview to using Cascadia Code NF.

Bottom line: shouldn't there be a documented procedure for diagnosing/repairing the font infrastructure for the latest DirectWrite-based render to function properly?

There must be a lot of folks out there who have followed the evolution of the various ways to get the necessary glyphs for oh-my-posh over time...

@sba923 commented on GitHub (Jan 7, 2026): Problem doesn't seem to have returned after installing the Nerd Fonts from https://github.com/microsoft/cascadia-code/releases/download/v2407.24/CascadiaCode-2407.24.zip and switching Windows Terminal Preview to using `Cascadia Code NF`. Bottom line: shouldn't there be a documented procedure for diagnosing/repairing the font infrastructure for the latest DirectWrite-based render to function properly? There must be a lot of folks out there who have followed the evolution of the various ways to get the necessary glyphs for `oh-my-posh` over time...
claunia commented 2026-01-31 08:56:50 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 7, 2026):

I'm really glad to hear that removing Cascadia fixed the issue.

It's not the first time that this fixed an issue like yours. We're using the official way to install fonts from a packaged application: baab0eae05/src/cascadia/CascadiaPackage/Package-Pre.appxmanifest (L242-L251)
That feature has been buggy since it was introduced. We've informed the maintainers about this multiple times. Side note: Installing user fonts (= %LOCALAPPDATA%\Microsoft\Windows\Fonts) is similarly buggy. If you or anyone else has any fonts in that folder, make sure to delete them and move them into C:\Windows\Fonts (aka: "Install for all users").

Bottom line: shouldn't there be a documented procedure for diagnosing/repairing the font infrastructure for the latest DirectWrite-based render to function properly?

Yes, but the only thing we can do is ask the font system maintainers. We've done that many times over the years and got... ghosted. It's just frustrating, so don't expect any improvements soon. 🙁

@lhecker commented on GitHub (Jan 7, 2026): I'm really glad to hear that removing Cascadia fixed the issue. It's not the first time that this fixed an issue like yours. We're using the official way to install fonts from a packaged application: https://github.com/microsoft/terminal/blob/baab0eae05d43cf3182ffd11baa7e046b8c33d06/src/cascadia/CascadiaPackage/Package-Pre.appxmanifest#L242-L251 That feature has been buggy since it was introduced. We've informed the maintainers about this multiple times. Side note: Installing user fonts (= `%LOCALAPPDATA%\Microsoft\Windows\Fonts`) is similarly buggy. If you or anyone else has any fonts in that folder, make sure to delete them and move them into `C:\Windows\Fonts` (aka: "Install for all users"). > Bottom line: shouldn't there be a documented procedure for diagnosing/repairing the font infrastructure for the latest DirectWrite-based render to function properly? Yes, but the only thing we can do is ask the font system maintainers. We've done that many times over the years and got... ghosted. It's just frustrating, so don't expect any improvements soon. 🙁
claunia commented 2026-01-31 08:56:50 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Jan 7, 2026):

[...]

That feature has been buggy since it was introduced. We've informed the maintainers about this multiple times. Side note: Installing user fonts (= %LOCALAPPDATA%\Microsoft\Windows\Fonts) is similarly buggy. If you or anyone else has any fonts in that folder, make sure to delete them and move them into C:\Windows\Fonts (aka: "Install for all users").

Bottom line: shouldn't there be a documented procedure for diagnosing/repairing the font infrastructure for the latest DirectWrite-based render to function properly?

Yes, but the only thing we can do is ask the font system maintainers. We've done that many times over the years and got... ghosted. It's just frustrating, so don't expect any improvements soon. 🙁

Thanks for the explanation.

You're referring to Windows bugs, not Windows Terminal bugs, right? If that's correct, how can we end users put pressure on this?

About using "install for all users": unfortunately that's not something that I can use on my work machines, due to IT restrictions: I can use elevated shells with my standard user account, but managing system-wide installed fonts cannot be done from there.

@sba923 commented on GitHub (Jan 7, 2026): [...] > > That feature has been buggy since it was introduced. We've informed the maintainers about this multiple times. Side note: Installing user fonts (= `%LOCALAPPDATA%\Microsoft\Windows\Fonts`) is similarly buggy. If you or anyone else has any fonts in that folder, make sure to delete them and move them into `C:\Windows\Fonts` (aka: "Install for all users"). > > Bottom line: shouldn't there be a documented procedure for diagnosing/repairing the font infrastructure for the latest DirectWrite-based render to function properly? > > Yes, but the only thing we can do is ask the font system maintainers. We've done that many times over the years and got... ghosted. It's just frustrating, so don't expect any improvements soon. 🙁 Thanks for the explanation. You're referring to Windows bugs, not Windows Terminal bugs, right? If that's correct, how can we _end users_ put pressure on this? About using "install for all users": unfortunately that's not something that I can use _on my work machines_, due to IT restrictions: I can use _elevated shells_ with my standard user account, but managing system-wide installed fonts _cannot_ be done from there.
claunia commented 2026-01-31 08:56:51 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Jan 7, 2026):

It's not the first time that this fixed an issue like yours.

I've shared a link to this issue at https://x.com/SBarizien/status/2008841857980346529 FWIW

@sba923 commented on GitHub (Jan 7, 2026): > It's not the first time that this fixed an issue like yours. I've shared a link to this issue at https://x.com/SBarizien/status/2008841857980346529 FWIW
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Needs-Attention Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23939
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?