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


43

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.
  • Clave de prueba
  • Cuando recupero el registro, esa clave y sus valores se han ido:
  • Test Key Gone
  • (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!


2
"El cambio de registro no aparece después del reinicio". - El cambio en el registro no entrará en vigencia hasta el reinicio y, por lo general, solo se debe reiniciar el Explorador de archivos. Todo depende de qué comportamiento se pretende que haga el cambio de registro si realmente se requiere un reinicio. La clave real se modifica, cuando se modifica, lo que responde a su pregunta.
Ramhound

8
¿Qué quieres decir con un cierre duro? ¿Sosteniendo el botón de encendido hasta que se apaga? Ese proceso evita escribir cualquier escritura de caché de disco pendiente.
DavidPostill

2
@Ramhound Entiendo que no entra en vigor, pero ¿por qué no se ha escrito en el disco? Hago la edición, apago y luego el cambio ya no existe. Ya sea que haya entrado en vigor en la memoria o no, no importa en ese momento
Shrout1

2
@ Shrout1: ¿por qué obliga a la máquina a apagarse en lugar de apagarla de manera segura?
Ramhound

66
@Ramhound Estoy realizando pruebas para ver qué sucede si el sistema no se apaga correctamente. Aleatorio, lo sé, pero necesito saber exactamente cómo se compromete esto con la memoria para que no perdamos nada en nuestros sistemas si no se maneja correctamente.
Shrout1

Respuestas:


54

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.


¡Gracias! Agradezco su respuesta :) Apagué la hibernación, reinicié y volví a ejecutar la misma prueba. El ejemplo 1 tiene el mismo resultado, no hay ningún archivo de hibernación involucrado. Parece que los cambios en el registro solo se escriben en algún momento durante el cierre de sesión / apagado ... También estoy de acuerdo en que el sistema podría estar buscando un "último buen" estado al despertar de una hibernación rota: tiende a ejecutar verificaciones de integridad.
Shrout1

1
Hmmm ... así que descargué "sync" de sysinternals que fuerza el caché de escritura al disco y eso no hizo nada (aún perdí las claves / valores en el apagado). También ejecuté el explorador de procesos y miré la E / S de disco en las propiedades de Regedit. Había leído E / S pero no había E / S de escritura. Esto me hace pensar que podría estar esperando el cierre ... ¿Conoces alguna documentación de M $ extremadamente seca que pueda explicar esto claramente? ¡¡Gracias, de nuevo, por toda su ayuda!!
Shrout1

11
El diario NTFS no garantiza los datos del archivo. Es simplemente para mantener los metadatos NTFS consistentes, para que no termines con un sistema de archivos roto . Los archivos individuales aún pueden tener cambios parciales grabados en ellos, rompiendo el archivo. Existe Transactional NTFS, pero eso no se recomienda y se usa muy raramente. Esta es también la razón por la cual los motores de bases de datos mantienen su propio diario para la consistencia de los datos. Ver también blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673
Bob

2
@ Shrout1 Eso supone que los cambios en el registro están pendientes en la memoria caché de reescritura. Es completamente posible que en su lugar se gestionen por separado y que esto no tenga nada que ver con el sistema de archivos, el almacenamiento en caché o de otra manera. Por ejemplo, la última configuración válida conocida solo se actualiza al iniciar con éxito. (No sé lo suficiente sobre las partes internas del registro para estar seguro de cuándo se guardan los cambios. Y luego TxR podría estar involucrado)
Bob

1
¿Hay alguna razón por la que estás forzando el apagado? AFAIK que solo obliga a cerrar las aplicaciones en ejecución, lo que no hace mucho más que eliminar aplicaciones que de otro modo no puede cerrar y hace que sea más probable que pierda algunos cambios no guardados en algún lugar si no sabe lo que está haciendo. haciendo o que pondrías alguna aplicación en un estado irrecuperable, realmente no lo llamaría un cierre "correcto".
NotThatGuy

39

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.


¡Oye! Le daré este si agrega un enlace al siguiente artículo de MSDN: Guardar cambios en el registro de la aplicación en Windows 8 o Windows Server 2012 y agregar una breve cita en bloque. Su respuesta me llevó por el agujero del conejo a ese artículo y básicamente dice lo mismo que usted hizo. ¡Muchas gracias!
Shrout1

¿Pero alguien sabe cómo un usuario puede llamar a RegFlushKey ?
Scott

@Scott Parece que debe hacerse en código ... El artículo de MSDN que figura en la publicación tiene un ejemplo de C ++ y lo he visto implementado en C # en otro lugar. No estoy seguro de que se pueda hacer desde la línea de comandos.
Shrout1

3
@ Scott: Me sorprendería si sync lo hizo al ras del registro en el disco. Simplemente no tendría ningún sentido. ¿Por qué debería enjuagar la memoria caché del sistema de archivos (que es utilizada por el administrador de configuración, no al revés) de repente enjuagar la propia memoria caché del administrador de configuración? Ni siquiera sabe cuál es la estructura de la memoria caché de nivel superior, si es que existe alguna.
Mehrdad

1
@ Scott Hay un camino. La API ya ha sido vinculada. Existen herramientas que le ofrecen una GUI para llamar a funciones arbitrarias de Win32. La cosa es ... Es un detalle de implementación. Si lo expones, la gente confía en él y luego no puedes cambiarlo. También vale la pena señalar que el disco del sistema es una bestia totalmente diferente a los medios extraíbles. El disco del sistema se usa para muchas cosas que requieren que un identificador esté siempre abierto (por ejemplo, un archivo de página). Windows no admite el desmontaje de la partición del sistema, por lo que no necesita esta "característica". Además ... intenta mantener los comentarios neutrales. Odias a Windows, lo entendemos.
Básico

14

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.


Oh buena captura! Ese es mi nuevo MSDN-ism favorito: el momento justo . Mi favorito anterior era "Tenga cuidado al especificar la cláusula TOP en una consulta que contenga un operador UNION, UNION ALL, EXCEPT o INTERSECT. Es posible escribir una consulta que devuelva resultados inesperados ", lo que fue un eufemismo para "esta característica es mal roto y no hace lo que cualquier persona razonable esperaría y en lugar de arreglarlo vamos a documentarlo ".
davidbak

@davidbak: lol, bueno en defensa de MSDN, realmente no veo qué más detalles podrían proporcionar que un usuario debería confiar.
Mehrdad

Oh tienes razon; claramente, esto fue solo algo documentado como consecuencia del acuerdo de la UE de hace mucho tiempo, donde Microsoft debía documentar todas las API, sin importar cuán internas sean. Esta página que vinculó incluso dice "Solo los componentes a nivel de kernel pueden usar este código de control del sistema de archivos", lo cual es un buen consejo para mantener las manos libres. Aún así, " el momento justo " - un día me va a documentar algunas API mío con "llamar a este método sólo en el momento justo " y ver qué pasa ....
davidbak

@davidbak: Creo que estás un poco ... emocionado. :-P Supongo que esto se documentó para que los controladores del sistema de archivos sepan qué archivo contiene la sección del registro SYSTEM, lo que puede ser importante ya que no intentarían escribir nada en el registro al mismo tiempo que ese archivo se está volcando al disco. Sin embargo, no tengo pruebas de esto; Es solo una razón por la que me parece concebible. Sin embargo, una duda que tengo al respecto es por qué un controlador de disco no necesitaría saber esto también.
Mehrdad
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.