Skip to main content

AYON 1.5.2 Tray Applications break fonts In Windows 10

Bugs

Hi,

Issue:

We work with freelance artists on a mix of Windows 10, and Windows 11 boxes.

We updated to AYON 1.5.2, however running the Tray Applications (such as the AYON Launcher, the Tray Publisher, etc.), on Windows 10 Breaks the Windows system fonts. This affects the File Explorer, Task Manager, Windows File Dialogs etc.

To reproduce:

  1. Run Ayon 1.5.2

  2. From the Windows Tray, select e.g. the Launcher:

  4. Select any Project from the Launcher,

  5. The Launcher displays the content Navigation panels, however, non of the text appears in the Launcher display (see image below):

  7. All of the other Windows Applications are now affected with the same issue. In the file explorer all of the file names have disappeared:

  8. In the File Save Dialogs, a similar thing happens with the text input fields, file names and the save and cancel buttons:

  10. To fix the issue the user has to log out and log back in, or restart windows.

In case this is useful, I also had a small dialogue with Claude Code, which narrowed down the issue to this (I hope it isn’t an hallucination!):

That's a very specific symptom — system apps like Explorer and Task Manager point to something happening at the Windows shell / GDI level, not just inside AYON's own process.

Most likely cause: Qt broadcasting WM_FONTCHANGE to HWND_BROADCAST

When PySide2 (which AYON uses) initialises QApplication, it builds Qt's font database by calling EnumFontFamiliesEx across all system fonts. After that, it broadcasts WM_FONTCHANGE to every top-level window on the desktop — including explorer.exe.

Explorer receives the message, clears its internal font cache and tries to reload. If Qt still holds GDI font handles at that moment (during its own font scan), Explorer's reload partially fails and it falls back to a broken/missing font state. Task Manager and other shell-hosted windows are affected for the same reason.

The fonts aren't actually deleted — they're just unloaded from Explorer's process. Restarting Explorer fixes it immediately:


Stop-Process -Name explorer -Force; Start-Process explorer
Longer-term options:

Switch AYON to PySide6 if it supports it — Qt 6 handles this more cleanly on Windows 10
Report it to AYON — this is a known class of bug in Qt/PySide2 pipelines on Windows and they may have a workaround (delaying the font broadcast, or suppressing it)

I can paste the full transcript in the comments below if that’s useful.

Although Support for Windows 10 is due to end this year (in October, I beleive), it feels like this shouldn’t have necessarily broken just yet.

Thanks for looking into this. Let me know if I can provide any more information.

Posted by theo@thetwingroup.com
3 comments

Log in to comment and vote

Comments3

  • theo@thetwingroup.com

    Hi @Dev Team ,

    Thank you for the speedy response and for the advice.

    I can confirm we have updated Ayon-core and I just restarted after the update, quickly tested the Ayon launcher, and this issue does indeed appear to be solved.

    Many thanks for the advice, much appreciated.

    I think you can close this ticket now and get it off your backlog.

  • Dev Team

    Team

    Hello, as far as I know this was fixed with ayon-core 1.8.3 . I would highly recommend to update AYON launcher and ayon-core to latest releases. Also Windows 10 life ended last year so I would recommend to update sooner than later.

  • theo@thetwingroup.com

    Full Claude Code Transcript:

    Theo: Why would a python tool make the fonts disappear on windows 10?

    Claude Code:

    This is a known Windows issue with a few common causes:

Most likely: WM_FONTCHANGE broadcast
Some Python libraries (notably matplotlib during font cache rebuild) call SendMessage(HWND_BROADCAST, WM_FONTCHANGE) to tell Windows the font list changed. This forces every running application to reload its font list — apps that are mid-render or in a bad state can drop fonts from their UI until restarted.

GDI font registration/deregistration via ctypes
A tool using AddFontResourceEx / RemoveFontResourceEx (e.g. to load a custom font temporarily) can inadvertently deregister fonts system-wide if it calls RemoveFontResource on the wrong path or broadcasts the change message carelessly.

Font cache corruption
Tools that enumerate all system fonts (PIL/Pillow, matplotlib, reportlab) can corrupt C:\Windows\System32\FNTCACHE.DAT if they crash mid-scan or run concurrently with another font operation. Windows then silently drops fonts it can't re-resolve from the cache.

Registry writes to the Fonts key
Anything writing to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts (even to add an entry) can cause the font subsystem to briefly reload, and a crash or incomplete write leaves the registry in a bad state.

Quick fixes:

Restart the affected app (most common fix — fonts come back on reload)
Rebuild the font cache: stop fontdrvhost.exe, delete FNTCACHE.DAT, reboot
If matplotlib is the culprit, deleting ~/.matplotlib/fontlist-*.json and letting it rebuild cleanly usually stops it happening again

Do you know which Python tool is triggering it?

    Theo: C:\Users\theof\AppData\Local\Ynput\AYON\shim\ayon.exe. Apologies; it might not be a python tool, although there is a python3.dll file in that folder alongside the executable


    Claude Code:

    AYON is a strong suspect. The shim bootstraps the full AYON Python environment and its Qt UI (PySide2/PySide6), which gives several likely culprits:

Most probable: Qt font database init
When AYON starts, QApplication initialises Qt's font database by enumerating all system fonts via GDI. On Windows 10, PySide2 in particular is known to broadcast WM_FONTCHANGE during this process, causing other open apps to reload their font lists and sometimes drop fonts in the process.

AYON/OpenPype custom font loading
AYON registers its own UI fonts (it ships icon/brand fonts). If it calls AddFontResourceEx and then broadcasts WM_FONTCHANGE, that refresh can cause poorly-behaved apps to lose their font state.

The shim's DLL injection
The shim injects into host DCCs (Maya, Nuke, Houdini etc.) to load the AYON plugin. DLL injection triggers a full DLL initialisation pass in the host process, and any font-related initialisation in the injected DLLs can fire WM_FONTCHANGE inside the host, which the host then propagates.

To narrow it down:

Does it happen when AYON launches standalone, or only when it connects to a DCC?
Does it affect the DCC itself, or other apps on the desktop?
If it's the DCC losing fonts after AYON connects, the injection path is likely the cause and it's worth raising it on the AYON GitHub — it's a known class of problem with pipeline launchers on Windows.


    Theo: it happens when AYON launches standalone, and it breaks the fonts in the windows applications, such as the file explorer and the task manager.

    Claude Code:

    That's a very specific symptom — system apps like Explorer and Task Manager point to something happening at the Windows shell / GDI level, not just inside AYON's own process.

Most likely cause: Qt broadcasting WM_FONTCHANGE to HWND_BROADCAST

When PySide2 (which AYON uses) initialises QApplication, it builds Qt's font database by calling EnumFontFamiliesEx across all system fonts. After that, it broadcasts WM_FONTCHANGE to every top-level window on the desktop — including explorer.exe.

Explorer receives the message, clears its internal font cache and tries to reload. If Qt still holds GDI font handles at that moment (during its own font scan), Explorer's reload partially fails and it falls back to a broken/missing font state. Task Manager and other shell-hosted windows are affected for the same reason.

The fonts aren't actually deleted — they're just unloaded from Explorer's process. Restarting Explorer fixes it immediately:


Stop-Process -Name explorer -Force; Start-Process explorer
Longer-term options:

Switch AYON to PySide6 if it supports it — Qt 6 handles this more cleanly on Windows 10
Report it to AYON — this is a known class of bug in Qt/PySide2 pipelines on Windows and they may have a workaround (delaying the font broadcast, or suppressing it)
Check if there's an AYON setting to run in a "tray only" / headless mode that avoids initialising a full QApplication until needed
The AYON GitHub issue tracker at ynput/ayon-core is the right place to report it with this diagnosis.