As documented on the MSDN page for RegFlushKey
:
Calling RegFlushKey is an expensive operation that significantly affects system-wide performance as it consumes disk bandwidth and blocks modifications to all keys by all processes in the registry hive that is being flushed until the flush operation completes. RegFlushKey should only be called explicitly when an application must guarantee that registry changes are persisted to disk immediately after modification. All modifications made to keys are visible to other processes without the need to flush them to disk.
Alternatively, the registry has a 'lazy flush' mechanism that flushes registry modifications to disk at regular intervals of time. In addition to this regular flush operation, registry changes are also flushed to disk at system shutdown. Allowing the 'lazy flush' to flush registry changes is the most efficient way to manage registry writes to the registry store on disk.
This suggests that apart from flushing a specific key to disk immediately (which locks everyone else out of the registry until the flush is complete), the registry is automatically flushed periodically: a time is not given, but presumably it is at least more than the time you waited between writing the key and hard shutdown. In addition, it is flushed at shutdown, as you had already figured out.
You can use the RegFlushKey
function in the software that manipulates said key, or create an additional tool with it to force writing a registry key to disk immediately, if this is crucial to your usage case.
The now defunct "Saving application registry changes on Windows 8 or Windows Server 2012" Microsoft support article (archive.org linked here) states the following:
To maximize performance, updates to the registry in Windows 8 and Windows Server 2012 are not immediately flushed to disk. Instead, the registry flushes modified registry data to the disk at regular intervals of time. In addition, modified registry data is saved to disk when the system shuts down. In most cases, these mechanisms are sufficient to ensure that registry modifications safely reach the disk.
Because registry changes are not immediately flushed to disk, if a machine loses power immediately after an application modifies the registry, the application’s registry changes may not be saved. If this occurs, the application may observe the following effects when the system restarts:
- Registry changes made by the application may not be visible
- A newly installed driver may no longer appear to be installed, and will need to be reinstalled
- A newly uninstalled driver will still be installed, and need to be uninstalled again
An application or installer can request that its registry modifications be written to disk immediately using the RegFlushKey API. However, calling RegFlushKey is an expensive operation that significantly affects system-wide performance. Applications and installers should only call this API if they must guarantee that their registry modifications are immediately persisted to disk.
Also, an excerpt from Mokubai's response:
While the system is hibernated there are going to be several key filesystem structures that may not have been written out to disk and are instead in RAM. The system will, upon resuming from hibernation, expect the disk to be in a very particular state and it is possible that disk caches and important system files get saved to the hibernation file rather than to the actual disk...
The linked How To Geek article in that response was very informative:
Fast Startup mixes the traditional shutdown process with hibernation. With Fast Startup enabled, Windows 10 discards all your open programs and files (as it would during a traditional shutdown), but saves the state of the Windows kernel to disk (as it would during hibernation). The next time you boot your PC, Windows restores the kernel and starts up the rest of the system.
Between Fast Startup / Hybrid Shutdown and the delay in flushing the keys, most of the pieces come together. If the system managed to store the modification in memory but hadn't flushed to disk then it would get saved in the hibernation file on hybrid shutdown or just discarded on a hard shutdown. If the hibernation file is discarded by the recovery tool then the change will no longer exist either.
Best Answer
Very nice, I could finally solve the problem.
After researching for a while, I found out that the registry that I edited from the recovery command line was not the actual one used on the computer. I had to load the registry hive
HKEY_LOCAL_MACHINE\SOFTWARE
(with a different keyname, e.g.SOFTWARE2
) fromC:\Windows\System32\config\SOFTWARE
.Then, replacing the entire
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
key and theC:\Windows\Fonts
directory with working ones of a friend would do the job -- I could boot again and log in normally.I should really start to use Windows recovery points.