Kapan Windows menulis perubahan registri ke disk?

TL; DR:

Saya perhatikan bahwa jika saya membuat perubahan registri dan kemudian mematikan sistem Windows 10 saya, perubahan registri tidak muncul setelah reboot.

Saya juga memperhatikan bahwa penghapusan file hibernasi dapat memengaruhi kemampuan alat pemulihan Linux untuk membuat perubahan pada registri Windows dalam keadaan offline. Alat ini tampaknya tidak dapat membuat perubahan terus-menerus setelah penghapusan file hibernasi. Saya akan mencantumkan contoh spesifik di bawah ini.

Contoh 1:

Saya menambahkan kunci yang disebut "1111" ke dalam "HKLM \ SOFTWARE". Saya kemudian mematikan kotak saya dengan menekan tombol power selama 5 detik.
Ketika saya menarik kembali registri, kunci itu dan nilainya hilang:
(Gambar-gambar ini diedit untuk keperluan format)

Contoh 2 :

Buat perubahan di registri (menggunakan regedit)
Hibernasi sistem
Boot ke alat pemulihan Linux
Hapus file hibernasi untuk memasang disk.
Baca registri windows (dari alat pemulihan)
Perubahan registri hilang.

Ini sepertinya sama dengan shutdown keras pada kotak.

Contoh 3:

Saya melihat perilaku orang asing ketika saya:

Hibernate the box
Boot ke alat pemulihan Linux dan hapus file hibernasi
Buat perubahan pada registri (dari alat pemulihan)
Nyalakan ulang kotaknya

Perubahan-perubahan itu juga tidak tercermin dalam registri.

Jadi apa yang terjadi di sini?

Kapan Windows 10 menulis perubahan registri ke disk?
Mengapa penghapusan file hibernasi (dalam Contoh 3) mencegah perubahan registri yang dibuat dari alat pemulihan agar tidak tercermin pada boot berikutnya?

Berharap mendapatkan klarifikasi!

windows-10 windows-registry hibernate

— Shrout1
sumber

"Perubahan registri tidak muncul setelah reboot." - Perubahan registri tidak berlaku hingga reboot, dan biasanya, hanya File Explorer yang harus dimulai ulang. Itu semua tergantung pada perilaku apa yang ingin dilakukan perubahan registri jika reboot benar-benar diperlukan. Kunci aktual diubah, ketika dimodifikasi, yang menjawab pertanyaan Anda.

— Ramhound

Apa yang Anda maksud dengan shutdown yang sulit? Menahan tombol daya hingga mati? Proses tersebut mem-bypass penulisan cache disk yang tertunda.

— DavidPostill

@Ramhound Saya mengerti bahwa itu tidak berlaku, tetapi mengapa belum ditulis ke disk? Saya melakukan pengeditan, mematikan daya dan kemudian mengubah tidak ada lagi. Apakah itu berlaku atau tidak dalam memori tidak masalah pada saat itu

— Shrout1

@ Shrout1 - Mengapa Anda memaksa mesin untuk mematikan, bukannya mematikan mesin dengan aman?

— Ramhound

@Ramhound Saya menjalankan tes untuk melihat apa yang terjadi jika sistem tidak dimatikan dengan anggun. Acak, saya tahu, tapi saya perlu tahu persis bagaimana ini dilakukan ke memori sehingga kami tidak kehilangan apa pun di sistem kami jika tidak ditangani dengan benar.

— Shrout1

Jawaban:

TL; DR: Matikan sistem Anda dengan benar.

Hibernasi tidak ada hubungannya dengan mematikan, itu terkait erat dengan suspend-to-RAM (tidur) kecuali dengan isi RAM yang didorong ke disk agar dapat dibaca kembali dan operasi dilanjutkan dari tempat sistem tidak aktif .

Jika Anda ingin perubahan tetap ada maka Anda harus menonaktifkan hibernasi dan Windows Fastboot (yang merupakan subset dari hibernasi). Atau Anda benar-benar dapat reboot daripada hibernate dan restart.

Alasan perubahan tidak bertahan adalah karena mereka belum ditulis ke disk kecuali dalam file hibernasi. Yang Anda hapus, artinya sistem file mungkin harus memperbaiki dirinya sendiri dan kembali ke keadaan "terakhir yang dikenal baik".

Sementara sistem di-hibernasi, akan ada beberapa struktur sistem file utama yang mungkin belum ditulis ke disk dan malah di RAM. Sistem akan, setelah melanjutkan dari hibernasi, mengharapkan disk berada dalam keadaan yang sangat khusus dan ada kemungkinan bahwa cache disk dan file sistem penting disimpan ke file hibernasi daripada ke disk sebenarnya.

Jika Anda melakukan shutdown yang benar maka Windows akan mem-flush memori yang berfungsi dengan baik ke disk, dan kemudian melepas disk dengan bersih sebelum mematikannya.

Untuk memaksa shutdown yang benar, buka prompt perintah dan ketik

shutdown /s /f /t 0

/sadalah "shutdown", /funtuk memaksa, dan /t 0berarti "sekarang" (waktu = 0 detik)

Atau Anda bisa menonaktifkan fastboot dan hibernasi.

Baca lebih lanjut di HowtoGeek: Mematikan Tidak sepenuhnya Mematikan Windows 10 (Tapi Memulai Lagi)

Terkait dengan Anda melakukan shutdown keras masalahnya ada bahwa Windows tidak dijamin untuk menulis perubahan ke disk milidetik yang sama (atau bahkan menit) yang Anda lakukan perubahan. Itu hampir pasti akan ditulis dalam beberapa menit tetapi kemungkinan itu sebenarnya telah ditulis akan meningkat dari waktu ke waktu. Ini tidak mungkin ditulis segera, kemudian mendekati waktu Anda membuat perubahan, probabilitas meningkat tajam, dan hampir pasti akan ditulis dalam waktu satu jam.

Masalahnya adalah, dengan memaksa hard shutdown Anda tidak memberikan sistem kesempatan untuk menulis perubahan ke disk dengan aman.

Sebagian besar sistem file modern ditulis untuk membuat perubahan dengan cara yang paling aman. Di masa lalu mereka telah disebut sebagai "atom", seperti dalam perubahan yang terjadi atau tidak.

Hari ini kita mengenal mereka sebagai sistem file Journal karena mereka menyimpan log operasi yang akan terjadi yang dapat dikembalikan atau digulung ke depan jika terjadi kegagalan sistem dan reboot. Setelah memulai dari kegagalan daya, sistem memeriksa jurnal dan untuk setiap transaksi memeriksa apakah data file aktual ditulis ke disk dan "baik". Jika sudah maka transasi bergulir ke depan dan selesai, jika tidak maka gulungan kembali ke data lama.

Dengan menggunakan urutan ini, disk hampir selalu dalam kondisi mudah diperbaiki.

Tetapi dengan memaksa sistem Anda untuk mematikan secara tiba-tiba Anda tidak dapat menjamin apakah transaksi telah berkembang cukup jauh untuk maju setelah perbaikan, dan kemungkinan bahwa sistem operasi seperti Linux tidak akan terlalu peduli seperti Windows tentang sejarah transaksi dan lebih mungkin terjadi daripada tidak hanya membuat perubahan yang memutar semuanya ke belakang daripada ke depan.

Jika Anda reboot ke Windows, ia mungkin mencoba atau memperbaiki disk dengan benar karena memiliki pengetahuan yang lebih mendalam tentang sistem file.

— Mokubai
sumber

Terima kasih! Saya menghargai respons Anda :) Saya mematikan hibernasi, reboot dan menjalankan kembali tes yang sama. Contoh 1 memiliki hasil yang sama, tidak ada file hibernasi yang terlibat. Tampaknya perubahan registri hanya ditulis di beberapa titik selama logoff / shutdown ... Saya juga setuju bahwa sistem mungkin mencari kondisi "terakhir yang baik" ketika bangun dari hibernasi yang rusak - cenderung menjalankan pemeriksaan integritas.

— Shrout1

Hmmm ... Jadi saya mengunduh sysinternals "sync" yang memaksa cache tulis ke disk dan itu tidak melakukan apa-apa (masih kehilangan kunci / nilai saat hard shut off). Saya juga menjalankan proses explorer dan melihat Disk I / O di properti untuk Regedit. Sudah membaca I / O tetapi tidak menulis I / O. Ini membuat saya berpikir bahwa itu mungkin menunggu penutupan ... Apakah Anda tahu ada dokumentasi $ M yang sangat kering yang dapat menjelaskannya dengan jelas? Sekali lagi terima kasih atas semua bantuan Anda !!

— Shrout1

Jurnal NTFS tidak memberikan jaminan tentang data file. Ini hanya untuk menjaga agar metadata NTFS tetap konsisten, sehingga Anda tidak berakhir dengan sistem file yang rusak . File individual masih dapat memiliki perubahan parsial yang direkam untuk mereka, memecahkan file. Ada Transaksional NTFS tetapi itu tidak dianjurkan dan sangat jarang digunakan. Ini juga mengapa mesin database menyimpan jurnal mereka sendiri untuk konsistensi data. Lihat juga blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

— Bob

@ Shrout1 Itu dengan asumsi perubahan registri tertunda dalam cache tulis-kembali. Sangat mungkin bahwa mereka dikelola secara terpisah dan bahwa ini tidak ada hubungannya dengan sistem file, caching atau sebaliknya. Sebagai contoh, Konfigurasi Baik Yang Terakhir Diketahui hanya diperbarui pada startup yang berhasil. (Saya tidak cukup tahu tentang internal registri untuk memastikan kapan perubahan disimpan. Dan kemudian TxR mungkin terlibat.)

— Bob

Apakah ada alasan Anda memaksa shutdown? AFAIK yang hanya memaksa menjalankan aplikasi untuk ditutup, yang tidak melakukan banyak hal selain membunuh aplikasi yang tidak bisa Anda tutup dan membuatnya lebih mungkin bahwa Anda akan kehilangan beberapa perubahan yang belum disimpan di suatu tempat jika Anda tidak tahu apa yang Anda lakukan melakukan atau Anda akan menempatkan beberapa aplikasi dalam keadaan tidak dapat dipulihkan - saya tidak akan benar-benar menyebut itu shutdown yang "tepat".

— NotThatGuy

Seperti yang didokumentasikan pada halaman MSDN untukRegFlushKey :

Memanggil RegFlushKey adalah operasi mahal yang secara signifikan mempengaruhi kinerja seluruh sistem karena mengkonsumsi bandwidth disk dan memblokir modifikasi untuk semua kunci oleh semua proses dalam kumpulan registri yang sedang disiram sampai operasi siram selesai. RegFlushKey hanya boleh dipanggil secara eksplisit ketika aplikasi harus menjamin bahwa perubahan registri tetap ada pada disk segera setelah modifikasi. Semua modifikasi yang dilakukan pada kunci dapat dilihat oleh proses lain tanpa perlu membilasnya ke disk.

Atau, registri memiliki mekanisme 'lazy flush' yang mem-flush modifikasi registri ke disk secara berkala. Selain operasi flush biasa ini, perubahan registri juga dibilas ke disk saat sistem mati. Mengizinkan 'flush malas' untuk membersihkan perubahan registri adalah cara paling efisien untuk mengelola penulisan registri ke toko registri pada disk.

Hal ini menunjukkan bahwa selain membersihkan kunci tertentu ke disk segera (yang mengunci semua orang keluar dari registri hingga flush selesai), registri secara otomatis memerah secara berkala: waktu tidak diberikan, tetapi mungkin setidaknya lebih dari waktu Anda menunggu antara menulis kunci dan mematikan keras. Selain itu, memerah saat shutdown, karena Anda sudah tahu.

Anda dapat menggunakan RegFlushKeyfungsi dalam perangkat lunak yang memanipulasi kata kunci, atau membuat alat tambahan dengan itu untuk memaksa menulis kunci registri ke disk segera, jika ini penting untuk kasus penggunaan Anda.

— pengguna914877
sumber

Hei! Saya akan memberi Anda yang ini jika Anda melempar tautan ke artikel MSDN berikut: Menyimpan perubahan registri aplikasi pada Windows 8 atau Windows Server 2012 dan menambahkan blockquote singkat. Jawaban Anda membawa saya ke lubang kelinci ke artikel itu dan pada dasarnya mengatakan hal yang sama Anda lakukan. Terima kasih banyak!

— Shrout1

Tetapi apakah ada yang tahu bagaimana pengguna dapat memanggil RegFlushKey ?

— Scott

@Scott Tampaknya harus dilakukan dalam kode ... Artikel MSDN yang tercantum dalam posting memiliki contoh C ++ dan saya telah melihatnya diimplementasikan dalam C # di tempat lain. Tidak yakin itu bisa dilakukan dari baris perintah.

— Shrout1

@Scott: Saya akan terkejut jika sync melakukan flush registri ke disk. Itu tidak masuk akal. Mengapa harus membilas cache sistem file (yang digunakan oleh manajer konfigurasi, bukan sebaliknya) tiba-tiba membersihkan cache manajer konfigurasi itu sendiri? Ia bahkan tidak tahu apa struktur cache level yang lebih tinggi, jika bahkan ada.

— Mehrdad

@ Esc Ada cara. API telah ditautkan. Ada alat di luar sana yang memberi Anda GUI untuk memanggil fungsi Win32 sewenang-wenang. Masalahnya ... Ini adalah detail implementasi. Jika Anda mengeksposnya, orang-orang mengandalkannya dan kemudian Anda tidak dapat mengubahnya. Juga perlu dicatat bahwa disk sistem adalah binatang yang sama sekali berbeda dengan media yang dapat dilepas. Disk sistem digunakan untuk banyak hal yang memerlukan pegangan agar selalu terbuka (misalnya file halaman). Windows tidak mendukung unmount partisi sistem, jadi tidak perlu untuk "fitur" ini. Plus ... coba jaga komentar tetap netral. Anda membenci Windows, kami mengerti.

— Dasar

TL; DR: Hal ini sangat berhati-hati untuk melakukan hal ini pada saat yang tepat .

Dokumentasi pada FSCTL_MARK_AS_SYSTEM_HIVEmengatakan ini:

The FSCTL_MARK_AS_SYSTEM_HIVEkode kontrol menginformasikan sistem file yang file yang ditentukan berisi sistem registri sarang. Sistem file harus membilas data sarang sistem ke disk pada saat yang tepat untuk menghindari kebuntuan dan untuk memastikan integritas data.

Saya tidak percaya ada detail lebih banyak tersedia untuk umum daripada ini.

Ingatlah bahwa pembilasan sistem file tidak berarti pembilasan registri , karena registri dapat melakukan caching di atas sistem file. Untuk membersihkan registri terlebih dahulu, Anda harus entah bagaimana menyebabkan NtFlushKeyatau ZwFlushKeydipanggil pada kunci minat Anda.

— Mehrdad
sumber

Oh, tangkapan yang bagus! Itulah MSDN-isme favorit saya yang baru: saat yang tepat . Favorit saya sebelumnya adalah "Berhati-hatilah saat menentukan klausa TOP dalam kueri yang berisi operator UNION, UNION ALL, EXCEPT, atau INTERSECT. Dimungkinkan untuk menulis kueri yang mengembalikan hasil yang tidak terduga " yang merupakan eufemisme untuk "fitur ini adalah rusak parah dan tidak melakukan apa yang diharapkan orang masuk akal dan bukannya memperbaikinya kita akan mendokumentasikannya ".

— davidbak

@davidbak: lol, yah di pertahanan MSDN, saya tidak benar-benar melihat detail apa lagi yang bisa mereka sediakan yang harus diandalkan pengguna.

— Mehrdad

Oh kamu benar; jelas ini hanya sesuatu yang didokumentasikan sebagai dampak dari penyelesaian Uni Eropa yang lama di mana Microsoft diminta untuk mendokumentasikan semua API - tidak peduli seberapa dalam mereka. Halaman ini yang Anda tautkan bahkan mengatakan "Hanya komponen tingkat kernel yang dapat menggunakan kode kontrol sistem file ini" yang merupakan petunjuk kuat untuk menjaga tangan Anda. Namun, " saat yang tepat " - suatu hari saya akan mendokumentasikan beberapa API saya dengan "panggil metode ini hanya pada saat yang tepat " dan lihat apa yang terjadi ....

— davidbak

@davidbak: Saya pikir Anda sedikit ... bersemangat. :-P Dugaan saya adalah bahwa ini didokumentasikan untuk memberi tahu pengandar sistem file tahu file apa yang mengandung sarang registri SISTEM, yang mungkin penting karena mereka tidak akan mencoba menulis apa pun ke registri pada saat yang sama bahwa file tersebut sedang memerah ke disk. Saya tidak punya bukti tentang ini; itu hanya salah satu alasan yang menurut saya masuk akal. Satu keraguan yang saya miliki tentang itu, mengapa driver disk tidak perlu mengetahui hal ini juga.

— Mehrdad