Kiedy system Windows zapisuje zmiany rejestru na dysku?

TL; DR:

Zauważyłem, że jeśli dokonam zmiany rejestru, a następnie mocno zamknę system Windows 10, zmiana rejestru nie pojawi się po ponownym uruchomieniu.

Zauważyłem również, że usunięcie pliku hibernacji może wpłynąć na zdolność narzędzia do odzyskiwania systemu Linux do wprowadzania zmian w rejestrze systemu Windows w trybie offline. Narzędzie wydaje się nie być w stanie wprowadzić trwałych zmian po usunięciu pliku hibernacji. Poniżej wymienię konkretne przykłady.

Przykład 1:

Dodam klucz o nazwie „1111” do „HKLM \ SOFTWARE”. Następnie mocno wyłączam urządzenie, przytrzymując przycisk zasilania przez 5 sekund.
Po ponownym utworzeniu rejestru ten klucz i jego wartości zniknęły:
(Te obrazy zostały edytowane do celów formatowania)

Przykład 2 :

Wprowadź zmiany w rejestrze (używając regedit)
Hibernuj system
Uruchom narzędzie do odzyskiwania systemu Linux
Usuń plik hibernacji, aby zamontować dysk.
Przeczytaj rejestr systemu Windows (z narzędzia do odzyskiwania)
Zmiana rejestru zniknęła.

Wydaje się to równoznaczne z silnym zamknięciem systemu.

Przykład 3:

Widzę dziwniejsze zachowanie, gdy:

Hibernuj pudełko
Uruchom narzędzie do odzyskiwania systemu Linux i usuń plik hibernacji
Wprowadź zmiany w rejestrze (z narzędzia do odzyskiwania)
Uruchom ponownie pudełko

Zmiany te również nie są odzwierciedlone w rejestrze.

Co tu się dzieje?

Kiedy system Windows 10 zapisuje zmiany rejestru na dysku?
Dlaczego usunięcie pliku hibernacji (w przykładzie 3) uniemożliwia odzwierciedlenie zmian rejestru wprowadzonych za pomocą narzędzia do odzyskiwania przy następnym uruchomieniu?

Mając nadzieję na wyjaśnienie!

windows-10 windows-registry hibernate Shrout 1
źródło

„Zmiana rejestru nie pojawia się po ponownym uruchomieniu.” - Zmiana rejestru wchodzi w życie dopiero po ponownym uruchomieniu komputera i zwykle trzeba ponownie uruchomić tylko Eksploratora plików. Wszystko zależy od tego, jakie zachowanie zamierza wykonać zmiana rejestru, jeśli ponowne uruchomienie jest rzeczywiście wymagane. Rzeczywisty klucz jest modyfikowany, kiedy jest modyfikowany, co odpowiada na twoje pytanie.

Ramhound

Co rozumiesz przez ciężkie wyłączenie? Trzymasz przycisk zasilania, aż się wyłączy? Proces ten omija zapisywanie wszelkich zapisów w pamięci podręcznej dysku.

DavidPostill

@Ramhound Rozumiem, że nie wchodzi w życie, ale dlaczego nie został zapisany na dysku? Robię edycję, twarde wyłączanie, a potem zmiany już nie ma. To, czy

zadziałało

@ Shrout1 - Dlaczego zmuszasz urządzenie do wyłączenia zamiast bezpiecznego wyłączania urządzenia?

Ramhound

@Ramhound Przeprowadzam testy, aby zobaczyć, co się stanie, jeśli system nie zamknie się płynnie. Wiem, że to losowe, ale muszę dokładnie wiedzieć, w jaki sposób jest to związane z pamięcią, aby nie stracić niczego w naszych systemach, jeśli nie zostanie to poprawnie obsługiwane.

Shrout1

Odpowiedzi:

TL; DR: Wyłącz system poprawnie.

Hibernacja nie ma nic wspólnego z zamykaniem, jest ściśle związana z zawieszeniem do pamięci RAM (uśpieniem), z wyjątkiem zawartości pamięci RAM wypchniętej na dysk w celu ponownego odczytania i wznowienia operacji dokładnie od miejsca, w którym system został przerwany .

Jeśli chcesz, aby zmiany się utrzymywały, musisz wyłączyć hibernację i Windows Fastboot (który jest podzbiorem hibernacji). Lub możesz zrestartować komputer zamiast hibernować i uruchomić ponownie.

Powodem, dla którego zmiany nie zostały utrwalone, jest to, że nie zostały jeszcze zapisane na dysku, z wyjątkiem pliku hibernacji. Które usuwasz, co oznacza, że system plików może musieć się naprawić i wrócić do stanu „ostatniego znanego dobrego”.

Podczas gdy system jest w stanie hibernacji, będzie kilka kluczowych struktur systemu plików, które mogły nie zostać zapisane na dysk, a zamiast tego są w pamięci RAM. Po wznowieniu hibernacji system będzie oczekiwał, że dysk będzie w bardzo szczególnym stanie i możliwe jest, że pamięci podręczne dysków i ważne pliki systemowe zostaną zapisane w pliku hibernacji, a nie na dysku.

Jeśli wykonasz prawidłowe zamknięcie, system Windows poprawnie opróżni pamięć roboczą na dysk, a następnie odmontuje dysk przed czyszczeniem.

Aby wymusić prawidłowe zamknięcie, otwórz wiersz polecenia i wpisz

shutdown /s /f /t 0

/sto „zamknięcie”, /fwymuszenie i /t 0oznaczenie „teraz” (czas = 0 sekund)

Lub możesz po prostu wyłączyć fastboot i hibernację.

Przeczytaj więcej na HowtoGeek: Zamykanie nie powoduje pełnego zamknięcia systemu Windows 10 (ale restartowanie działa)

Problemem związanym z twardym zamykaniem systemu jest to, że Windows nie ma gwarancji, aby zapisać zmiany na dysku w tej samej milisekundie (lub nawet minucie), w której dokonano zmiany. Prawie na pewno zostanie napisane w ciągu kilku minut, ale prawdopodobieństwo, że zostanie napisane, z czasem wzrośnie. Jest mało prawdopodobne, aby być napisane natychmiast, a następnie blisko do chwili dokonać zmiany gwałtownie wzrasta prawdopodobieństwo, i prawie na pewno zostały napisane w ciągu godziny.

Rzecz w tym, że wymuszając twarde zamknięcie systemu, nie dajesz systemowi szansy na bezpieczne zapisanie zmian na dysku.

Większość współczesnych systemów plików została napisana w celu dokonywania zmian w najbezpieczniejszy możliwy sposób. W przeszłości były one określane jako „atomowe”, ponieważ zmiana nastąpiła albo nie.

Dziś znamy je jako osadzone systemów plików , ponieważ mają one dziennik operacji, które będą się zdarzyć, że może być albo cofnięte lub walcowane przodu w przypadku awarii i ponownym uruchomieniu systemu. Po uruchomieniu z powodu awarii zasilania system sprawdza dziennik i dla każdej transakcji sprawdza, czy rzeczywiste dane pliku są zapisywane na dysku i czy są „dobre”. Jeśli tak, to przejście przewija się do przodu i jest zakończone, jeśli nie, to przywraca stare dane.

Korzystając z tej kolejności, dysk jest prawie zawsze w stanie łatwym do naprawy.

Ale zmuszając system do nieoczekiwanego wyłączenia, nie możesz zagwarantować, że transakcja przebiegła wystarczająco daleko, aby przejść do przodu po naprawie, i są szanse, że system operacyjny, taki jak Linux, nie będzie obchodził historii transakcji tak bardzo jak Windows i jest bardziej prawdopodobne niż nie wprowadzać zmian, które przewracają wszystko do tyłu, a nie do przodu.

Po ponownym uruchomieniu w systemie Windows może on spróbować lub być w stanie naprawić dysk poprawnie, ponieważ ma bardziej intymną znajomość systemu plików.

Mokubai
źródło

Dziękuję Ci! Doceniam twoją odpowiedź :) Wyłączyłem hibernację, ponownie uruchomiłem i ponownie uruchomiłem ten sam test. Przykład 1 ma ten sam wynik, nie dotyczy pliku hibernacji. Wygląda na to, że zmiany rejestru są zapisywane tylko w pewnym momencie podczas wylogowywania / zamykania ... Zgadzam się również, że system może szukać stanu „ostatniego dobrego” po przebudzeniu ze zepsutej hibernacji - ma tendencję do przeprowadzania kontroli integralności.

Shrout1

Hmmm ... Więc pobrałem sysinternals „synchronizację”, która wymusza pamięć podręczną zapisu na dysk i która nic nie zrobiła (wciąż traciłam klucze / wartości przy twardym wyłączaniu). Uruchomiłem także eksplorator procesów i sprawdziłem we / wy dysku we właściwościach programu Regedit. Odczytał we / wy, ale nie zapisał we / wy. To sprawia, że myślę, że może to być oczekiwanie na zamknięcie ... Czy znasz jakąś wyjątkowo suchą dokumentację M $, która mogłaby to jasno przedstawić? Jeszcze raz dziękuję za całą pomoc !!

Shrout1

Dziennik NTFS nie gwarantuje żadnych danych dotyczących plików. Chodzi tylko o zachowanie spójności metadanych NTFS, aby nie skończyć się uszkodzonym systemem plików . Poszczególne pliki mogą nadal mieć zapisane częściowe zmiany, powodując uszkodzenie pliku. Istnieje transakcyjny NTFS, ale nie jest to zalecane i bardzo rzadko używane. Z tego też powodu silniki baz danych prowadzą własne dzienniki w celu zapewnienia spójności danych. Zobacz także blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

Bob

@ Shrout1 Zakładając, że zmiany w rejestrze oczekują na zapis w pamięci podręcznej zapisu. Jest całkiem możliwe, że zamiast tego są one zarządzane osobno i że nie ma to nic wspólnego z systemem plików, buforowaniem lub innym. Na przykład Ostatnia znana dobra konfiguracja jest aktualizowana tylko po pomyślnym uruchomieniu. (Nie wiem wystarczająco dużo na temat wewnętrznych elementów rejestru, aby mieć pewność, że zmiany zostaną zapisane. I wtedy może być zaangażowany TxR .)

Bob

Czy istnieje powód, dla którego wymuszasz zamknięcie? AFAIK, który wymusza tylko zamykanie uruchomionych aplikacji, co nie robi nic poza zabijaniem aplikacji, których inaczej nie można zamknąć, i zwiększa prawdopodobieństwo utraty gdzieś niezapisanych zmian, jeśli nie wiesz, czym jesteś robiąc lub że umieściłeś jakąś aplikację w stanie niemożliwym do odzyskania - tak naprawdę nie nazwałbym tego „właściwym” zamknięciem.

NotThatGuy

Zgodnie z dokumentacją na stronie MSDN dlaRegFlushKey :

Wywołanie RegFlushKey jest kosztowną operacją, która znacząco wpływa na wydajność całego systemu, ponieważ zużywa przepustowość dysku i blokuje modyfikacje wszystkich kluczy przez wszystkie procesy w gałęzi rejestru, która jest opróżniana aż do zakończenia operacji opróżniania. RegFlushKey powinien być wywoływany jawnie tylko wtedy, gdy aplikacja musi zagwarantować, że zmiany rejestru zostaną utrwalone na dysku natychmiast po modyfikacji. Wszystkie modyfikacje dokonane w kluczach są widoczne dla innych procesów bez konieczności ich spłukiwania na dysk.

Alternatywnie, rejestr ma mechanizm „leniwego opróżniania”, który w regularnych odstępach czasu opróżnia modyfikacje rejestru na dysku. Oprócz tej regularnej operacji opróżniania zmiany rejestru są również opróżniane na dysk przy zamykaniu systemu. Umożliwienie „leniwego opróżniania” w celu opróżnienia zmian rejestru jest najskuteczniejszym sposobem zarządzania zapisami rejestru do magazynu rejestru na dysku.

Sugeruje to, że oprócz natychmiastowego opróżnienia określonego klucza na dysk (co blokuje wszystkich innych poza rejestrem aż do zakończenia opróżniania ), rejestr jest okresowo automatycznie czyszczony: nie podano czasu, ale przypuszczalnie jest to co najmniej więcej niż czas oczekiwania między napisaniem klucza a twardym zamknięciem. Ponadto jest on spłukiwany przy wyłączaniu, jak już się domyśliłeś.

Możesz użyć RegFlushKeyfunkcji w oprogramowaniu, która manipuluje tym kluczem, lub utworzyć dodatkowe narzędzie, aby wymusić natychmiastowe zapisanie klucza rejestru na dysku, jeśli ma to zasadnicze znaczenie dla przypadku użycia.

użytkownik914877
źródło

Hej! Dam ci to, jeśli umieścisz link do następującego artykułu MSDN: Zapisywanie zmian rejestru aplikacji w systemie Windows 8 lub Windows Server 2012 i dodanie krótkiego cytatu blokowego. Twoja odpowiedź zaprowadziła mnie do króliczej nory do tego artykułu i mówi w zasadzie to samo, co zrobiłeś. Wielkie dzięki!

Shrout1

Ale czy ktoś wie, jak użytkownik może wywołać RegFlushKey ?

Scott

@Scott Wygląda na to, że należy to zrobić za pomocą kodu ... Artykuł MSDN wymieniony w poście ma przykład C ++ i widziałem go zaimplementowanego w C # gdzie indziej. Nie jestem pewien, czy można to zrobić z wiersza poleceń.

Shrout1,

@Scott: Byłbym zaskoczony jeśli sync nie równo rejestr na dysku. To po prostu nie miałoby sensu. Dlaczego opróżnianie pamięci podręcznej systemu plików (która jest używana przez menedżera konfiguracji, a nie na odwrót) powinno nagle opróżniać pamięć podręczną menedżera konfiguracji? Nawet nie wie, jaka jest struktura pamięci podręcznej wyższego poziomu, jeśli w ogóle istnieje.

Mehrdad

@Scott Istnieje sposób. Interfejs API został już połączony. Istnieją narzędzia, które dają GUI do wywoływania dowolnych funkcji Win32. Chodzi o to ... To szczegół implementacji. Jeśli go ujawnisz, ludzie polegają na nim, a wtedy nie możesz go zmienić. Warto również zauważyć, że dysk systemowy jest zupełnie inną bestią niż nośniki wymienne. Dysk systemowy jest używany do wielu rzeczy, które wymagają, aby uchwyt był zawsze otwarty (np. Plik strony). System Windows nie obsługuje odmontowywania partycji systemowej, więc nie ma potrzeby korzystania z tej „funkcji”. Plus ... staraj się zachować neutralność komentarzy. Nienawidzisz Windowsa, my go rozumiemy.

Podstawowy

TL; DR: Bardzo ostrożnie jest to zrobić w odpowiednim momencie .

Dokumentacja FSCTL_MARK_AS_SYSTEM_HIVEzawiera następujące informacje:

FSCTL_MARK_AS_SYSTEM_HIVEKod sterujący informuje system plików, który zawiera określony plik systemu gałąź Rejestru. System plików musi opróżnić dane gałęzi systemu na dysk w odpowiednim momencie, aby uniknąć zakleszczeń i zapewnić integralność danych.

Nie wierzę, że jest więcej szczegółów dostępnych publicznie niż to.

Należy pamiętać, że opróżnienie systemu plików nie oznacza opróżnienia rejestru , ponieważ rejestr może wykonywać buforowanie w górnej części systemu plików. Aby najpierw opróżnić rejestr, musisz w jakiś sposób wywołać NtFlushKeylub ZwFlushKeyzostać wezwanym na klucz zainteresowania.

Mehrdad
źródło

Och, dobry chwyt! To mój nowy ulubiony MSDN-ism: odpowiedni moment . Moim poprzednim ulubionym było „Zachowaj ostrożność przy określaniu klauzuli TOP w zapytaniu zawierającym operator UNION, UNION ALL, EXCEPT lub INTERSECT. Możliwe jest napisanie zapytania zwracającego nieoczekiwane wyniki ”, co było eufemizmem dla „ta funkcja jest mocno zepsuty i nie robi tego, czego oczekiwałaby jakakolwiek rozsądna osoba i zamiast go naprawić, udokumentujemy to.

davidbak

@davidbak: lol, dobrze w obronie MSDN, tak naprawdę nie widzę, jakie więcej szczegółów mogliby podać, na których użytkownik powinien polegać.

Mehrdad

Och, masz rację; najwyraźniej było to po prostu coś, co zostało udokumentowane jako wynik wcześniejszej ugody w UE, w której Microsoft był zobowiązany do udokumentowania wszystkich interfejsów API - bez względu na to, jak są one wewnętrzne. Na tej stronie, którą podlinkowałeś, jest nawet napisane: „Tylko komponenty na poziomie jądra mogą korzystać z tego kodu sterującego systemem plików”, co jest mocną wskazówką, aby trzymać się z daleka. Mimo to, „ we właściwym momencie ” - pewnego dnia udokumentuję moje API za pomocą „wywołaj tę metodę tylko we właściwym momencie ” i zobaczę, co się stanie…

davidbak

@davidbak: Myślę, że jesteś trochę ... podekscytowany. :-P Domyślam się, że zostało to udokumentowane w celu poinformowania sterowników systemu plików, który plik zawiera gałąź rejestru SYSTEM, co może być ważne, ponieważ nie próbowali zapisywać niczego w rejestrze w tym samym czasie, co ten plik jest opróżniany na dysk. Nie mam jednak na to dowodów; to tylko jeden powód, który uważam za możliwy. Wątpię jednak, dlaczego sterownik dysku też nie musiałby o tym wiedzieć.

Mehrdad