Коли Windows записує зміни в реєстр на диск?

TL; DR:

Я помітив, що якщо я внесу зміни в реєстр, а потім завершую відключення моєї системи Windows 10, зміна реєстру не з’являється після перезавантаження.

Я також помітив, що видалення файлу сплячки може вплинути на здатність інструмента відновлення Linux вносити зміни до реєстру Windows в офлайн-стані. Інструмент, здається, не в змозі внести стійкі зміни після видалення файла сплячки. Я перерахую конкретні приклади нижче.

Приклад 1:

Я додаю ключ під назвою "1111" у "HKLM \ SOFTWARE". Тоді я сильно вимикаю енергію, тримаючи кнопку живлення протягом 5 секунд.
Коли я повертаю реєстр назад, цей ключ і його значення втрачаються:
(Ці зображення відредаговані для цілей форматування)

Приклад 2 :

Внесіть зміни в реєстр (використовуючи regedit)
Зимує система
Завантажтесь у інструмент відновлення Linux
Видаліть файл сплячки, щоб встановити диск.
Прочитайте реєстр Windows (з інструменту відновлення)
Зміни в реєстрі вже немає.

Це здається еквівалентним жорсткому відключенню на коробці.

Приклад 3:

Я бачу чужу поведінку, коли:

Зимуйте коробкою
Завантажте інструмент відновлення Linux та видаліть файл сплячки
Внесіть зміни до реєстру (з інструменту відновлення)
Перезавантажте поле

Ці зміни також не відображаються в реєстрі.

То що тут відбувається?

Коли Windows 10 записує зміни в реєстр на диск?
Чому видалення файлу сплячки (у прикладі 3) запобігає відображенню змін у реєстрі, зроблених інструментом відновлення, при наступному завантаженні?

Сподіваючись отримати деяке уточнення!

windows-10 windows-registry hibernate

— Плащ1
джерело

"зміна реєстру не з’являється після перезавантаження." - Зміна реєстру не набирає чинності до перезавантаження, і, як правило, потрібно перезапустити лише Провідник файлів. Все залежить від того, якою поведінкою призначена зміна реєстру, якщо насправді потрібна перезавантаження. Дійсний ключ змінюється, коли він модифікується, що відповідає на ваше запитання.

— Рамхаунд

Що ви маєте на увазі під жорстким відключенням? Утримуючи кнопку живлення, поки вона не вимкнеться? Цей процес обходить записування будь-яких записів на кеш диска, що очікують.

— DavidPostill

@Ramhound Я розумію, що це не вступає в силу, але чому він не був записаний на диск? Я вимикаю правки, вимикаю потужне живлення, а потім вже не змінююсь. Чи це

— ввійшло

@ Shrout1 - Чому ви змушуєте машину вимикатись, а не безпечно вимикати машину?

— Рамхаунд

@Ramhound Я запускаю тести, щоб побачити, що станеться, якщо система не вимкнеться граціозно. Випадково, я знаю, але мені потрібно точно знати, як це відбувається в пам'яті, щоб ми нічого не втратили в нашій системі, якщо з нею правильно не працювати.

— Shrout1

Відповіді:

TL; DR: Вимкніть систему належним чином.

Гібернація не має нічого спільного із вимкненням, вона тісно пов’язана із тимчасовим відключенням оперативної пам’яті (сном), за винятком того, що вміст оперативної пам’яті, висунутого на диск, для того, щоб її можна було прочитати назад та відновити роботу з того місця, де система припинилась. .

Якщо ви хочете, щоб зміни зберігалися, вам потрібно вимкнути сплячку та програму Windows Fastboot (яка є підмножиною сплячки). Або ви можете насправді перезавантажити, а не перезимувати та перезапустити.

Причина змін не зберігається в тому, що вони ще не записуються на диск, за винятком файлу сплячки. Що ви видаляєте, це означає, що файлова система, можливо, може сама поправитись і повернутися до стану "останнього відомого хорошого".

Поки система перебуває у сплячому режимі, існує декілька ключових структур файлової системи, які, можливо, не були записані на диск і замість цього знаходяться в оперативній пам'яті. Після відновлення після сплячої системи система очікує, що диск перебуває у дуже певному стані, і можливо, кешові диски та важливі системні файли будуть збережені у файл гібернації, а не на власний диск.

Якщо ви робите належне відключення, то Windows належним чином передасть робочу пам’ять на диск, а потім відключіть диск перед тим, як вимкнути живлення.

Для примусового відключення відкрийте командний рядок і введіть

shutdown /s /f /t 0

/sє "вимкненням", /fпримушувати і /t 0означати "зараз" (час = 0 секунд)

Або ви можете просто відключити швидку завантаження та сплячку.

Детальніше читайте на HowtoGeek: Завершення роботи не завершується повністю Windows 10 (але перезапуск робить)

Що стосується того, що ви робите жорстке відключення, проблема полягає в тому, що Windows не гарантовано записує будь-які зміни на диск тієї ж мілісекунди (або навіть хвилини), яку ви вносите. Вона майже напевно буде написана протягом декількох хвилин, але ймовірність її написання з часом зросте. Навряд чи це буде написано негайно, тоді майже під час внесення змін ймовірність різко зростає і майже напевно буде написана протягом години.

Вся справа в тому, що, примушуючи жорстке відключення, ви не даєте системі можливості безпечно записати зміни на диск.

Більшість сучасних файлових систем написані для внесення змін у найбезпечніший спосіб. Раніше їх називали "атомними", так як у зміні це сталося або не відбулося.

Сьогодні ми знаємо їх як файлові системи Journalled, тому що вони ведуть журнал операцій, які будуть відбуватися, які можуть бути повернені або прокручені вперед у разі відмови системи та перезавантаження. Після запуску з відключення живлення система перевіряє журнал і для кожної транзакції перевіряє, чи фактичні дані файлу записуються на диск і є "хорошими". Якщо це, то транзакція відкочується вперед і завершується, якщо ні, то він повертається до старих даних.

Використовуючи це замовлення, диск майже завжди знаходиться у стані легкого відновлення.

Але несподівано змусивши вашу систему вимкнути живлення, ви не можете гарантувати, що транзакція просунулася досить далеко, щоб просунутись вперед після ремонту, і є ймовірність, що операційна система, така як Linux, не піклуватиметься про історію трансакцій, як Windows. ніж не просто вносити зміни, які повертають все назад, а не вперед.

Якщо ви перезавантажилися в Windows, він може спробувати або мати змогу належним чином відновити диск, оскільки він має більш інтимні знання про файлову систему.

— Мокубай
джерело

Дякую! Я вдячний за вашу відповідь :) Я вимкнув сплячку, перезавантажив і повторно пройшов той же тест. Приклад 1 має той самий результат, жоден файл сплячки не задіяний. Здається, що зміни в реєстрі записуються лише в якийсь момент під час відходу / відключення ... Я також погоджуюся, що система може шукати "останнього доброго" стану, коли прокидається від порушеної сплячки - вона, як правило, запускає перевірки цілісності.

— Shrout1

Гммм ... Отже, я завантажив "синхронізацію" системних сімей, що змушує кеш запису на диск, і це нічого не зробило (все-таки втратили ключі / значення при жорсткому відключенні). Я також запустив провідник процесів і роздивився дисковий введення / вивід у властивостях Regedit. Він читав введення-виведення, але не вводить-виводити не записувати. Це змушує мене думати, що це може чекати відключення ... Чи знаєте ви надто суху документацію M $, яка могла б викласти це просто? Ще раз дякую за всю вашу допомогу !!

— Shrout1

Журнал NTFS не дає гарантій щодо даних файлів. Це просто підтримувати послідовність метаданих NTFS, щоб ви не закінчилися зі зламаною файловою системою . Окремі файли все ще можуть мати часткові зміни, записані до них, порушуючи файл. Існує транзакційний NTFS, але це не рекомендується і дуже рідко використовується. Це також, чому двигуни бази даних ведуть свій власний журнал щодо узгодженості даних. Дивіться також blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

— Боб

@ Shrout1 Це припустимо, що зміни в реєстрі очікують на зберігання в кеш-пам'яті. Цілком можливо, що вони замість них управляються окремо і що це не має нічого спільного з файловою системою, кешування чи іншим чином. Наприклад, остання відома хороша конфігурація оновлюється лише після успішного запуску. (Я не знаю достатньо про внутрішні записи реєстру, щоб бути впевненим, коли зміни будуть збережені. І тоді може бути залучений TxR .)

— Боб

Чи є причина, що ви змушуєте відключити роботу? AFAIK примушує закривати лише запущені програми, що не робить щось інше, ніж знищувати програми, які ви інакше не можете закрити, і, швидше за все, ви втратите десь незбережені зміни, якщо не знаєте, що ви робити або що ви поставили б якусь програму в невідновний стан - я б не назвав це "правильним" відключенням.

— NotThatGuy

Як задокументовано на сторінці MSDN дляRegFlushKey :

Виклик RegFlushKey - це дорога операція, яка суттєво впливає на загальносистемну продуктивність, оскільки вона споживає пропускну здатність диска і блокує модифікації всіх клавіш усіма процесами у вулику реєстру, які видаються до завершення операції змивання. RegFlushKey слід викликати явно лише тоді, коли програма повинна гарантувати, що зміни реєстру зберігаються на диску відразу після модифікації. Усі модифікації клавіш видно для інших процесів без необхідності передавати їх на диск.

Крім того, у реєстрі є механізм "ледачий змив", який регулярно видаляє зміни реєстру на диску. На додаток до цієї регулярної операції промивання, зміни реєстру також видаляються на диск при відключенні системи. Дозвіл на "ледачий флеш" для внесення змін у реєстр є найефективнішим способом керування записами реєстру в магазині реєстру на диску.

Це говорить про те, що, крім того, що мить певний ключ на диску негайно (який блокує всіх інших із реєстру, поки флеш не буде завершений), реєстр періодично змивається: час не задається, але, мабуть, він принаймні більше, ніж час, який ви чекали між написанням ключа та жорстким відключенням. Крім того, він вимивається при відключенні, як ви вже зрозуміли.

Ви можете використовувати цю RegFlushKeyфункцію в програмному забезпеченні, яке маніпулює вказаним ключем, або створити з ним додатковий інструмент, щоб змусити негайно записати ключ реєстру на диск, якщо це важливо для вашого випадку використання.

— user914877
джерело

Гей! Я дам вам це, якщо ви перейдете посилання на таку статтю MSDN: Збереження змін у реєстрі додатків на Windows 8 або Windows Server 2012 та додайте короткий блок-цитат. Ваша відповідь привела мене до кролячої нори до тієї статті, і це в основному говорить те саме, що ви зробили. Дякую багато!

— Shrout1

Але хтось знає, як користувач може викликати RegFlushKey ?

— Скотт

@Scott Здається, що це потрібно робити в коді ... Стаття MSDN, зазначена в публікації, має приклад C ++, і я бачив, що вона реалізована в C # в інших місцях. Не впевнений, що це можна зробити з командного рядка.

— Shrout1

@Scott: Я був би шокований , якщо sync зробив врівень реєстр на диск. Це просто не мало б сенсу. Чому промивка файлової системи кеш (який використовується при менеджері конфігурації, а не навпаки) раптово вимивати власний кеш менеджера конфігураційного? Він навіть не знає, яка структура кешу вищого рівня, якщо такий взагалі існує.

— Мехрдад

@Scott Є спосіб. API вже пов’язаний. Існують інструменти, які дають вам графічний інтерфейс для виклику довільних функцій Win32. Річ у тому, що ... Це деталь реалізації. Якщо ви виставляєте його, люди покладаються на нього, і тоді ви не можете його змінити. Також варто відзначити, що системний диск - це зовсім інший звір для знімних носіїв. Системний диск використовується для багатьох речей, для яких потрібно завжди відкривати ручку (наприклад, файл сторінки). Windows не підтримує відключення системного розділу, тому немає необхідності в цій "функції". Плюс ... спробуйте зберегти коментарі нейтральними. Ви ненавидите Windows, ми це отримуємо.

— Основний

TL; DR: Дуже обережно це робити в потрібний момент .

У документації на FSCTL_MARK_AS_SYSTEM_HIVEце сказано:

Код FSCTL_MARK_AS_SYSTEM_HIVEуправління повідомляє файлову систему про те, що вказаний файл містить системний вулик реєстру. Файлова система повинна видалити дані системи вулика на диск у потрібний момент, щоб уникнути тупикових ситуацій та забезпечити цілісність даних.

Я не вірю, що публічно доступна більш детальна інформація, ніж ця.

Майте на увазі, що промивання файлової системи не означає промивання реєстру , оскільки реєстр може виконувати кешування поверх файлової системи. Щоб спочатку залишити реєстр, вам потрібно якось викликати NtFlushKeyабо ZwFlushKeyвикликати за вашим ключовим кодом.

— Мехрдад
джерело

О гарний улов! Оце мій новий улюблений MSDN-ism: саме підходящий момент . Мій попередній улюблений був "Будьте обережні, вказуючи пункт TOP у запиті, що містить оператор UNION, UNION ALL, EXCEPT або INTERSECT. Можна написати запит, який повертає несподівані результати ", що було евфемізмом для "цієї функції є сильно зламаний і не робить того, чого очікував би будь-який розумний чоловік, і замість того, щоб виправляти це, ми збираємось документувати це ".

— davidbak

@davidbak: хай, добре, на захист MSDN, я насправді не бачу, які деталі вони могли б надати, щоб користувач повинен покластися.

— Мехрдад

Ой ти правий; Очевидно, що це було лише щось задокументоване як наслідки давнього врегулювання ЄС, де Microsoft вимагала документувати всі API-інтерфейси - незалежно від того, наскільки вони внутрішні. На цій сторінці, на яку ви пов’язані, навіть написано "Тільки компоненти рівня ядра можуть використовувати цей код управління файловою системою", що є важливим підказом, щоб не тримати руки. І все-таки " просто потрібний момент " - одного дня я задокументую деякий мій API з "зателефонуйте цьому методу лише в потрібний момент " і подивіться, що станеться ....

— davidbak

@davidbak: Я думаю, ти трохи ... схвильований. :-P Я гадаю , що це було задокументовано для того, щоб водії файлової системи знали, який файл містить вулик реєстру SYSTEM, що може бути важливо тим, що вони не намагалися б написати щось до реєстру одночасно з цим файлом зливається на диск. Я не маю доказів цього, хоча; це лише одна причина, яку я вважаю можливою. Я маю сумніви щодо цього, чому драйвер диска теж не повинен знати про це.

— Мехрдад