When does Windows write registry changes to disk?

Question

TL;DR:

I've noticed that if I make a registry change and then hard-shutdown my Windows 10 system, the registry change does not appear after reboot.

I've also noticed that the deletion of a hibernation file can impact the ability for a Linux recovery tool to make changes to the Windows registry in an offline state. The tool seems unable to make persistent changes after the deletion of a hibernation file. I will list specific examples below.

Example 1:

• I add a key called "1111" into "HKLM\SOFTWARE". I then hard power down my box by holding the power button for 5 seconds.
• 
• When I pull the registry back up, that key and its values are gone:
• 
• (These images were edited for formatting purposes)

Example 2:

• Make a change in the registry (using regedit)
• Hibernate the system
• Boot into a Linux recovery tool
• Delete the hibernation file in order to mount the disk.
• Read the windows registry (from the recovery tool)
• The registry change is gone.

This seems equivalent to a hard shutdown on the box.

Example 3:

I see stranger behavior when I:

• Hibernate the box
• Boot to a Linux recovery tool and delete the hibernation file
• Make changes to the registry (from the recovery tool)
• Reboot the box

Those changes are not reflected in the registry either.

So what's going on here?

• When does Windows 10 write the registry changes to the disk?
• Why does the deletion of a hibernation file (in Example 3) prevent registry changes made from the recovery tool from being reflected on the next boot?

Hoping to get some clarification!

Answer 1

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.

Answer 2

TL;DR: Shut your system down properly.

---

Hibernation is nothing to do with shutting down, it is closely related to suspend-to-RAM (sleep) except with the contents of RAM pushed to disk in order for it to be read back in and operation resumed from exactly where the system left off.

If you want the changes to persist then you need to disable hibernation and Windows Fastboot (which is a subset of hibernation). Or you can actually reboot rather than hibernate and restart.

The reason changes are not persisted is because they are not written to disk yet except in the hibernation file. Which you are deleting, meaning that the filesystem may well have to repair itself and go back to a "last known good" state.

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.

If you do a proper shutdown then Windows will properly flush working memory to disk, and then unmount the disk cleanly before powering down.

To force a proper shutdown open a command prompt and type

shutdown /s /f /t 0

/s is "shutdown", /f to force, and /t 0 to mean "now" (time = 0 seconds)

Or you can just disable fastboot and hibernation.

Read more at HowtoGeek: Shutting Down Doesn’t Fully Shut Down Windows 10 (But Restarting Does)

---

Related to you doing a hard shutdown the problem there is that Windows is not guaranteed to write any changes out to disk the same millisecond (or even minute) that you make the change. It will almost certainly be written within a few minutes but the probablility of it having actually been written will increase over time. It's unlikely to be written immediately, then near to the time you make the change the probability increases sharply, and will almost certainly have been written within an hour.

The thing is though, that by forcing a hard shutdown you are not giving the system a chance to safely write changes to disk.

Most modern filesystems are written to make changes in the safest way possible. In the past they have been referred to as "atomic", as in the change has either happened or it has not.

Today we know them as Journalled file systems because they keep a log of operations that will happen that can be either reverted or rolled forwards in the event of system failure and reboot. Upon startup from a power failure the system checks the journal and for each transaction it checks if the actual file data is written to disk and is "good". If it is then the transation rolls forwards and is completed, if not then it rolls back to the old data.

By using this order the disk is almost always in an easy to repair state.

But by forcing your system to power down unexpectedly you cannot guarantee whether the transaction has progressed far enough to roll forwards upon repair, and chances are that an operating system such as Linux will not care as much as Windows about the transaction history and is more likely than not to just make changes that roll everything backwards rather than forwards.

If you rebooted into Windows it might try or be able to repair the disk properly as it has a more intimate knowledge of the filesystem.

Answer 3

TL;DR: It is very careful to do this at the right moment.

The documentation on FSCTL_MARK_AS_SYSTEM_HIVE has this to say:

The FSCTL_MARK_AS_SYSTEM_HIVE control code informs the file system that the specified file contains the registry's system hive. The file system must flush system hive data to disk at just the right moment to avoid deadlocks and to ensure data integrity.

I don't believe there is any more detail available publicly than this.

Bear in mind that flushing the file system does not imply flushing the registry, because the registry can perform caching on top of the file system. To flush the registry first, you need to somehow cause NtFlushKey or ZwFlushKey to be called on your key of interest.