BitLocker просит ключ при каждом запуске: как найти причину повторного восстановления

Один запрос и восстановление при каждом старте — разные ситуации

После обновления прошивки компьютер один раз попросил ключ BitLocker, затем стал запускаться нормально. Иной случай — правильный ключ подходит, но запрос возвращается при каждом включении. Здесь важно найти повторяющееся изменение условий загрузки, а не просто ещё раз сохранить пароль.

BitLocker связывает доступ к зашифрованному системному тому с настроенными средствами защиты ключа. При использовании TPM проверяются измерения загрузки. Изменение загрузочных компонентов или настроек может привести к восстановлению, даже если файлы пользователя исправны. ^{[1], [2]}

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

Проверьте ключ и не смешивайте разные тома

Сверьте идентификатор на экране восстановления с сохранённой записью. Для системного тома, другого диска и старого устройства ключи могут различаться. Идентификатор помогает выбрать запись, но сам не заменяет 48-значный ключ.

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

После входа проверьте, к какому тому относится проблема. Внешний диск с запросом при открытии Проводника и системный диск с запросом до входа — разные сценарии.

Посмотрите состояние, прежде чем что-либо отключать

В повышенной командной строке выполните:

manage-bde -status C:

Убедитесь, что C — нужный системный том. Запишите Conversion Status, Percentage Encrypted, Protection Status и Lock Status. Зашифрованный том может быть разблокирован для текущей работы; это не противоречие. И приостановленная защита не означает, что данные уже расшифрованы. ^[3]

В среде PowerShell с доступным модулем BitLocker можно вывести только типы и идентификаторы защитников:

(Get-BitLockerVolume -MountPoint 'C:').KeyProtector |
  Select-Object KeyProtectorType, KeyProtectorId

Здесь намеренно не выбирается поле с паролем восстановления. Набор возможностей и интерфейс зависят от редакции Windows и того, используется ли полное управление BitLocker или «Шифрование устройства». Отсутствие модуля не является доказательством отсутствия шифрования. ^[4]

Составьте журнал изменений загрузки

Запишите последний нормальный запуск и всё, что изменилось перед первым запросом: обновление BIOS/UEFI, замена платы, клонирование диска, изменение Secure Boot, порядка загрузки или настроек TPM. Отдельно отметьте подключённые загрузочные флешки и сетевую загрузку.

Проверьте, запускается ли нужный Windows Boot Manager именно с системного накопителя. Если путь каждый раз меняется из-за старого диска, USB или PXE, повторное введение ключа не устраняет источник расхождения.

В новых вариантах экрана BitLocker могут показываться дополнительные сведения о причине восстановления. Используйте их вместе с журналами и конфигурацией. Перечень причин, связанных с BCD, TPM и Secure Boot, опубликован Microsoft. ^[2]

Проверьте журналы, не предполагая один номер события

В Просмотре событий найдите доступные журналы BitLocker и записи рядом с восстановлением. Сохраните время, сообщение и сведения о причине без самого ключа. Список журналов можно получить так:

Get-WinEvent -ListLog '*BitLocker*' |
  Select-Object LogName, IsEnabled, RecordCount

Имена и доступность журналов зависят от версии и настроек. Затем откройте реально найденный журнал и ограничьте интервал нужным запуском. Не переносите произвольный Event ID из случая другой версии Windows.

Цель — связать сообщение с конкретным изменением. Если отмечено изменение загрузочного файла, проверьте его происхождение. Если TPM отсутствует или отключён, сначала разберитесь с его состоянием в документации устройства. Очистка TPM удаляет доверенные данные и не является обычным способом прекратить запросы.

Отдельный случай: сетевой запуск перед локальным

В актуальном руководстве Microsoft по Secure Boot описан повторный запрос после обновлений, когда PXE стоит перед локальным Windows Boot Manager. Попытка сетевой загрузки и последующий переход к диску могут использовать разные цепочки подписи, из-за чего измерения не стабилизируются. ^[5]

Проверьте фактический порядок загрузки. Для личного компьютера без необходимости PXE правильным действием может стать выбор локального менеджера первым. На управляемом устройстве сетевой запуск может быть нужен: тогда конфигурацию меняют вместе с администратором и обслуживанием инфраструктуры.

Это конкретная возможная причина, а не объяснение любого запроса BitLocker. Не меняйте параметры Secure Boot только потому, что в журнале упомянут TPM.

Когда допустимы приостановка и повторное включение

После того как установлено легитимное изменение и проверен ключ восстановления, Microsoft предусматривает приостановку и возобновление защиты для обновления доверенной конфигурации. ^{[1], [6]} Пока защита приостановлена, ключ доступен системе упрощённым способом; это временно снижает защиту при физическом доступе. Сам том при этом не расшифровывается.

Пример для обслуживаемого системного тома с возобновлением после одного перезапуска:

manage-bde -protectors -disable C: -RebootCount 1

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

manage-bde -protectors -enable C:
manage-bde -status C:

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

Проверьте устойчивость после возвращения защиты

Повторите обычный перезапуск и выключение с последующим включением. Для ноутбука проверьте привычное подключение док-станции и устройств, если именно при нём возникал запрос. Сравнивайте неизменную конфигурацию, затем добавляйте один фактор.

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

Рабочий результат — нормальный запуск в ожидаемой конфигурации при включённой защите. Отсутствие запроса потому, что защита забыта в состоянии Suspended, таким результатом не считается.