Это мой второй вопрос, касающийся моего случая без загрузки Windows 10, но с другим фокусом на этот раз. Как напоминание:
Так как что-то (TM) произошло вчера с моим ноутбуком (Dell Latitude E6440) (я подозреваю, что Центр обновления Windows, но кто знает), моя установка Windows 10 Pro (17134.1, если это имеет значение) больше не загружается. По сути, во время загрузки я бесконечно видел только логотип Dell, и больше ничего не происходило, кроме начальной активности жесткого диска.
Я исключил диспетчер загрузки Windows как основную причину, не в последнюю очередь установив ту же версию Windows 10 на второй раздел, управляемый тем же менеджером загрузки EFI. [Кажется, нет способа обновить / установить на месте поверх существующей, не загружающейся установки Windows и сохранить установленные приложения, так что это не мое предпочтительное решение. Я бы хотел починить сломанный.] Меню загрузки прекрасно работает со всеми настроенными параметрами, просто я не могу загрузить одну из двух установок Windows. Несмотря на соответствующую конфигурацию BCD, файл журнала %WINDIR%\Ntbtlog.txt не записывается, поэтому я подозреваю, что последовательность загрузки завершается сбоем очень рано (то есть даже до загрузки ntoskrnl.exe ). Я подумал , что , может быть, Windows Boot Loader этой установки была нарушена.
Поэтому я начал искать различия между соответствующими файлами. Я убедился, что BCD выглядит одинаково, за исключением дополнительных параметров ведения журнала и отладки:
Windows Boot Loader
-------------------
identifier {the-working-one}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {uid1}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
flightsigning Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {uid2}
nx OptIn
bootmenupolicy Standard
Windows Boot Loader
-------------------
identifier {non-working-one}
device partition=D:
path \Windows\system32\winload.efi
description Windows 10-1
locale en-US
inherit {bootloadersettings}
recoverysequence {uid3}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
flightsigning Yes
allowedinmemorysettings 0x15000075
osdevice partition=D:
systemroot \Windows
nx OptIn
bootmenupolicy Standard
bootstatuspolicy DisplayAllFailures
bootlog Yes
sos Yes
Затем я продолжил сравнивать файлы, которые, как я подозреваю, как-то связаны с загрузкой, но все, что я до сих пор тестировал, тоже идентично:
C:\Windows\Boot\* == D:\Windows\Boot\* (recursive)
C:\Windows\System32\*boot*.* == D:\Windows\System32\*boot*.*
C:\Windows\System32\*bcd*.* == D:\Windows\System32\*bcd*.*
C:\Windows\System32\*winload*.* == D:\Windows\System32\*winload.*
C:\Windows\System32\Boot\* == D:\Windows\System32\Boot\* (recursive)
Что мне не хватает? Какие другие важные компоненты загрузки Windows 10 я могу сравнить? Есть ли другой способ изолировать соответствующие различия между двумя установками, которые могли бы позволить мне скопировать часть из рабочего в нерабочий?
Две дополнительные части информации, которые могут помочь указать в правильном направлении:
Во время восстановления только с нерабочей установкой Windows, «bootrec /fixboot» также завершился с "Доступ запрещен", но я не мог выяснить, какой доступ был запрещен. Я не очень хочу попробовать эту команду сейчас, не зная, что именно она делает.
D:\Windows\System32\LogFiles\Srt\SrtTrail.txt(файл журнала для восстановления при запуске, также запускается во время восстановления Windows) содержит эту строку;
Загрузочный критический файл d:\efi\microsoft\boot\resources\custom\bootres.dll поврежден.
Я понятия не имею, почему может потребоваться пользовательский bootres.dll, у меня его нигде нет. Где это может быть зарегистрировано? Интересно, что единственное место, где я могу найти часть этого сообщения об ошибке, - это два потока, которые относятся к обновлению 17133.73 (я полагаю, из 17133.1). Я действительно установил это обновление (успешно) после того, как установил чистую 17133.1, но насколько я могу судить, последующее чистое обновление до 17134.1 прошло гладко. Тем не менее, мне интересно, может ли это указывать на наличие остатков от проблем, связанных с извлечением Microsoft 17133 в качестве RTM-сборки (например, в EFI NVRAM).
- Логотипы для двух записей в диспетчере загрузки Windows при использовании графических версий различаются. Поэтому на уровне диспетчера загрузки Windows (или загрузчиков) должна быть разница:
Я нахожу это не слишком далеко, чтобы предположить, что проблема custom\bootres.dll выше и проблема логотипа менеджера загрузки здесь тесно связаны. (Смежный вопрос: можно ли изменить значок загрузочной записи Windows?) Чего я не понимаю (пока), так это почему Boot Manager считает, что для этой записи вообще нужны пользовательские ресурсы.