¿Cuándo escribe Windows los cambios de registro en el disco?

TL; DR:

Me di cuenta de que si hago un cambio en el registro y luego apago mi sistema Windows 10, el cambio en el registro no aparece después del reinicio.

También he notado que la eliminación de un archivo de hibernación puede afectar la capacidad de una herramienta de recuperación de Linux para realizar cambios en el registro de Windows en un estado fuera de línea. La herramienta parece incapaz de realizar cambios persistentes después de la eliminación de un archivo de hibernación. Voy a enumerar ejemplos específicos a continuación.

Ejemplo 1:

• Agrego una clave llamada "1111" en "HKLM \ SOFTWARE". Luego apago mi caja presionando el botón de encendido durante 5 segundos.
• 
• Cuando recupero el registro, esa clave y sus valores se han ido:
• 
• (Estas imágenes fueron editadas con fines de formateo)

Ejemplo 2 :

• Realizar un cambio en el registro (usando regedit)
• Hibernar el sistema
• Arrancar en una herramienta de recuperación de Linux
• Elimine el archivo de hibernación para montar el disco.
• Lea el registro de Windows (de la herramienta de recuperación)
• El cambio de registro se ha ido.

Esto parece equivalente a un apagado completo de la caja.

Ejemplo 3

Veo un comportamiento extraño cuando yo:

• Hibernar la caja
• Inicie desde una herramienta de recuperación de Linux y elimine el archivo de hibernación
• Realizar cambios en el registro (desde la herramienta de recuperación)
• Reinicia la caja

Esos cambios tampoco se reflejan en el registro.

Entonces, ¿qué está pasando aquí?

• ¿Cuándo escribe Windows 10 los cambios de registro en el disco?
• ¿Por qué la eliminación de un archivo de hibernación (en el Ejemplo 3) evita que los cambios de registro realizados desde la herramienta de recuperación se reflejen en el próximo arranque?

¡Esperando obtener alguna aclaración!

TL; DR: apague su sistema correctamente.

La hibernación no tiene nada que ver con el apagado, está estrechamente relacionado con la suspensión a RAM (suspensión), excepto con el contenido de RAM empujado al disco para que se pueda volver a leer y reanudar el funcionamiento exactamente desde el punto en que se detuvo el sistema .

Si desea que los cambios persistan, debe deshabilitar la hibernación y Windows Fastboot (que es un subconjunto de hibernación). O bien, puede reiniciar en lugar de hibernar y reiniciar.

La razón por la que los cambios no persisten es porque todavía no están escritos en el disco, excepto en el archivo de hibernación. Lo que está eliminando, lo que significa que el sistema de archivos puede tener que repararse a sí mismo y volver al estado de "último bien conocido".

Mientras el sistema esté en hibernación, habrá varias estructuras clave del sistema de archivos que pueden no haberse escrito en el disco y, en cambio, están en la RAM. El sistema, al reanudarse de la hibernación, esperará que el disco esté en un estado muy particular y es posible que las memorias caché de disco y los archivos importantes del sistema se guarden en el archivo de hibernación en lugar de en el disco real.

Si realiza un apagado correcto , Windows vaciará correctamente la memoria de trabajo al disco y luego desmontará el disco limpiamente antes de apagarlo.

Para forzar un apagado correcto, abra un símbolo del sistema y escriba

shutdown /s /f /t 0

/ses "apagado", /fforzar y /t 0significar "ahora" (tiempo = 0 segundos)

O simplemente puede deshabilitar fastboot e hibernación.

Lea más en HowtoGeek: Apagar no cierra completamente Windows 10 (pero reiniciar sí)

El problema es que Windows no garantiza que escriba ningún cambio en el disco el mismo milisegundo (o incluso un minuto) en el que realiza el cambio. Es casi seguro que se escribirá dentro de unos minutos, pero la probabilidad de que se haya escrito realmente aumentará con el tiempo. Es poco probable que se escriba de inmediato, luego, cerca del momento en que realice el cambio, la probabilidad aumentará bruscamente, y casi seguramente se habrá escrito en una hora.

Sin embargo, la cuestión es que al forzar un apagado forzado no le está dando al sistema la oportunidad de escribir cambios en el disco de manera segura.

La mayoría de los sistemas de archivos modernos están escritos para hacer cambios de la manera más segura posible. En el pasado se les ha denominado "atómicos", ya que en el cambio se produjo o no.

Hoy en día los conocemos como los sistemas de archivos articulado , ya que mantener un registro de las operaciones que va a suceder que puede revertirse o enrollada hacia delante en caso de fallo del sistema y reiniciar el sistema tampoco. Al iniciarse desde una falla de energía, el sistema verifica el diario y, para cada transacción, verifica si los datos del archivo real están escritos en el disco y son "buenos". Si es así, la transición avanza y se completa, de lo contrario, vuelve a los datos anteriores.

Al usar este orden, el disco está casi siempre en un estado fácil de reparar.

Pero al obligar a su sistema a apagarse inesperadamente, no puede garantizar si la transacción ha progresado lo suficiente como para avanzar después de la reparación, y es probable que un sistema operativo como Linux no se preocupe tanto como Windows por el historial de transacciones y es más probable que no solo hacer cambios que hacen que todo retroceda en lugar de avanzar.

Si reinicia en Windows, podría intentar o reparar el disco correctamente, ya que tiene un conocimiento más íntimo del sistema de archivos.

Como se documenta en la página de MSDN paraRegFlushKey :

Llamar a RegFlushKey es una operación costosa que afecta significativamente el rendimiento de todo el sistema, ya que consume ancho de banda del disco y bloquea las modificaciones a todas las claves por parte de todos los procesos en la sección de registro que se va a vaciar hasta que se complete la operación de vaciado. RegFlushKey solo debe llamarse explícitamente cuando una aplicación debe garantizar que los cambios en el registro persistan en el disco inmediatamente después de la modificación. Todas las modificaciones realizadas en las claves son visibles para otros procesos sin la necesidad de vaciarlas en el disco.

Alternativamente, el registro tiene un mecanismo de 'vaciado lento' que descarga las modificaciones del registro en el disco a intervalos regulares de tiempo. Además de esta operación regular de vaciado, los cambios del registro también son vaciados al disco al apagar el sistema. Permitir que la 'descarga lenta' elimine los cambios del registro es la forma más eficiente de administrar las escrituras del registro en el almacén del registro en el disco.

Esto sugiere que, además de enjuagar una clave específica en el disco de inmediato (que bloquea a todos los demás fuera del registro hasta que se complete el vaciado), el registro se vacía automáticamente periódicamente: no se otorga un tiempo, pero presumiblemente es al menos más que el tiempo que esperó entre escribir la clave y el apagado forzado. Además, se sonroja en el apagado, como ya lo había descubierto.

Puede usar la RegFlushKeyfunción en el software que manipula dicha clave, o crear una herramienta adicional para forzar la escritura de una clave de registro en el disco de inmediato, si esto es crucial para su caso de uso.

TL; DR: Es muy cuidadoso hacer esto en el momento correcto .

La documentación sobre FSCTL_MARK_AS_SYSTEM_HIVEtiene esto que decir:

El FSCTL_MARK_AS_SYSTEM_HIVEcódigo de control informa al sistema de archivos que el archivo especificado contiene la sección del sistema del registro. El sistema de archivos debe vaciar los datos de la sección del sistema al disco en el momento justo para evitar puntos muertos y garantizar la integridad de los datos.

No creo que haya más detalles disponibles públicamente que esto.

Tenga en cuenta que el vaciado del sistema de archivos no implica el vaciado del registro , ya que el registro puede realizar el almacenamiento en caché en la parte superior del sistema de archivos. Para limpiar primero el registro, debe de alguna manera causar NtFlushKeyo ZwFlushKeyser llamado a su clave de interés.