Quando Windows scrive le modifiche del registro su disco?


43

TL; DR:

Ho notato che se eseguo una modifica del registro e quindi arresto il sistema Windows 10, la modifica del registro non viene visualizzata dopo il riavvio.

Ho anche notato che la cancellazione di un file di ibernazione può influire sulla capacità di uno strumento di recupero di Linux di apportare modifiche al registro di Windows in uno stato offline. Lo strumento sembra non essere in grado di apportare modifiche permanenti dopo l'eliminazione di un file di ibernazione. Elencherò di seguito alcuni esempi specifici.

Esempio 1:

  • Aggiungo una chiave denominata "1111" in "HKLM \ SOFTWARE". Dopodiché spegni la mia scatola tenendo premuto il pulsante di accensione per 5 secondi.
  • Chiave di prova
  • Quando eseguo il backup del registro, quella chiave e i suoi valori scompaiono:
  • Test Key Gone
  • (Queste immagini sono state modificate a scopo di formattazione)

Esempio 2 :

  • Apporta una modifica al registro (utilizzando regedit)
  • Iberna il sistema
  • Avvia in uno strumento di recupero di Linux
  • Elimina il file di ibernazione per montare il disco.
  • Leggi il registro di Windows (dallo strumento di recupero)
  • La modifica del registro non è più disponibile.

Questo sembra equivalente a un duro arresto sulla scatola.

Esempio 3:

Vedo un comportamento estraneo quando:

  • Iberna la scatola
  • Avviare su uno strumento di ripristino di Linux ed eliminare il file di ibernazione
  • Apporta modifiche al registro (dallo strumento di recupero)
  • Riavvia la scatola

Tali modifiche non si riflettono nemmeno nel registro.

Quindi cosa sta succedendo qui?

  • Quando Windows 10 scrive le modifiche del registro sul disco?
  • Perché la cancellazione di un file di ibernazione (nell'Esempio 3) impedisce che le modifiche al registro effettuate dallo strumento di recupero vengano riflesse all'avvio successivo?

Spero di avere qualche chiarimento!


2
"La modifica del registro non viene visualizzata dopo il riavvio." - La modifica del registro non ha effetto fino al riavvio e, in genere, è necessario riavviare solo Esplora file. Tutto dipende dal comportamento che la modifica del Registro di sistema è destinata a fare se è effettivamente necessario un riavvio. La chiave effettiva viene modificata, quando viene modificata, che risponde alla tua domanda.
Ramhound,

8
Cosa intendi per arresto estremo? Tenere premuto il pulsante di accensione fino allo spegnimento? Tale processo ignora la scrittura di eventuali scritture cache del disco in sospeso.
DavidPostill

2
@Ramhound Ho capito che non ha effetto, ma perché non è stato scritto sul disco? Faccio la modifica, lo spegnimento e poi il cambiamento non c'è più. A quel punto non importa se sia entrato in vigore nella memoria
Shrout1

2
@ Shrout1 - Perché stai forzando lo spegnimento della macchina invece di spegnerla in sicurezza?
Ramhound,

6
@Ramhound Sto eseguendo dei test per vedere cosa succede se il sistema non si spegne con grazia. Casuale, lo so, ma devo sapere esattamente come questo è impegnato nella memoria in modo da non perdere nulla sui nostri sistemi se non viene gestito correttamente.
Shrout1

Risposte:


54

TL; DR: arresta correttamente il sistema.


L'ibernazione non ha nulla a che fare con lo spegnimento, è strettamente correlato alla sospensione su RAM (sleep) tranne che con il contenuto della RAM spinto sul disco per poterlo rileggere e riprendere l'operazione esattamente da dove era stato interrotto il sistema .

Se si desidera che le modifiche persistano, è necessario disabilitare l'ibernazione e Windows Fastboot (che è un sottoinsieme dell'ibernazione). In alternativa, è possibile riavviare anziché ibernare e riavviare.

Il motivo per cui le modifiche non sono persistenti è perché non sono ancora state scritte sul disco, tranne nel file di ibernazione. Che stai eliminando, il che significa che potrebbe essere necessario che il filesystem si ripari da solo e torni allo stato "ultimo bene noto".

Mentre il sistema è ibernato, ci saranno diverse strutture chiave del filesystem che potrebbero non essere state scritte su disco e che invece si trovano nella RAM. Al momento della ripresa dalla modalità di sospensione, il sistema si aspetta che il disco si trovi in ​​uno stato molto particolare ed è possibile che le cache del disco e i file di sistema importanti vengano salvati nel file di sospensione piuttosto che sul disco effettivo.

Se si esegue un arresto corretto, Windows scaricherà correttamente la memoria di lavoro su disco, quindi smonterà il disco in modo pulito prima di spegnerlo.

Per forzare un arresto corretto, aprire un prompt dei comandi e digitare

shutdown /s /f /t 0

/sè "spegnimento", /fper forzare e /t 0per indicare "ora" (tempo = 0 secondi)

Oppure puoi semplicemente disabilitare l'avvio rapido e l'ibernazione.

Maggiori informazioni su HowtoGeek: lo spegnimento non arresta completamente Windows 10 (ma il riavvio sì)


Relativamente a te che stai facendo un arresto forzato, il problema è che Windows non è sicuro di scrivere alcuna modifica sul disco nello stesso millisecondo (o persino minuto) in cui apporti la modifica. Quasi sicuramente sarà scritto entro pochi minuti, ma la probabilità che sia stato effettivamente scritto aumenterà nel tempo. È improbabile che venga scritto immediatamente, quindi vicino al momento in cui si apporta la modifica la probabilità aumenta nettamente e sarà quasi sicuramente scritta entro un'ora.

Il fatto è che forzando un arresto forzato non si dà al sistema la possibilità di scrivere in modo sicuro le modifiche sul disco.

I filesystem più moderni sono scritti per apportare modifiche nel modo più sicuro possibile. In passato sono stati definiti "atomici", come nel caso del cambiamento o è avvenuto o no.

Oggi noi li conosciamo come file system imperniata perché tengono un registro delle operazioni che si accadere che può essere sia ritornato o laminati in avanti in caso di guasto del sistema e riavviare. All'avvio da un'interruzione di corrente, il sistema controlla il journal e per ogni transazione verifica se i dati del file effettivo vengono scritti sul disco ed è "buono". Se è allora la transazione rotola in avanti e viene completata, altrimenti torna ai vecchi dati.

Usando questo ordine il disco è quasi sempre in uno stato facile da riparare.

Ma costringendo il tuo sistema a spegnersi inaspettatamente non puoi garantire se la transazione è progredita abbastanza lontano da andare avanti al momento della riparazione, e ci sono possibilità che un sistema operativo come Linux non si preoccupi tanto di Windows della cronologia delle transazioni ed è più probabile piuttosto che apportare modifiche che ruotano tutto all'indietro anziché in avanti.

Se hai riavviato Windows, potrebbe provare o essere in grado di riparare correttamente il disco in quanto ha una conoscenza più intima del filesystem.


Grazie! Apprezzo la tua risposta :) Ho disattivato l'ibernazione, riavviato ed eseguito nuovamente lo stesso test. L'esempio 1 ha lo stesso risultato, nessun file di ibernazione coinvolto. Sembra che le modifiche al registro vengano scritte solo ad un certo punto durante la disconnessione / arresto ... Sono anche d'accordo sul fatto che il sistema potrebbe essere alla ricerca di uno stato "ultimo buono" al risveglio da un letargo rotto - tende a eseguire controlli di integrità.
Shrout1

1
Hmmm ... Quindi ho scaricato sysinternals "sync" che forza la cache di scrittura su disco e che non ha fatto nulla (ha perso le chiavi / i valori allo spegnimento immediato). Ho anche eseguito Process Explorer e ho esaminato l'I / O del disco nelle proprietà di Regedit. Aveva letto I / O ma nessun I / O di scrittura. Questo mi fa pensare che potrebbe essere in attesa di arresto ... Conosci qualche documentazione M $ estremamente secca che potrebbe spiegarlo chiaramente? Grazie ancora per tutto il vostro aiuto!!
Shrout1

11
Il journal NTFS non fornisce garanzie sui dati dei file. È semplicemente per mantenere coerenti i metadati NTFS, quindi non si finisce con un filesystem rotto . I singoli file possono ancora avere delle modifiche parziali registrate su di essi, rompendo il file. C'è NTFS transazionale ma non è raccomandato e molto raramente utilizzato. Questo è anche il motivo per cui i motori di database mantengono il proprio diario per la coerenza dei dati. Vedi anche blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673
Bob

2
@ Shrout1 Questo presuppone che le modifiche al registro siano in sospeso nella cache di write-back. È del tutto possibile che vengano invece gestiti separatamente e che ciò non abbia nulla a che fare con il filesystem, la memorizzazione nella cache o altro. Ad esempio, Ultima configurazione valida nota viene aggiornata solo all'avvio corretto. (Non so abbastanza sugli interni del registro per essere sicuro quando le modifiche vengono salvate. E quindi potrebbe essere coinvolto TxR .)
Bob

1
C'è un motivo per cui stai forzando l'arresto? AFAIK che forza solo la chiusura delle applicazioni in esecuzione, il che non fa altro che uccidere le applicazioni che altrimenti non potresti chiudere e rende più probabile la perdita di alcune modifiche non salvate da qualche parte se non sai cosa sei facendo o che avresti messo alcune applicazioni in uno stato irrecuperabile - non lo definirei davvero un arresto "corretto".
NotThatGuy

39

Come documentato sulla pagina MSDN perRegFlushKey :

La chiamata a RegFlushKey è un'operazione costosa che influisce in modo significativo sulle prestazioni a livello di sistema in quanto consuma larghezza di banda del disco e blocca le modifiche a tutte le chiavi da parte di tutti i processi nell'hive del registro che viene scaricato fino al completamento dell'operazione di scarico. RegFlushKey deve essere chiamato in modo esplicito solo quando un'applicazione deve garantire che le modifiche al registro vengano mantenute sul disco immediatamente dopo la modifica. Tutte le modifiche apportate alle chiavi sono visibili ad altri processi senza la necessità di scaricarle sul disco.

In alternativa, il registro ha un meccanismo di "svuotamento lento" che scarica le modifiche del registro sul disco a intervalli regolari di tempo. Oltre a questa normale operazione di scaricamento, anche le modifiche al registro vengono scaricate sul disco all'arresto del sistema. Consentire a "lazy flush" di scaricare le modifiche al registro è il modo più efficiente per gestire le scritture del registro nell'archivio del registro su disco.

Ciò suggerisce che, oltre a svuotare immediatamente una chiave specifica su disco (che blocca tutti gli altri fuori dal registro fino al completamento dello svuotamento), il registro viene automaticamente scaricato periodicamente: non viene fornito un tempo, ma presumibilmente è almeno più che tempo che hai aspettato tra la scrittura della chiave e l'arresto forzato. Inoltre, è arrossato allo spegnimento, come avevi già capito.

È possibile utilizzare la RegFlushKeyfunzione nel software che manipola detta chiave o creare uno strumento aggiuntivo per forzare la scrittura immediata di una chiave di registro su disco, se questo è cruciale per il proprio caso di utilizzo.


Hey! Ti darò questo se lanci un collegamento al seguente articolo MSDN: Salvataggio delle modifiche al registro dell'applicazione su Windows 8 o Windows Server 2012 e aggiunta di una breve citazione. La tua risposta mi ha portato nella tana del coniglio a quell'articolo e in pratica dice la stessa cosa che hai fatto. Grazie mille!
Shrout1

Qualcuno sa come un utente può chiamare RegFlushKey ?
Scott,

@Scott Sembra che debba essere fatto nel codice ... L'articolo MSDN elencato nel post ha un esempio C ++ e l'ho visto implementato in C # altrove. Non sono sicuro che possa essere fatto dalla riga di comando.
Shrout1

3
@ Scott: Sarei scioccato se sync fatto a filo del Registro di sistema per il disco. Non avrebbe alcun senso. Perché svuotare la cache del file system (che viene utilizzata dal gestore della configurazione, non viceversa) dovrebbe improvvisamente svuotare la cache del gestore della configurazione? Non sa nemmeno quale sia la struttura della cache di livello superiore, se ne esiste addirittura una.
Mehrdad,

1
@Scott C'è un modo. L'API è già stata collegata. Ci sono strumenti là fuori che ti danno una GUI per chiamare funzioni Win32 arbitrarie. La cosa è ... è un dettaglio di implementazione. Se lo esponi, le persone fanno affidamento su di esso e quindi non puoi cambiarlo. Vale anche la pena notare che il disco di sistema è una bestia totalmente diversa dai supporti rimovibili. Il disco di sistema viene utilizzato per molte cose che richiedono un handle sempre aperto (ad es. File di paging). Windows non supporta lo smontaggio della partizione di sistema, quindi non è necessario per questa "funzionalità". Inoltre ... prova a mantenere i commenti neutrali. Tu odi Windows, lo capiamo.
Basic

14

TL; DR: è molto attento farlo al momento giusto .

La documentazione su FSCTL_MARK_AS_SYSTEM_HIVEha questo da dire:

Il FSCTL_MARK_AS_SYSTEM_HIVEcodice di controllo informa il file system che il file specificato contiene l'hive di sistema del registro. Il file system deve scaricare i dati dell'hive di sistema sul disco al momento giusto per evitare deadlock e garantire l'integrità dei dati.

Non credo che ci siano più dettagli disponibili pubblicamente di questo.

Tenere presente che lo svuotamento del file system non implica lo svuotamento del registro , poiché il registro può eseguire la memorizzazione nella cache in cima al file system. Per svuotare prima il registro, è necessario in qualche modo causare NtFlushKeyo ZwFlushKeyessere chiamati sulla chiave di interesse.


Oh buona cattura! Questo è il mio nuovo preferito MSDN-ism: il momento giusto . Il mio preferito precedente era "Prestare attenzione quando si specifica la clausola TOP in una query che contiene un operatore UNION, UNION ALL, EXCEPT o INTERSECT. È possibile scrivere una query che restituisca risultati imprevisti " che era un eufemismo per "questa funzione è gravemente rotto e non fa ciò che una persona ragionevole si aspetterebbe e invece di sistemarlo lo documenteremo ".
davidbak,

@davidbak: lol, bene a difesa di MSDN, non vedo davvero su quali ulteriori dettagli potrebbero fornire un utente su cui fare affidamento.
Mehrdad,

Oh hai ragione; chiaramente questo era solo qualcosa documentato come una ricaduta dell'insediamento UE di lunga data in cui a Microsoft era richiesto di documentare tutte le API, indipendentemente da quanto fossero interne. Questa pagina che hai linkato dice anche "Solo i componenti a livello di kernel possono usare questo codice di controllo del filesystem" che è un forte suggerimento per tenere le mani lontane. Comunque, " solo il momento giusto " - un giorno documenterò alcune mie API con "chiama questo metodo solo al momento giusto " e vedi cosa succede ....
davidbak,

@davidbak: penso che tu sia un po '... emozionato. :-P La mia ipotesi è che questo è stato documentato per far sapere ai driver del file system quale file contiene l'hive del registro di sistema, il che può essere importante in quanto non tenterebbero di scrivere nulla nel registro contemporaneamente a quel file viene scaricato sul disco. Non ho prove di questo però; è solo una delle ragioni che ritengo concepibile. Un dubbio che ho a riguardo, tuttavia, è perché un driver del disco non avrebbe bisogno di sapere anche questo.
Mehrdad,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.