Oh I've definitely encountered "memory thrashing" before (starting around >90% RAM usage), but when it happens it is typically
far worse than what I'm seeing here with CB.
As for ordinary day-to-day usage, I know this bug cast a rather bad first impression of the editor, but I'm also noticing various little mundane details that don't sit as well with me. Like the top-level split between .c and .h files in the project panel.
I'm willing to help stay and debug for a bit, but I'd probably need instruction on building CB from its source first because as long as I'm the only one it's actively happening to, I'm also the only one that can truly
dive into it to research what is going wrong where.
I can find no code that saves the files ok and then closes them.
If I have two files open & modified, the "save changes?" prompt is a good breakpoint where I should be able to fetch the call stack and find exactly WHERE it is trying to close the editor window.
In the meantime, viewing Task Manager there is a "normal" CPU spike while saving a file (in 1 of 4 CPU cores) but it is very localized to CB itself (not affecting other processes / system at large). I additionally sometimes see the little "leaf" icon next to its status, indicating that (as a UWP process) the system has occasionally suspended it (by force?) -- see attachment.