45 votes

Quand Windows écrit-il les modifications du registre sur le disque ?

TL;DR :

J'ai remarqué que si j'effectue une modification du registre et que j'arrête ensuite brutalement mon système Windows 10, la modification du registre n'apparaît pas après le redémarrage.

J'ai également remarqué que la suppression d'un fichier d'hibernation peut avoir un impact sur la capacité d'un outil de récupération Linux à apporter des modifications au registre Windows dans un état hors ligne. L'outil semble incapable d'effectuer des modifications persistantes après la suppression d'un fichier d'hibernation. Je vais énumérer des exemples spécifiques ci-dessous.

Exemple 1 :

  • J'ajoute une clé appelée "1111" dans "HKLM \SOFTWARE ". J'ai ensuite mis mon boîtier hors tension en maintenant le bouton d'alimentation pendant 5 secondes.
  • Test Key
  • Lorsque je remonte le registre, cette clé et ses valeurs ont disparu :
  • Test Key Gone
  • (Ces images ont été modifiées pour des raisons de formatage)

Exemple 2 :

  • Modifier le registre (à l'aide de regedit)
  • Mettre le système en veilleuse
  • Démarrer dans un outil de récupération Linux
  • Supprimez le fichier d'hibernation pour pouvoir monter le disque.
  • Lire le registre Windows (à partir de l'outil de récupération)
  • La modification du registre a disparu.

Cela semble équivalent à un arrêt brutal de la boîte.

Exemple 3 :

Je vois étranger comportement lorsque je :

  • Mise en veilleuse de la boîte
  • Démarrez avec un outil de récupération Linux et supprimez le fichier d'hibernation.
  • Modifier le registre (à partir de l'outil de récupération)
  • Redémarrer le boîtier

Ces modifications ne sont pas non plus reflétées dans le registre.

Que se passe-t-il donc ici ?

  • Quand Windows 10 écrit-il les modifications du registre sur le disque ?
  • Pourquoi la suppression d'un fichier d'hibernation (dans l'exemple 3) empêche-t-elle les modifications du registre effectuées à partir de l'outil de récupération d'être prises en compte lors du démarrage suivant ?

J'espère obtenir des éclaircissements !

55voto

Ana cleto Points 11

TL;DR : Arrêtez votre système correctement.


L'hibernation n'a rien à voir avec l'arrêt, elle est étroitement liée à la suspension en mémoire vive (sommeil), sauf que le contenu de la mémoire vive est transféré sur le disque afin d'être lu à nouveau et de reprendre le fonctionnement exactement là où le système s'est arrêté.

Si vous voulez que les changements persistent, vous devez désactiver l'hibernation. Windows Fastboot (qui est un sous-ensemble de l'hibernation). Vous pouvez également redémarrage plutôt que d'hiberner et de redémarrer.

La raison pour laquelle les modifications ne sont pas persistantes est qu'elles ne sont pas encore écrites sur le disque sauf dans le fichier d'hibernation. Que vous supprimez, ce qui signifie que le système de fichiers pourrait bien devoir se réparer et revenir à un état de "dernier état connu".

Lorsque le système est en hibernation, plusieurs structures clés du système de fichiers peuvent ne pas avoir été écrites sur le disque et se trouver dans la mémoire vive. Le système, lorsqu'il sort de l'hibernation, s'attend à ce que le disque soit dans un état très particulier et il est possible que les caches du disque et les fichiers système importants soient enregistrés dans le fichier d'hibernation plutôt que sur le disque proprement dit.

Si vous faites un arrêt correct Windows videra alors correctement la mémoire de travail sur le disque, puis démontera proprement le disque avant de s'éteindre.

Pour forcer un arrêt correct, ouvrez une invite de commande et tapez

shutdown /s /f /t 0

/s est "arrêt", /f à la force, et /t 0 pour signifier "maintenant" (temps = 0 seconde)

Vous pouvez également désactiver le fastboot et l'hibernation.

Pour en savoir plus HowtoGeek : La fermeture n'arrête pas complètement Windows 10 (mais le redémarrage le fait)


En ce qui concerne l'arrêt brutal, le problème est que Windows n'est pas assuré d'écrire les modifications sur le disque à la même milliseconde (ou même à la même minute) que celle où vous les avez effectuées. Il est presque certain que les modifications seront écrites dans un délai de quelques minutes mais la probabilité qu'il ait été écrit augmentera avec le temps. Il est donc peu probable qu'il soit écrit immédiatement près de au moment où vous effectuez le changement, la probabilité augmente fortement, et il est presque certain que le texte aura été écrit dans l'heure qui suit.

Cependant, en forçant un arrêt brutal, vous ne donnez pas au système la possibilité d'écrire les modifications sur le disque en toute sécurité.

La plupart des systèmes de fichiers modernes sont écrits pour apporter des modifications de la manière la plus sûre possible. Dans le passé, on les qualifiait d'"atomiques", c'est-à-dire que la modification avait eu lieu ou n'avait pas eu lieu.

Aujourd'hui, nous les connaissons sous le nom de Systèmes de fichiers journalisés parce qu'ils tiennent un registre des opérations qui volonté Les données relatives à l'état de santé de l'utilisateur et à l'état de santé de la personne peuvent être modifiées de manière à ce qu'elles puissent être annulées ou reportées en cas de défaillance du système et de redémarrage. Au démarrage, après une panne de courant, le système vérifie le journal et, pour chaque transaction, il vérifie si les données du fichier sont écrites sur le disque et si elles sont "bonnes". Si c'est le cas, la transaction avance et s'achève ; si ce n'est pas le cas, elle revient aux anciennes données.

En utilisant cet ordre, le disque est presque toujours dans un état facile à réparer.

Mais en forçant votre système à s'éteindre inopinément, vous ne pouvez pas garantir que la transaction est suffisamment avancée pour être reprise après réparation, et il y a de fortes chances qu'un système d'exploitation tel que Linux ne se préoccupe pas autant que Windows de l'historique des transactions et qu'il se contente d'apporter des modifications qui ramènent tout en arrière plutôt qu'en avant.

Si vous avez redémarré sous Windows, celui-ci pourrait essayer ou être en mesure de réparer le disque correctement, car il a une connaissance plus approfondie du système de fichiers.

40voto

user914877 Points 416

Comme l'indique le site la page MSDN pour RegFlushKey :

Appel RegFlushKey est une opération coûteuse qui affecte considérablement les performances du système, car elle consomme de la bande passante sur le disque et bloque les modifications apportées à toutes les clés par tous les processus dans le répertoire de stockage du registre en cours de vidage jusqu'à ce que l'opération de vidage soit terminée. RegFlushKey ne doit être appelé explicitement que lorsqu'une application doit garantir que les modifications du registre sont enregistrées sur le disque immédiatement après leur modification. Toutes les modifications apportées aux clés sont visibles par les autres processus sans qu'il soit nécessaire de les transférer sur le disque.

Par ailleurs, le registre dispose d'un mécanisme de "nettoyage paresseux" qui efface les modifications du registre sur le disque à intervalles réguliers. En plus de cette opération régulière, les modifications du registre sont également transférées sur le disque lors de l'arrêt du système. Permettre au "lazy flush" d'évacuer les modifications du registre est le moyen le plus efficace de gérer les écritures du registre dans le magasin du registre sur le disque.

Cela suggère qu'en dehors de la suppression d'une clé spécifique sur le disque immédiatement (qui bloque l'accès au registre à tous les autres utilisateurs jusqu'à ce que le nettoyage soit terminé), le registre est automatiquement nettoyé périodiquement : le délai n'est pas indiqué, mais on peut supposer qu'il est au moins plus long que le temps écoulé entre l'écriture de la clé et l'arrêt brutal de l'ordinateur. En outre, la base de registre est vidée à l'arrêt de l'ordinateur, comme vous l'avez déjà compris.

Vous pouvez utiliser le RegFlushKey dans le logiciel qui manipule cette clé, ou créer un outil supplémentaire pour forcer l'écriture immédiate d'une clé de registre sur le disque, si cela est crucial pour votre cas d'utilisation.

La défunte "Sauvegarder les modifications apportées au registre des applications sous Windows 8 ou Windows Server 2012" L'article d'assistance de Microsoft (archive.org lié ici) indique ce qui suit :

Pour optimiser les performances, les mises à jour du registre dans Windows 8 et Windows Server 2012 ne sont pas immédiatement transférées sur le disque. Au lieu de cela, le registre envoie les données modifiées sur le disque à intervalles réguliers. En outre, les données de registre modifiées sont enregistrées sur le disque lorsque le système s'éteint. Dans la plupart des cas, ces mécanismes sont suffisants pour garantir que les modifications du registre atteignent le disque en toute sécurité.

Les modifications du registre n'étant pas immédiatement transférées sur le disque, si une machine est mise hors tension immédiatement après qu'une application a modifié le registre, les modifications du registre de l'application risquent de ne pas être sauvegardées. Si cela se produit, l'application peut observer les effets suivants lorsque le système redémarre :

  • Les modifications apportées au registre par l'application peuvent ne pas être visibles
  • Un pilote nouvellement installé peut ne plus sembler être installé et devra être réinstallé.
  • Un pilote nouvellement désinstallé sera toujours installé et devra être désinstallé à nouveau.

Une application ou un programme d'installation peut demander que les modifications apportées au registre soient immédiatement écrites sur le disque à l'aide de l'API RegFlushKey. Toutefois, l'appel à RegFlushKey est une opération coûteuse qui affecte considérablement les performances du système. Les applications et les installateurs ne doivent faire appel à cette API que s'ils doivent garantir que leurs modifications de registre sont immédiatement enregistrées sur le disque.

Egalement, un extrait de Réponse de Mokubai :

Lorsque le système est en hibernation, plusieurs structures clés du système de fichiers peuvent ne pas avoir été écrites sur le disque et se trouver dans la mémoire vive. Le système, lorsqu'il sort de l'hibernation, s'attend à ce que le disque soit dans un état très particulier et il est possible que les caches du disque et les fichiers système importants soient sauvegardés dans le fichier d'hibernation plutôt que sur le disque réel...

Die article lié à How To Geek dans cette réponse était très instructive :

Fast Startup mélange le processus d'arrêt traditionnel avec l'hibernation. Lorsque le démarrage rapide est activé, Windows 10 supprime tous les programmes et fichiers ouverts (comme lors d'un arrêt traditionnel), mais enregistre l'état du noyau Windows sur le disque (comme lors d'une mise en veille prolongée). La prochaine fois que vous démarrez votre PC, Windows restaure le noyau et démarre le reste du système.

Entre le démarrage rapide / l'arrêt hybride et le délai de vidange des clés, la plupart des éléments sont réunis. Si le système a réussi à stocker la modification en mémoire mais ne l'a pas transférée sur le disque, elle sera sauvegardée dans le fichier d'hibernation lors de l'arrêt hybride ou simplement supprimée lors d'un arrêt brutal. Si le fichier d'hibernation est supprimé par l'outil de récupération, la modification n'existera plus non plus.

14voto

user541686 Points 22852

TL;DR : C'est très attention de le faire au bon moment .

La documentation sur FSCTL_MARK_AS_SYSTEM_HIVE a déclaré ce qui suit :

Die FSCTL_MARK_AS_SYSTEM_HIVE informe le système de fichiers que le fichier spécifié contient le répertoire de stockage du registre. Le système de fichiers doit effacer les données du répertoire de stockage du système sur le disque à au bon moment pour éviter les blocages et garantir l'intégrité des données.

Je ne pense pas qu'il y ait plus de détails disponibles publiquement que cela.

Il faut garder à l'esprit que le rinçage de la système de fichiers n'implique pas de vider le registre parce que le registre peut mettre en cache les données de l sommet du système de fichiers. Pour vider le registre en premier lieu, vous devez d'une manière ou d'une autre faire en sorte que NtFlushKey o ZwFlushKey pour être appelé sur votre clé d'intérêt.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X