Crashbug if the font defined in config cannot be found

[grue74]

I noticed that the 6502bench crashes if there is no selected font present in the system when I try to open a project.

I have 6502bench files on a cloud synced directory and I use the same install with my desktop and laptop.

[fadden]

I tried editing the "cdlv-font-family" value in the SourceGen-settings file, changing it to the non-existent "Consolas1", and it just started up with a non-mono font. Can you provide more details about the circumstances?

Also, there should be a "CrashLog.txt" file created in the top directory (same place as the settings file) that should have a stack trace.

[grue74]

CrashLog.txt

I found this crashlog on my project dir, I hope it helps

[fadden]

Unfortunately, the stack trace just shows that none of the application code is involved... everything after SourceGen.App.Main() is internal to WPF.

A Google search for MS.Internal.Text.TextInterface.FontList (the method that actually crashed) produced an AI summary that said:

---

The MS.Internal.Text.TextInterface.FontList FileNotFoundException is a common error in WPF and .NET applications (like Telerik or DevExpress). It occurs when the application’s text rendering engine tries to load a required system or embedded font (e.g., Segoe UI, Arial) but cannot find the physical .ttf or .otf file on disk.

Most Common Causes & Solutions

1. Corrupted Windows Font Cache: The system font cache may be out of sync or corrupted.
   • Fix: Open the Services app (services.msc), find Windows Font Cache Service, stop it, and restart it. You can also manually delete .dat files in C:\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache.
2. Missing or Unsupported Font Files: The specific font requested in your application's XAML/code doesn't exist on the machine or the file path is incorrect.
   • Fix: Ensure the target font is properly installed in C:\Windows\Fonts. If you are using custom fonts, verify they are TrueType and embedded correctly in your project.
3. "Block Untrusted Fonts" GPO: Enterprise Group Policies might be blocking standard fonts from loading.
   • Fix: Check your Windows settings to ensure the Block untrusted fonts feature is disabled via Group Policy or Registry.
4. Architecture Mismatch (x86 vs x64): Running as "Any CPU" might cause issues if the app loads a 32-bit vs 64-bit unmanaged DLL dependency.
   • Fix: Change the build target in Visual Studio to x86 or x64 explicitly instead of Any CPU.

---

I'm not sure how far to trust the AI-generated summary. It would be nice if WPF would actually report the name of the file it was trying to open.

[grue74]

Ok, The font was C64 Pro Mono and for some reason I had it listed twice on the windows front browser, I removed the another one and this seemed to solve the problem.
Maybe I do have corruption on my font cache, need to rebuild it just in case.

[fadden]

Excellent, hopefully that resolves it.

It'd be nice to get a better diagnostic on-screen when this happens. I think the real fix is to move away from WPF, but that's a longer road.