[Bug] Crash on startup after changing CJK font settings

[yadokariinthemarsh]

Description

The application crashes during startup if the Japanese font or CJK font priority is changed from "Auto". This persists until the configuration files are manually deleted.

Environment

• OS: Windows 11 Japanese
• Ferrite version: v0.2.6
• Rust version: rustc 1.92.0 (ded5c06cf 2025-12-08)
• Installation method: MSI Installer

Steps to Reproduce

1. Launch Ferrite.
2. Set a Japanese font or change CJK font priority to any value other than Auto.
3. Close the application.
4. Attempt to relaunch the application.

Expected Behavior

The application should launch normally with the selected font/CJK settings.

Actual Behavior

The application window does not appear at all. The ferrite.exe process can be seen in the Task Manager for a split second before it terminates and generates a crash log in the Event Viewer.

Log Output

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" />
    <EventID>1000</EventID>
    <TimeCreated SystemTime="2026-01-29T10:58:50.2586746Z" />
    <Execution ProcessID="4068" ThreadID="11496" />
    <Channel>Application</Channel>
  </System>
  <EventData>
    <Data Name="AppName">ferrite.exe</Data>
    <Data Name="ExceptionCode">c0000409</Data>
    <Data Name="FaultingOffset">0000000000527cb5</Data>
    <Data Name="AppPath">C:\Program Files\Ferrite\ferrite.exe</Data>
  </EventData>
</Event>

Additional Context

Deleting the %AppData%\Roaming\ferrite directory fixes the issue temporarily by resetting the configuration.

Also, there is some Tofu appearing in the settings UI.

[OlaProeis]

Thanks for the detailed report, this is very helpful.

From investigating the startup path and the font system, this does appear to be a config-driven crash related to persisted font/CJK settings, not a general runtime instability.

A few key points that line up with what you’re seeing:

• Font selection and CJK priority are loaded and applied very early during startup, before the window or UI is shown.
• If an invalid or unsupported font configuration is persisted (e.g. a font name or CJK priority combination that cannot be reconstructed on next launch), the application can fail before it reaches any recoverable error handling.
• On Windows, this currently manifests as a c0000409 fast-fail instead of a Rust panic.
• Deleting %AppData%\Roaming\ferrite works because it resets the font settings back to a known-safe default (Auto CJK handling).

The tofu you’re seeing in the settings UI is likely related: it suggests that the active font stack is missing proper fallback glyph coverage, which further supports that the font family / fallback chain becomes invalid when CJK priority is forced.

So in short:

• ✅ Reproducible
• ✅ Config-related
• ✅ Not data-loss related
• ❌ Currently not resilient to invalid font settings

I’ll be looking at tightening validation and adding defensive fallbacks so that:

• Invalid font configs are ignored or reset safely
• A bad font choice can never prevent the app from launching

Thanks again for reporting this, especially with Event Viewer details and a clear repro path.

[OlaProeis]

I’ve investigated this and the crash is caused by an invalid persisted font configuration when a non-Auto CJK font preference is selected.

In short: if a specific CJK preference (e.g. Japanese) is saved, but the corresponding system font cannot be successfully loaded on startup, Ferrite ends up passing an inconsistent font setup to egui. This causes a hard crash during set_fonts() before the window is shown. Because the setting is persisted, the crash repeats until the config directory is deleted.

This also explains the tofu (□) seen in the settings UI, glyphs are missing because no suitable CJK fallback font is actually loaded.

This is a bug on our side: we need to defensively validate persisted font/CJK settings at startup and fall back to Auto when the requested fonts are unavailable, instead of crashing.

I’ll address this in an upcoming patch release. Thanks again for reporting it.

[OlaProeis]

@yadokariinthemarsh, v0.2.6.1 is out and this crash is fixed!

Fonts now return None gracefully when they can't be loaded, so a bad CJK preference will no longer take down the whole app on startup. The tofu in settings labels may still appear when no CJK document is open (since fonts load lazily now), but the crash itself is gone.

This is also the first code-signed release, so you shouldn't see any SmartScreen warnings either.

Please give it a try: https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.6.1

[yadokariinthemarsh]

The crash issue when changing CJK Regional Preference and fonts has been resolved. I can also confirm that the Japanese glyph selection is working as expected. Thank you for the fix!

However, there appears to be a different issue with the rendering of multi-byte characters.
Immediately after launching the editor, the display is corrupted as shown in the screenshot. If I switch to Split View or Rendered View, the characters display correctly in those views, but they become corrupted again when I switch back to the Raw Editor. In some cases, most characters are missing at launch, and then corrupted characters gradually appear.
These corrupted sections include not only multi-byte characters but also ASCII characters.

The display in the Raw Editor returns to normal when I type any character or change the font settings.
This phenomenon occurs only within approximately the first 30 lines of a file. In the attached screenshot, everything from line 34 onwards displays normally, while in another file, it was normal from line 35. (Please ignore the content of my notes! 😅)

This bug occurs in both .md and .txt files. It seems to be triggered by the presence of multi-byte characters, as files containing only ASCII characters do not exhibit this problem.

I really appreciate your efforts to support CJK users.🙇