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

TL; DR:

J'ai remarqué que si je modifie le registre, puis arrête brutalement mon système Windows 10, le changement de registre n'apparaît pas après le redémarrage.

J'ai également remarqué que la suppression d'un fichier d'hibernation pouvait avoir une incidence sur la capacité d'un outil de récupération Linux à apporter des modifications au registre Windows en mode hors connexion. L'outil semble incapable d'apporter 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 éteint mon ordinateur en maintenant le bouton d'alimentation enfoncé pendant 5 secondes.
Lorsque je relève le registre, cette clé et ses valeurs ont disparu:
(Ces images ont été éditées à des fins de formatage)

Exemple 2 :

Faire un changement dans le registre (en utilisant regedit)
Hibernate le système
Démarrez dans un outil de récupération Linux
Supprimez le fichier d'hibernation afin de monter le disque.
Lire le registre Windows (à partir de l'outil de récupération)
Le changement de registre est parti.

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

Exemple 3:

Je vois un comportement étranger quand je:

Hibernate la boîte
Démarrez avec un outil de récupération Linux et supprimez le fichier de mise en veille prolongée.
Apporter des modifications au registre (à partir de l'outil de récupération)
Redémarrer la boîte

Ces changements ne sont pas reflétés dans le registre non plus.

Alors qu'est-ce qui se passe 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 de registre apportées par l'outil de récupération d'être répercutées au prochain démarrage?

En espérant avoir des éclaircissements!

windows-10 windows-registry hibernate Shrout1
la source

"Le changement de registre n'apparaît pas après le redémarrage." - La modification du registre n'entre en vigueur qu'au redémarrage. Généralement, seul l'explorateur de fichiers doit être redémarré. Tout dépend du comportement que le changement de registre est censé avoir si un redémarrage est réellement requis. La clé réelle est modifiée, lorsqu'elle est modifiée, ce qui répond à votre question.

Ramhound

Qu'entendez-vous par un arrêt brutal? Maintenez le bouton d'alimentation enfoncé jusqu'à ce qu'il s'arrête? Ce processus contourne l'écriture des écritures en attente sur le cache disque.

DavidPostill

@Ramhound Je comprends que cela n'entre pas en vigueur, mais pourquoi n'a-t-il pas été écrit sur le disque? Je fais le montage, la puissance dure et puis le changement n'est plus là. Qu'il soit entré en vigueur ou non dans la mémoire importe peu à ce stade

Shrout1

@ Shrout1 - Pourquoi obligez-vous la machine à s'éteindre au lieu de l'arrêter en toute sécurité?

Ramhound

@Ramhound J'effectue des tests pour voir ce qui se passe si le système ne se ferme pas normalement. Au hasard, je sais, mais j'ai besoin de savoir exactement comment cela est mémorisé pour que nous ne perdions rien sur nos systèmes s'il n'est pas géré correctement.

Shrout1

Réponses:

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 de la RAM, à l’exception du contenu de la RAM inséré sur le disque afin que celui-ci puisse être lu et que l’opération reprenne exactement à l'endroit où le système s'est arrêté. .

Si vous souhaitez que les modifications persistent, vous devez désactiver la mise en veille prolongée et Windows Fastboot (qui est un sous-ensemble de la mise en veille prolongée). Ou vous pouvez réellement redémarrer plutôt que d'hiberner et redémarrer.

Les modifications ne sont pas conservées car elles ne sont pas encore écrites sur le disque, sauf dans le fichier de veille prolongée. Ce que vous êtes en train de supprimer, ce qui signifie que le système de fichiers devra peut-être se réparer lui-même et revenir à un état "dernier bon connu".

Pendant l'hibernation du système, il y aura plusieurs structures de système de fichiers clés qui n'ont peut-être pas été écrites sur le disque mais qui sont plutôt en RAM. À la sortie de veille prolongée, le système s’attend à ce que le disque soit dans un état très particulier et il est possible que les caches de disque et les fichiers système importants soient enregistrés dans le fichier de veille prolongée plutôt que sur le disque lui-même.

Si vous effectuez un arrêt approprié, Windows videra correctement la mémoire de travail sur le disque, puis démontera le disque proprement avant de le mettre hors tension.

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

shutdown /s /f /t 0

/sest "shutdown", /fforcer et /t 0signifier "maintenant" (temps = 0 secondes)

Ou vous pouvez simplement désactiver le démarrage rapide et l'hibernation.

En savoir plus sur HowtoGeek: La fermeture ne ferme pas complètement Windows 10 (mais le redémarrage le fait)

En ce qui concerne l’arrêt brutal, le problème est qu’il n’est pas garanti que Windows écrit toutes les modifications sur le disque de la même milliseconde (ou même la minute) à laquelle vous les avez apportées. Il sera presque certainement écrit dans quelques minutes, mais la probabilité que ce texte ait été écrit augmentera avec le temps. Il est peu probable que l’on écrive immédiatement, puis près du moment où vous apportez le changement, la probabilité augmente brusquement et aura presque certainement été écrite en une heure.

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

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é, ils ont été qualifiés d '"atomiques", car le changement a eu lieu ou ne s'est pas produit.

Aujourd'hui , nous les connaissons comme des systèmes de fichiers journalisé parce qu'ils tiennent un registre des opérations qui se produira qui peut être soit Reconvertit ou roulées vers l' avant en cas de défaillance du système et le redémarrage. Au démarrage, après une panne de courant, le système vérifie le journal et vérifie, pour chaque transaction, si les données du fichier sont écrites sur le disque et sont "correctes". Si c'est le cas, la transition est ensuite poursuivie et terminée. Sinon, elle revient aux anciennes données.

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

Mais en forçant votre système à s’éteindre de manière inattendue, vous ne pouvez pas garantir que la transaction a progressé suffisamment loin pour être réparée. Il est donc probable qu’un système d’exploitation tel que Linux ne se soucie pas autant que Windows de l’historique des transactions et qu’il est plus probable. que de ne pas simplement faire des changements qui renvoient tout en arrière plutôt qu'en avant.

Si vous redémarrez Windows, il est possible que le disque soit réparé correctement car il possède une connaissance plus intime du système de fichiers.

Mokubai
la source

Merci! J'apprécie votre réponse :) J'ai désactivé l'hibernation, redémarré et relancé le même test. L'exemple 1 a le même résultat, aucun fichier d'hibernation n'est impliqué. Il semble que les modifications du registre ne soient écrites qu'à un moment donné au cours de la fermeture / fermeture de l'ordinateur ... Je conviens également que le système recherche peut-être un "dernier état" lors de la sortie d'une veille prolongée - il a tendance à exécuter des contrôles d'intégrité.

Shrout1

Hmmm ... J'ai donc téléchargé sysinternals "sync" qui force le cache en écriture sur le disque et qui ne fait rien (perd toujours les clés / valeurs à l'arrêt complet). J'ai également exécuté l'explorateur de processus et examiné les E / S de disque dans les propriétés de Regedit. Il avait lu I / O mais pas d'écriture I / O. Cela me fait penser qu'il est peut- être en attente d'arrêt… Connaissez-vous une documentation extrêmement déformée de M $ qui pourrait expliquer cela clairement? Merci encore pour votre aide!!

Shrout1

Le journal NTFS ne donne aucune garantie sur les données de fichier. Il s'agit simplement de maintenir la cohérence des métadonnées NTFS afin d'éviter un système de fichiers défectueux . Les fichiers individuels peuvent toujours avoir des modifications partielles enregistrées sur eux, cassant le fichier. Il existe un NTFS transactionnel, mais ce n'est pas recommandé et très rarement utilisé. C'est également pourquoi les moteurs de base de données tiennent leur propre journal pour la cohérence des données. Voir aussi blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

Bob

@ Shrout1 Cela suppose que les modifications du registre sont en attente dans le cache de réécriture. Il est tout à fait possible qu'ils soient gérés séparément et que cela n'ait rien à voir avec le système de fichiers, la mise en cache ou autre. Par exemple, Dernière bonne configuration connue est mise à jour uniquement après un démarrage réussi. (Je ne connais pas suffisamment les éléments internes du registre pour être certain que les modifications sont enregistrées. TxR pourrait alors être impliqué.)

Bob

Y a-t-il une raison pour laquelle vous forcez l'arrêt? Pour autant que je sache, cela ne force que les applications en cours d’exécution à fermer, ce qui ne fait pas autre chose que tuer les applications que vous ne pouvez pas fermer autrement et rend plus probable la perte de modifications non sauvegardées quelque part si vous ne savez pas ce que vous êtes. faire ou que vous mettriez une application dans un état irrécupérable - je n’appellerais pas vraiment cela un arrêt «approprié».

NotThatGuy

Comme indiqué sur la page MSDN pourRegFlushKey :

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

Sinon, le registre dispose d'un mécanisme de «vidage paresseux» qui supprime les modifications du registre sur le disque à intervalles réguliers. En plus de cette opération de vidage régulier, les modifications du registre sont également vidées sur le disque lors de l'arrêt du système. Le moyen le plus efficace de gérer les écritures de registre dans le magasin de registres sur disque est de permettre au «flush paresseux» de vider les modifications du registre.

Cela suggère qu'en dehors du vidage immédiat d' une clé spécifique sur le disque (ce qui verrouille tout le monde hors du registre jusqu'à ce que le vidage soit terminé), le registre est automatiquement vidé périodiquement: un délai n'est pas donné, mais il est vraisemblablement au moins supérieur à la le temps que vous avez attendu entre l’écriture de la clé et l’arrêt brutal. De plus, il est vidé à l’arrêt, comme vous l’aviez déjà compris.

Vous pouvez utiliser la RegFlushKeyfonction du logiciel qui manipule ladite 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.

utilisateur914877
la source

Hey! Je vous donnerai celui-ci si vous jetez un lien vers l'article MSDN suivant: Enregistrement des modifications du registre des applications sous Windows 8 ou Windows Server 2012 et ajout d'un bref commentaire de bloc. Votre réponse m'a conduit vers le bas à la lecture de cet article et il dit essentiellement la même chose que vous avez faite. Merci beaucoup!

Shrout1

Mais est-ce que quelqu'un sait comment un utilisateur peut appeler RegFlushKey ?

Scott

@ Scott Il semble que cela doit être fait dans le code ... L'article MSDN répertorié dans l'article contient un exemple C ++ et je l'ai déjà vu implémenté en C # ailleurs. Pas sûr que cela puisse être fait depuis la ligne de commande.

Shrout1

@Scott: Je serais choqué si sync fait affleurant le registre sur le disque. Cela n'aurait aucun sens. Pourquoi vider le cache du système de fichiers (utilisé par le gestionnaire de configuration, et non l'inverse) viderait-il soudainement le propre cache du gestionnaire de configuration? Il ne sait même pas quelle est la structure du cache de niveau supérieur, s'il en existe un.

Mehrdad

@ Scott Il y a un moyen. L'API a déjà été lié. Il existe des outils qui vous donnent une interface graphique pour appeler des fonctions Win32 arbitraires. La chose est ... C'est un détail de mise en œuvre. Si vous l'exposez, les gens s'en remettent et vous ne pouvez plus le changer. Il convient également de noter que le disque système est une bête totalement différente des supports amovibles. Le disque système est utilisé pour de nombreuses choses qui nécessitent un handle toujours ouvert (par exemple, un fichier de page). Windows ne prend pas en charge le démontage de la partition système et n'a donc pas besoin de cette "fonctionnalité". De plus ... essayez de garder les commentaires neutres. Vous détestez Windows, nous l'obtenons.

Base

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

La documentation sur FSCTL_MARK_AS_SYSTEM_HIVEa ceci à dire:

Le FSCTL_MARK_AS_SYSTEM_HIVEcode de contrôle informe le système de fichiers que le fichier spécifié contient la ruche système du registre. Le système de fichiers doit vider les données de la ruche système sur le disque au bon moment pour éviter les blocages et assurer l'intégrité des données.

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

Gardez à l' esprit que le rinçage du système de fichiers ne signifie pas le rinçage du registre , parce que le registre peut effectuer la mise en cache sur le dessus du système de fichiers. Pour vider le registre en premier, vous devez d’une manière NtFlushKeyou d’ une autre causer ou ZwFlushKeyêtre appelé sur votre clé d’intérêt.

Mehrdad
la source

Oh bonne pêche! C'est mon nouveau MSDN-ism favori: le bon moment . Mon précédent favori était "Soyez prudent lorsque vous spécifiez la clause TOP dans une requête contenant un opérateur UNION, UNION ALL, EXCEPT ou INTERSECT. Il est possible d'écrire une requête qui renvoie des résultats inattendus ", ce qui était un euphémisme pour "cette fonctionnalité est mal brisé et ne fait pas ce à quoi une personne raisonnable s’attendrait et au lieu de le réparer, nous allons le documenter ".

davidbak

@davidbak: lol, bien pour la défense de MSDN, je ne vois pas vraiment quel détail supplémentaire ils pourraient fournir sur lequel un utilisateur devrait se fier.

Mehrdad

Oh tu as raison Clairement, il s’agissait là d’une conséquence documentée des retombées du règlement conclu il ya longtemps avec l’Union européenne, selon lequel Microsoft était tenu de documenter toutes les API, quelle que soit leur interne. Cette page que vous avez liée indique même "Seuls les composants au niveau du noyau peuvent utiliser ce code de contrôle du système de fichiers", ce qui est un bon conseil pour ne pas vous toucher le dos. Toujours, " juste le bon moment " - un jour, je documenterai une de mes API avec "appelez cette méthode uniquement au bon moment " et je verrai ce qui se passera ....

davidbak

@ Davidbak: Je pense que vous êtes un peu… excité. :-P Ma conjecture est que cela a été documenté afin de laisser les pilotes du système de fichiers savent ce fichier contient la ruche de Registre SYSTEM, qui peut être important en ce sens qu'ils ne tenteraient pas de quoi que ce soit d'écriture au registre en même temps que ce fichier est vidé sur le disque. Je n'ai aucune preuve de cela cependant; c'est juste une des raisons que je trouve concevable. Un de mes doutes, cependant, est la raison pour laquelle un pilote de disque n'aurait pas besoin de le savoir aussi.

Mehrdad