Когда 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

— Shrout1
источник

msgstr "изменение реестра не появляется после перезагрузки." - Изменение реестра не вступает в силу до перезагрузки, и, как правило, необходимо перезапустить только Проводник. Все зависит от того, как поведет себя изменение реестра, если на самом деле требуется перезагрузка. Фактический ключ изменяется, когда он модифицирован, что отвечает на ваш вопрос.

— Ramhound

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

— DavidPostill

@ Получается, что он не вступает в силу, но почему он не был записан на диск? Я делаю правку, отключаю питание, а потом меня уже нет. Является ли он вступил в силу в памяти не имеет значения в этой точке

— Shrout1

@ Shrout1 - Почему вы заставляете машину выключаться, а не закрываете ее?

— Ramhound

@Ramhound Я запускаю тесты, чтобы посмотреть, что произойдет, если система не будет корректно завершена. Случайно, я знаю, но мне нужно точно знать, как это происходит с памятью, чтобы мы ничего не теряли в наших системах, если это не обрабатывается правильно.

— Shrout1

Ответы:

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

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

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

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

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

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

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

shutdown /s /f /t 0

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

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

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

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

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

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

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

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

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

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

— Мокубай
источник

Спасибо! Я ценю ваш ответ :) Я выключил спящий режим, перезагрузил компьютер и снова запустил тот же тест. Пример 1 имеет тот же результат, без файла гибернации. Похоже, что изменения в реестре записываются только в какой-то момент во время выхода из системы / завершения работы ... Я также согласен с тем, что система может искать «последнее хорошее» состояние при выходе из сломанного режима гибернации - она имеет тенденцию запускать проверки целостности.

— Shrout1

Хммм ... Итак, я загрузил sysinternals "sync", который запускает кэш записи на диск и ничего не делает (все еще терял ключи / значения при жестком отключении). Я также запустил Process Explorer и посмотрел на дисковый ввод-вывод в свойствах для 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 сделал вровень реестр на диск. Это просто не имеет никакого смысла. Почему промывка файловой системы кэша (который используется при менеджере конфигурации, а не наоборот) внезапно вымывать собственный кэш менеджера конфигурационного? Он даже не знает, какова структура высокоуровневого кэша, если он вообще существует.

— Мердад

@ Скотт Есть способ. API уже был связан. Существуют инструменты, которые дают вам графический интерфейс для вызова произвольных функций Win32. Дело в том ... Это деталь реализации. Если вы разоблачаете это, люди полагаются на это, и тогда вы не можете изменить это. Также стоит отметить, что системный диск является совершенно другим зверем по сравнению со съемными носителями. Системный диск используется для многих вещей, для которых требуется всегда открывать дескриптор (например, файл страницы). Windows не поддерживает размонтирование системного раздела, поэтому эта «функция» не нужна. Плюс ... постарайтесь, чтобы комментарии были нейтральными. Ты ненавидишь Windows, мы понимаем это.

— Базовые

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

В документации FSCTL_MARK_AS_SYSTEM_HIVEесть что сказать:

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

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

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

— Mehrdad
источник

О, хороший улов! Это мой новый любимый MSDN-изм: как раз подходящий момент . Моим предыдущим фаворитом было «Будьте осторожны при указании предложения TOP в запросе, который содержит оператор UNION, UNION ALL, EXCEPT или INTERSECT. Можно написать запрос, который возвращает неожиданные результаты », что было эвфемизмом для «эта функция сильно сломлен и не делает то, что ожидал бы любой разумный человек, и вместо того, чтобы исправить это, мы собираемся это задокументировать ».

— Давидбак

@ davidbak: lol, ну, в защиту MSDN, я не очень понимаю, на какие подробности они могли бы предоставить, на что пользователь должен полагаться.

— Мердад

О, ты прав; ясно, что это было просто документально подтверждено как результат давнего урегулирования в ЕС, когда Microsoft должна была документировать все API-интерфейсы - независимо от того, насколько они внутренними. На этой странице, на которую вы ссылаетесь, даже написано «Только компоненты уровня ядра могут использовать этот управляющий код файловой системы», что является серьезным указанием, чтобы держать руки подальше. Тем не менее, «как раз подходящий момент » - однажды я документирую мой API с «вызовом этого метода только в нужный момент » и посмотрю, что произойдет…

— davidbak

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

— Мердад