I've made this issue in a Help discussion thread, so I'm linking this with the ticket:
https://sourceforge.net/p/keepass/discussion/329221/thread/523249ecd4/
In short:
Hi, I'm on KeePass 2.37 and I've already experienced this issue so many times. The config file often just randomly resets, mostly after OS (Windows 10) crashes due to any issue. After a PC crashes (or even worse, when it crashes during startup), the app just behaves as if no config were present, overwriting the previous config in AppData by an empty one. This is completely non-deterministic, so I can't provide repro steps. It may even be an issue that occurs while the app is closing down and doesn't manage to do so gracefully. KeePass supposedly writes a new config file whenever you close it, so it may be caused e.g. by terminating the process that's in the shutdown sequence. Please make sure this can never happen, thanks.
My idea about the fix is that maybe the AppConfigSerializer.Save() could make a backup file first before overriding the original, and the process of loading, which seems to be AppConfigSerializer.Load() under Program.CommonInit(), could first make sure that the original isn't corrupt (or just check for the existence of a backup)? I'm not sure how atomic those actions are, so someone should make sure that a naive approach like "replacing original by a backup" cannot corrupt a working copy by restoring a broken copy (I've experienced something like this even in Google Chrome, as it mercilessly destroyed my session in spite of having a .bak file, but that's to be expected from a company that uses us as beta testers).
This is not a bug in KeePass, as has been explained in your original thread.
cheers, Paul
Since version 2.39, KeePass uses a very reliable approach for writing configuration files (writing to a temporary file first and then replacing the actual file using an NTFS file transaction).
As you are still using the older KeePass version 2.37, my suggestion would simply be to update to the latest version (which currently is 2.43).
Thanks and best regards,
Dominik