Windows kayıt defteri değişikliklerini ne zaman diske yazar?

TL; DR:

Kayıt defteri değişikliği yapar ve Windows 10 sistemimi kapatmayı kapatırsam, kayıt defteri değişikliğinin yeniden başlatıldıktan sonra görünmediğini fark ettim.

Ayrıca bir hazırda bekletme dosyasının silinmesinin Linux kurtarma aracının çevrimdışı bir durumda Windows kayıt defterinde değişiklik yapma yeteneğini etkileyebileceğini de farkettim. Araç, bir hazırda bekleme dosyasının silinmesinden sonra kalıcı değişiklikler yapamıyor gibi görünüyor. Aşağıda belirli örnekleri listeleyeceğim.

Örnek 1:

"HKLM \ SOFTWARE" içine "1111" adlı bir anahtar ekledim. Daha sonra güç düğmesini 5 saniye basılı tutarak kutumu kapattım.
Kayıt defterini yedeklediğimde, bu anahtar ve değerleri kayboluyor:
(Bu görüntüler biçimlendirme amacıyla düzenlendi)

Örnek 2 :

Kayıt defterinde değişiklik yapın (regedit kullanarak)
Hazırda bekletme sistemi
Linux kurtarma aracına önyükleme yapın
Diski takmak için hazırda bekletme dosyasını silin.
Windows kayıt defterini okuyun (kurtarma aracından)
Kayıt defteri değişikliği gitti.

Bu, kutunun sert bir şekilde kapanmasına eşdeğer görünüyor.

Örnek 3:

Ne zaman garip davranışlar görüyorum:

Kutuyu hazırda beklet
Bir Linux kurtarma aracına önyükleme yapın ve hazırda bekleme dosyasını silin
Kayıt defterinde değişiklik yapın (kurtarma aracından)
Kutuyu yeniden başlat

Bu değişiklikler kayıt defterine de yansıtılmaz.

Peki burada neler oluyor?

Windows 10 kayıt defteri değişikliklerini diske ne zaman yazar?
Bir hazırda bekletme dosyasının silinmesi (Örnek 3'te) neden kurtarma aracında yapılan kayıt defteri değişikliklerinin bir sonraki önyüklemede yansıtılmasını engelliyor?

Biraz açıklama almak için umut!

windows-10 windows-registry hibernate

— Shrout1
kaynak

"Kayıt defteri değişikliği yeniden başlatıldıktan sonra görünmüyor." - Kayıt defteri değişikliği yeniden başlatılıncaya kadar yürürlüğe girmez ve genellikle yalnızca Dosya Gezgini yeniden başlatılmalıdır. Tamamen, yeniden başlatma gerçekten gerekliyse, kayıt defteri değişikliğinin yapması gereken davranışa bağlıdır. Asıl anahtar, değiştirildiğinde sorunuzu yanıtlayan değiştirilir.

— Ramhound

Sert bir kapanma ile ne demek istiyorsun? Güç düğmesini kapanana kadar basılı tutmak? Bu işlem, beklemedeki herhangi bir disk önbelleği yazmayı yazmayı atlar.

— DavidPostill

@Ramhound Ben yürürlüğe girmeyeceğini anlıyorum, ancak neden diske yazılmadı? Düzenleme yapıyorum, güç kapalı ve sonra değişim artık yok. Hafızada yürürlüğe girip girmediği bu noktada önemli değil

— Shrout1

@ Kapanma1 - Makineyi güvenli bir şekilde kapatmak yerine neden makineyi kapatmaya zorluyorsunuz?

— Ramhound

@Ramhound Sistem incelikle kapanmazsa ne olacağını görmek için testler yapıyorum. Rastgele, biliyorum, ancak bunun tam olarak nasıl hafızaya alındığını bilmem gerekiyor, böylece doğru kullanılmazsa sistemlerimizde hiçbir şey kaybetmeyiz.

— Shrout1

Yanıtlar:

TL; DR: Sisteminizi kapatın.

Hazırda bekletme modunun kapatılması ile ilgisi yoktur, yeniden okunması ve sistemin tam olarak kaldığı yerden devam etmesi için diske basılan RAM içeriği dışında RAM'in askıya alınması (uyku) ile yakından ilgilidir. .

Değişikliklerin devam etmesini istiyorsanız, hazırda bekletme modunu ve hazırda bekletme modunun bir alt kümesi olan Windows Fastboot'u devre dışı bırakmanız gerekir . Veya hazırda bekletme modundan ziyade yeniden başlatıp yeniden başlatabilirsiniz.

Değişikliklerin devam etmemesinin nedeni , hazırda bekleme dosyası dışında henüz diske yazılmadıklarıdır . Hangi sildiğiniz, yani dosya sisteminin kendisini tamir etmesi ve “son bilinen iyi” durumuna geri dönmesi gerekebilir.

Sistem hazırda bekletme modundayken, diske yazılmamış ve bunun yerine RAM'de bulunan birkaç anahtar dosya sistemi yapısı olacaktır. Sistem, hazırda bekletme modundan çıktıktan sonra, diskin çok özel bir durumda olmasını bekler ve disk önbelleklerinin ve önemli sistem dosyalarının hazırda bekletme yerine gerçek diske kaydedilmesi mümkündür.

Düzgün kapanma yaparsanız, Windows çalışma belleğini düzgün bir şekilde diske temizler ve sonra kapatmadan önce diski temiz bir şekilde çıkarın.

Düzgün kapanmaya zorlamak için bir komut istemi açın ve

shutdown /s /f /t 0

/s"kapatma", /fzorlamak ve /t 0"şimdi" demek (süre = 0 saniye)

Veya fastboot ve hazırda bekletme modunu devre dışı bırakabilirsiniz.

HowtoGeek'te daha fazla bilgi edinebilirsiniz: Kapatılıyor Windows 10'u Tamamen Kapatmıyor (Ancak Yeniden Başlatıyor)

Sert bir kapatma işlemi yapmanızla ilgili problem, Windows'un, diske herhangi bir değişiklik yazdığınız aynı milisaniyede (veya hatta dakikada) herhangi bir değişiklik yazması garanti edilmemesidir. Neredeyse kesinlikle birkaç dakika içinde yazılacak ancak gerçekte yazmış olma olasılığı zamanla artacaktır. Daha sonra, hemen yazılacak düşüktür yakın sen olasılık artar keskin değişiklik yapmak zaman ve neredeyse kesinlikle bir saat içinde yazılı olacaktır.

Mesele şu ki, zorlu bir kapatmaya zorlayarak sisteme güvenli bir şekilde diske değişiklikler yazma şansı vermeyeceksiniz.

Çoğu modern dosya sistemi, değişiklikleri en güvenli şekilde yapmak için yazılmıştır. Geçmişte, değişimde olduğu gibi ya da olmadığından "atomik" olarak adlandırıldılar.

Bugün bunları biliyoruz journalled dosya sistemleri onlar operasyonların bir günlük tutmak çünkü edecektir bu da intikal veya sistem arızası ve yeniden başlatma durumunda öne doğru yuvarlandı edilebilir olur. Elektrik kesintisinden başlatıldığında, sistem dergiyi kontrol eder ve her işlem için gerçek dosya verilerinin diske yazılıp yazılmadığını ve "iyi" olup olmadığını kontrol eder. Öyleyse, geçiş ileriye doğru yuvarlanır ve tamamlanır, değilse de eski verilere geri döner.

Bu siparişi kullanarak, disk neredeyse her zaman onarımı kolay bir durumdadır.

Ancak, sisteminizi beklenmedik bir şekilde kapatmaya zorlayarak, işlemin onarımdan sonra ileriye doğru ilerlemesini sağlayacak kadar ilerlemiş olup olmadığını garanti edemezsiniz ve olasılıkla Linux gibi bir işletim sisteminin işlem geçmişiyle ilgili Windows kadar önemli olmayacağı ve daha muhtemel olduğu sadece ileriye değil, her şeyi geriye doğru yuvarlayan değişiklikler yapmamak için.

Windows'u yeniden başlattıysanız, dosya sistemi hakkında daha samimi bir bilgiye sahip olduğundan diski düzgün bir şekilde onarmayı deneyebilir veya deneyebilir.

— Mokubai
kaynak

Teşekkür ederim! Yanıtınız için teşekkür ederim :) Hazırda bekletme modunu kapattım, yeniden başlattım ve aynı testi tekrar yaptım. Örnek 1 aynı sonuca sahip, hazırda bekleme dosyası yok. Kayıt defteri değişikliklerinin oturum kapatma / kapatma sırasında yalnızca bir noktada yazılmış olduğu anlaşılıyor ... Ayrıca, bozuk bir hazırda bekletme modundan uyanırken sistemin "son iyi" bir durum aradığına da katılıyorum - bütünlük kontrolleri yapma eğilimindedir.

— Shrout1

Hmmm ... Yazma önbelleğini diske zorlayan ve hiçbir şey yapmayan sysinternals "sync" i indirdim (hala kapanma durumunda tuşları / değerleri kaybettim). Ayrıca işlem gezginini çalıştırdım ve Regedit'in özelliklerinde Disk G / Ç'ye baktım. G / Ç'yi okumuş, ancak G / Ç yazmamıştı. Bu beni o düşündürüyor olabilir bu açıkça ortaya koymak olabilecek son derece kuru M $ belgelerine biliyor musunuz ... kapatma bekliyor? Bütün yardımların için tekrar teşekkürler!!

— Shrout1

NTFS günlüğü dosya verileri hakkında hiçbir garanti vermez. Yalnızca NTFS meta verilerini tutarlı tutmak, bu nedenle bozuk bir dosya sistemi ile bitmezsiniz . Bireysel dosyalar hala kendilerine kaydedilmiş kısmi değişikliklere neden olabilir. Orada İşlemsel NTFS ama bu tavsiye edilmez ve çok nadiren kullandı. Bu nedenle veritabanı motorlarının veri tutarlılığı için kendi günlüklerini tutmasının nedeni budur. Ayrıca bkz. Blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

— Bob

@ Shrout1 Kayıt defteri değişikliklerinin geri yazma önbelleğinde beklemede olduğu varsayılıyor. Bunun yerine ayrı ayrı yönetilmeleri ve bunun dosya sistemi, önbellekleme veya başka bir şeyle ilgisi olmaması tamamen mümkündür. Örneğin, Bilinen Son İyi Yapılandırma yalnızca başarılı bir başlangıçta güncellenir. (Değişiklikler kaydedildiğinde kesin olarak kayıt defterinde bulunanlar hakkında yeterince bilgim yok. Ve sonra TxR de dahil olabilir.)

— Bob

Kapatmaya zorlamanın bir nedeni var mı? Yalnızca çalışan uygulamaları kapatmaya zorlayan, başka şekilde kapatamayacağınız uygulamaları öldürmekten başka bir şey yapmayan ve ne yaptığınızı bilmiyorsanız, kaydedilmemiş değişiklikleri bir yerde kaybetme olasılığınızı artıran AFAIK ya da bazı uygulamaları kurtarılamaz duruma getirdiyseniz - buna gerçekten "uygun" bir kapatma demezdim.

— NotThatGuy

MSDN sayfasındaRegFlushKey belgelendiği gibi :

Arayan RegFlushKey önemli ölçüde floş operasyon tamamlanıncaya kadar kızarmış ediliyor defteri kovanında tüm süreçlerde bütün anahtarlara Disk bant genişliği ve bloklar modifikasyonları tüketir olarak sistem genelinde performansı etkiler, pahalı bir işlemdir. RegFlushKey , yalnızca bir uygulamanın kayıt defteri değişikliklerinin değişiklikten hemen sonra diske kalmasını garanti etmesi gerektiğinde açıkça çağrılmalıdır. Anahtarlarda yapılan tüm değişiklikler, diske basılması gerekmeden diğer işlemler tarafından görülebilir.

Alternatif olarak, kayıt defteri, kayıt defteri değişikliklerini düzenli aralıklarla diske basan 'tembel bir temizleme' mekanizmasına sahiptir. Bu düzenli yıkama işlemine ek olarak, kayıt defteri değişiklikleri ayrıca sistem kapatıldığında diske de atılır. 'Tembel yıkama' işleminin kayıt defteri değişikliklerini temizlemesine izin vermek, kayıt defteri yazmalarını diskteki kayıt defteri deposuna yönetmenin en etkili yoludur.

Bu, derhal belirli bir anahtarın diske atılmasından ayrı olarak (bu, sifon tamamlanana kadar herkesi kayıt dışına kilitleyen) kayıt defterinin otomatik olarak düzenli bir şekilde temizlendiğini gösterir: bir süre verilmez, ancak en azından anahtarı yazmakla zor kapatma arasında beklediğiniz süre. Buna ek olarak, daha önce düşündüğünüz gibi kapanma sırasında temizlendi.

Kullanım RegFlushKeydurumunuz için çok önemliyse, söz konusu anahtarı kullanan yazılımdaki işlevi kullanabilir veya derhal bir kayıt defteri anahtarını diske yazmaya zorlamak için ek bir araç oluşturabilirsiniz.

— user914877
kaynak

Hey! Aşağıdaki MSDN makalesine bir bağlantı verirseniz size bunu vereceğim: Windows 8 veya Windows Server 2012'de uygulama kayıt defteri değişikliklerini kaydetme ve kısa bir blok alıntı ekleme. Cevabınız beni tavşan deliğinden aşağıya o makaleye yönlendirdi ve temelde yaptığınız şeyi söylüyor. Çok teşekkürler!

— Shrout1

Fakat bir kullanıcının RegFlushKey'i nasıl arayabileceğini bilen var mı?

— Scott

@Scott Kodda yapılması gerekiyor gibi görünüyor ... Yazıda listelenen MSDN makalesinde bir C ++ örneği var ve başka bir yerde C # ile uygulandığını gördüm. Komut satırından yapılabilir emin değilim.

— Shrout1

@Scott: eğer şok olur sync yaptılar floş diske kayıt. Sadece bir anlam ifade etmiyordu. Neden dosya sistemi önbelleğini temizlemeliyiz ( yapılandırma yöneticisi tarafından kullanılır , tam tersi olmaz), yapılandırma yöneticisinin kendi önbelleğini aniden temizlemelisiniz? Hatta biri varsa, üst seviye önbellek yapısının ne olduğunu bile bilmiyor.

— Mehrdad

@Scott Bir yolu var. API zaten bağlandı. Keyfi Win32 işlevlerini çağırmak için size GUI veren araçlar var. Şey ... Bu bir uygulama detayı. Eğer onu açığa çıkarırsanız, insanlar ona güvenir ve sonra değiştiremezsiniz. Ayrıca, sistem diskinin çıkarılabilir medya için tamamen farklı bir canavar olduğu dikkat çekmektedir. Sistem diski, her zaman açık olması için bir tanıtıcı gerektiren birçok şey için kullanılır (örneğin sayfa dosyası). Windows sistem bölümünün sökülmesini desteklemediğinden, bu "özelliğe" ihtiyaç duymaz. Artı ... yorumları tarafsız tutmaya çalış. Windows’tan nefret ediyorsun, anladık.

— Temel

TL; DR: Bunu doğru zamanda yapmak çok dikkatli .

Üzerindeki belgelerin şunu FSCTL_MARK_AS_SYSTEM_HIVEsöylemesi gerekir:

FSCTL_MARK_AS_SYSTEM_HIVEKontrol kodu Belirtilen dosya dairesinin sistem kovanını içerdiğini dosya sistemini bilgilendirir. Dosya sistemi, kilitlenmeleri önlemek ve veri bütünlüğünü sağlamak için sistem kovanı verilerini tam doğru zamanda diske boşaltmalıdır .

Bundan daha halka açık olan herhangi bir detay olduğuna inanmıyorum.

Ayı akılda su fışkırtma dosya sistemini kızarma anlamına gelmez kayıt defteri üzerinde önbelleğe alma gerçekleştirebilir, çünkü üst dosya sisteminin. Öncelikle kayıt defterini yıkamak için, bir şekilde ilginizi çekmeli NtFlushKeyya ZwFlushKeyda çağrılmanız gerekiyor.

— Mehrdad
kaynak

Ah iyi yakalayış! Bu benim yeni favori MSDN-ism: sadece doğru an . Benim daha önceki favori "UNION, UNION ALL, EXCEPT veya INTERSECT operatör içeren bir sorguda TOP maddesini belirtirken dikkatli olun. Kadar bir sorgu yazmak mümkündür döner beklenmedik sonuçlar " "için bir örtmece olan bu özellik Çok kötü bir şekilde kırıldı ve makul herhangi bir kişinin beklediği şeyi yapmıyor ve düzeltmek yerine belgeleyeceğiz ".

— davidbak

@davidbak: lol, MSDN'nin savunmasında, bir kullanıcının güvenebileceği daha fazla ayrıntıyı sağlayabileceklerini gerçekten göremiyorum.

— Mehrdad

Oh haklısın; Açıkçası bu, Microsoft'un tüm API'leri belgelemesi gereken, ne kadar içlerinde olursa olsun, uzun zaman önce olan AB anlaşmasının bir neşesi olarak belgelenen bir şeydi. Bağlantılı olduğunuz sayfa, "Sadece çekirdek seviyesindeki bileşenler bu dosya sistemi kontrol kodunu kullanabilir" diyor. Yine de, " sadece doğru an " - bir gün bazı API'leri " sadece bu anda sadece doğru zamanda bu yöntemi kullan " şeklinde

— belgeleyip

@davidbak: Bence biraz ... heyecanlısın. :-P Tahminimce bu, dosya sistemi sürücülerinin hangi dosyanın SYSTEM kayıt defteri kovanını içerdiğini bilmesini sağlamak için belgelendirildiği için, bu, o dosyaya aynı anda kayıt defterine bir şey yazmaya çalışmadıkları için önemli olabilir. diske temizlendi. Bununla ilgili hiçbir kanıtım yok; akla gelebilecek bulmamın tek nedeni bu. Bununla ilgili bir şüphem olsa da, neden bir disk sürücüsünün bunu bilmesi gerekmeyeceği de.

— Mehrdad