43

TL; DR:

Я заметил, что если я внесу изменения в реестр, а затем произвожу жесткое завершение работы системы Windows 10, изменение реестра не появится после перезагрузки.

Я также заметил, что удаление файла гибернации может повлиять на способность инструмента восстановления Linux вносить изменения в реестр Windows в автономном режиме. Похоже, инструмент не может вносить постоянные изменения после удаления файла гибернации. Ниже я приведу конкретные примеры.

Пример 1:

  • Я добавляю ключ с именем "1111" в «HKLM \SOFTWARE». Затем я отключаю питание, удерживая кнопку питания в течение 5 секунд.
  • Тестовый ключ
  • Когда я восстановлю реестр, этот ключ и его значения исчезнут:
  • Тестовый ключ ушел
  • (Эти изображения были отредактированы для форматирования)

Пример 2:

  • Внести изменения в реестр (используя regedit)
  • Спящий система
  • Загрузитесь в инструмент восстановления Linux
  • Удалите файл гибернации, чтобы смонтировать диск.
  • Прочитайте реестр Windows (из инструмента восстановления)
  • Изменение реестра исчезло.

Это похоже на жесткое отключение на коробке.

Пример 3:

Я вижу странное поведение, когда я:

  • Спящий ящик
  • Загрузитесь с помощью инструмента восстановления Linux и удалите файл гибернации
  • Внести изменения в реестр (из инструмента восстановления)
  • Перезагрузите коробку

Эти изменения также не отражаются в реестре.

Так что здесь происходит?

  • Когда Windows 10 записывает изменения реестра на диск?
  • Почему удаление файла гибернации (в примере 3) не позволяет отражать изменения реестра, сделанные с помощью инструмента восстановления, при следующей загрузке?

Надеюсь получить разъяснения!

3 ответа3

54

TL; DR: правильно выключить вашу систему.


Спящий режим не имеет ничего общего с выключением, он тесно связан с режимом приостановки в ОЗУ (спящий режим), за исключением того, что содержимое ОЗУ передается на диск для его считывания и возобновления работы именно с того места, где система остановилась. ,

Если вы хотите, чтобы изменения сохранялись, вам нужно отключить спящий режим и быструю загрузку Windows (которая является подмножеством спящего режима). Или вы можете перезагрузить компьютер, а не перевести его в спящий режим и перезагрузить.

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

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

Если вы сделаете правильное завершение работы, Windows должным образом сбросит рабочую память на диск, а затем аккуратно размонтирует диск перед выключением.

Чтобы принудительно завершить работу, откройте командную строку и введите

shutdown /s /f /t 0

/s означает "выключение", /f - принудительно, а /t 0 означает "сейчас" (время = 0 секунд)

Или вы можете просто отключить fastboot и гибернацию.

Узнайте больше на HowtoGeek: Завершение работы не полностью завершает работу Windows 10 (но перезапуск делает)


Проблема, связанная с тем, что вы выполняете принудительное завершение работы, заключается в том, что Windows не гарантирует запись каких-либо изменений на диск в ту же миллисекунду (или даже минуту), в которую вы вносите это изменение. Оно почти наверняка будет написано в течение нескольких минут, но вероятность того, что оно будет действительно написано, со временем возрастет. Это вряд ли будет написано сразу, то близко к тому времени , как вы сделаете изменения увеличивается вероятность резко, и почти наверняка было написано в течение часа.

Дело в том, что принудительное отключение не дает системе возможности безопасно записать изменения на диск.

Большинство современных файловых систем написаны для внесения изменений наиболее безопасным способом. В прошлом их называли "атомными", так как изменения произошли или не произошли.

Сегодня мы знаем их как файловые системы Journalled, потому что они хранят журнал операций, которые могут произойти, которые могут быть либо отменены, либо перенесены вперед в случае сбоя системы и перезагрузки. При запуске из-за сбоя питания система проверяет журнал и для каждой транзакции проверяет, записаны ли фактические данные файла на диск и является ли он "хорошим". Если это так, то переход откатывается вперед и завершается, если нет, то выполняется откат к старым данным.

Используя этот порядок, диск почти всегда находится в состоянии легкого ремонта.

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

Если вы перезагружаетесь в Windows, он может попытаться или сможет восстановить диск должным образом, так как он более глубоко знаком с файловой системой.

39

Как описано на странице MSDN для RegFlushKey:

Вызов RegFlushKey - это дорогостоящая операция, которая существенно влияет на производительность всей системы, поскольку она потребляет пропускную способность диска и блокирует изменения всех ключей всеми процессами в кусте реестра, который сбрасывается до завершения операции сброса. RegFlushKey следует вызывать только в том случае, если приложение должно гарантировать, что изменения реестра будут сохранены на диске сразу после внесения изменений. Все изменения, внесенные в ключи, видны другим процессам без необходимости их сброса на диск.

Кроме того, в реестре есть механизм «отложенной очистки», который сбрасывает изменения реестра на диск через регулярные промежутки времени. В дополнение к этой обычной операции сброса, изменения реестра также сбрасываются на диск при завершении работы системы. Разрешение «отложенной очистки» для сброса изменений в реестре является наиболее эффективным способом управления записями реестра в хранилище реестра на диске.

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

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

14

TL; DR: очень осторожно делать это в нужный момент.

В документации по FSCTL_MARK_AS_SYSTEM_HIVE сказано следующее:

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

Я не верю, что есть больше деталей, доступных публично, чем эта.

Имейте в виду, что очистка файловой системы не подразумевает очистку реестра, поскольку реестр может выполнять кэширование поверх файловой системы. Чтобы сначала очистить реестр, вам нужно как-то вызвать NtFlushKey или ZwFlushKey для вашего ключа интереса.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .