Environment: FontBase 2026.7.0, Windows 10 Pro 22H2 (19045.7725), i7-14700K, 128 GB RAM, library root F:_FontBase\FontBase (42 files), ~2,250 activated fonts in %LOCALAPPDATA%\Microsoft\Windows\Fonts\FontBase.
Symptom: One FontBase.exe --type=renderer process (the main window, minimized the whole time) consumed 42,000+ CPU-seconds in ~15 hours, i.e. ~75% of one core continuously. No fonts were added or changed during that period. CPU use starts right after launch and never drops.
Evidence (non-invasive debugger attach, cdb !runaway): a single thread accounts for almost all of it: 2 h 59 m user time + 7 h 08 m kernel time. Three stack samples of that thread, seconds apart, all show the same loop:
ntdll!NtCreateFile
KERNELBASE!CreateFileW
FontBase!uv_fs_scandir <- libuv fs.readdir / fs.readdirSync
FontBase!uv_loop_fork+0x103e0 <- (libuv internals, no symbols)
v8 JIT frames ...
FontBase!v8::Function::Call
So JavaScript in the renderer is calling fs.readdir (via libuv uv_fs_scandir) in an effectively unbounded loop. The ratio of kernel to user time (7:3) says the time goes into directory enumeration syscalls, not into font parsing. This looks like the folder-change polling that staff have described on the forum, but with no delay between polls, or a watcher that re-triggers itself.
Expected: an idle, minimized FontBase should use ~0% CPU. Folder changes can be detected with fs.watch / ReadDirectoryChangesW instead of polling, or with a polling interval of seconds, not continuous.
Workaround on my side: quitting FontBase when not in use.
Happy to provide a full CPU profile or process dump on request.