How Windows 98 Handled Corrupted Font Files

During startup, Microsoft Windows 98 processed installed fonts through its Graphical Device Interface (GDI) and an internal font cache file named ttfCache. How the operating system handled a corrupted font depended largely on whether the damaged file was a critical core system font or a non-essential third-party typeface. While standard corruptions typically triggered silent fallbacks via font substitution or produced font-cache read errors, critical system font corruption frequently halted the boot process entirely or produced severe interface rendering glitches.

Core System Fonts and Critical Boot Failures

Windows 98 depended on a handful of essential system fonts to initialize the graphical user interface. Key files included vgasys.fon, vgafix.fon, and the TrueType font marlett.ttf.

  • Bitmap System Fonts (.fon): Files like vgasys.fon supplied the basic text for menus, dialog boxes, and system alerts. If these were missing or corrupted, GDI failed to initialize. The boot process would abruptly halt, dropping the user into a 16-bit text-mode error screen indicating that GDI or Windows could not load, preventing access to the desktop.
  • Control Glyph Fonts (marlett.ttf): Marlett contained the symbols used for window control buttons, such as minimize, maximize, close, scrollbar arrows, and check boxes. If marlett.ttf was corrupted at startup, Windows 98 would not fail to boot, but the interface became severely garbled. Instead of icons, control buttons rendered random alphanumeric characters (such as numbers or lowercase letters).

The Font Cache (ttfCache) and Startup Freezes

To speed up boot times and font enumeration, Windows 98 compiled an index of installed TrueType fonts into a hidden binary cache file located in the C:\Windows directory called ttfCache.

During boot, Windows read this cache rather than scanning every individual font file in the Fonts folder. If a font file became corrupted on disk, the cached index would often become desynchronized or corrupted as well. When GDI parsed a corrupted ttfCache file during startup:

  • The system would frequently freeze on the Windows 98 splash screen.
  • The system would encounter a General Protection Fault (GPF) in GDI.EXE or GDI32.DLL before the desktop shell loaded.

Because Windows 98 lacked an automated self-healing mechanism for font files, the standard resolution required booting into MS-DOS mode or Safe Mode to manually delete ttfCache. Windows would then rebuild the cache on the next reboot by scanning the directory again.

Font Enumeration and Dynamic Substitution

For non-critical TrueType fonts (.ttf), Windows 98 attempted to read the font headers when building the active font table. If a file header was unreadable or contained invalid checksums, GDI would skip the font during enumeration.

If an application or system component requested a font that failed to load due to corruption, Windows 98 employed its font-matching and substitution engine:

  1. GDI checked the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\FontSubstitutes.
  2. It searched for defined alternative typefaces (such as mapping missing or corrupt typefaces to Arial or MS Sans Serif).
  3. If no explicit substitute existed, GDI dynamically selected the closest available font matching the requested font's height, weight, and character set.

Unhandled Parser Exceptions

If a corrupted TrueType file contained valid header structures but corrupt internal data tables (such as broken glyph outlines or corrupted hinting bytecode), Windows 98's font parser could not always isolate the fault. When GDI loaded the file into memory, it often triggered an unhandled exception, causing a Blue Screen of Death (BSOD) or a system-wide freeze that required a hard reboot.