Процесс загрузки Windows 2008 R2

Question

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

Я думаю, что мой вопрос сводится к следующему: как конкретно процесс загрузки Windows определяет расположение VBR/ загрузочного сектора на диске для раздела «boot» в Windows 2008 R2?

Подоплека моего вопроса заключается в следующем.

У меня совершенно счастливая, работающая установка 2008R2 (VM), которая содержит стандартный 100 МБ системный зарезервированный раздел, за которым следует раздел "boot" (C:\). В образовательных целях я переместил раздел C:\ точно на 1 МБ в "правую" часть системного раздела (используя gparted), который вставил пробел в 1 МБ (2048 секторов) между двумя разделами.

Этот процесс правильно обновил как запись раздела в MBR, так и изменил поле C:\ bootsector «зарезервированный / скрытый сектор».

Но теперь Windows не загружается (выдает ошибку Boot Manager « 0xc0000225 » - требуемое устройство недоступно). И установка восстановления не может даже найти установку Windows, чтобы восстановить. Имейте в виду, если я смонтирую диск на другом компьютере с Windows, тома будут исправными и жизнеспособными. Кроме того, если я переместил раздел C:\ на прежнее место, все загрузилось.

Итак, если MBR указывает на правильное смещение, почему Windows не может найти / загрузить раздел C:\ когда он был перемещен?

Answer 1

Прежде всего, вы должны заметить, что VBR на разделе C: не участвует в процессе загрузки. VBR в "системном" разделе загружает bootmgr, который загружает ядро Windows из раздела C:.

Я только что попробовал это сам. Удобно оказалось, что при запуске bcdboot создается новая загрузочная запись в BCD, поэтому мы можем легко сравнить старую запись с новой, чтобы увидеть, что изменилось.

Используя bcdedit, мы видим, что параметры device и osdevice разные:

C:\Windows\system32>bcdedit /enum /v

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-us
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {fde483f1-1482-11e2-90a1-00505698002c}
resumeobject            {fde483f0-1482-11e2-90a1-00505698002c}
displayorder            {fde483f1-1482-11e2-90a1-00505698002c}
                        {7409376c-f38e-11e1-bc89-00505698002c}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {fde483f1-1482-11e2-90a1-00505698002c}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-us
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
osdevice                partition=C:
systemroot              \Windows
resumeobject            {fde483f0-1482-11e2-90a1-00505698002c}
nx                      OptIn
detecthal               Yes

Windows Boot Loader
-------------------
identifier              {7409376c-f38e-11e1-bc89-00505698002c}
device                  unknown
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {7409376d-f38e-11e1-bc89-00505698002c}
recoveryenabled         Yes
osdevice                unknown
systemroot              \Windows
resumeobject            {7409376b-f38e-11e1-bc89-00505698002c}
nx                      OptIn

К сожалению, bcdedit не сообщает нам, как хранится информация, поэтому нам придется посмотреть сам файл BCD. Как вы, возможно, уже знаете, файл BCD на самом деле является кустом реестра, и обычно он загружается в HKLM\BCD00000000 , поэтому мы можем проверить его с помощью regedit или reg reg.

Идентификатором для каждой записи является имя раздела реестра, содержащего настройки. Сами настройки являются подразделами, расположенными в том же порядке, в котором они отображаются в выводе bcdedit. Оказывается (неудивительно), что в каждой записи устройство и osdevice содержат одни и те же данные, и эти данные для функциональной записи отличаются от старой.

На моей системе это появляется в работающей записи:

"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
  00,00,00,48,00,00,00,00,00,00,00,00,00,80,06,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,01,00,00,00,b0,5d,de,33,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

и это появляется в старой записи:

"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
  00,00,00,48,00,00,00,00,00,00,00,00,00,50,06,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,01,00,00,00,b0,5d,de,33,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

Есть только одно отличие. Давайте отформатируем старую запись немного более красиво:

0000 00,00,00,00,00,00,00,00,
0008 00,00,00,00,00,00,00,00,
0010 06,00,00,00,00,00,00,00,
0018 48,00,00,00,00,00,00,00,
0020 00,00,50,06,00,00,00,00,
0028 00,00,00,00,00,00,00,00,
0030 00,00,00,00,01,00,00,00,
0038 b0,5d,de,33,00,00,00,00,
0040 00,00,00,00,00,00,00,00,
0048 00,00,00,00,00,00,00,00,
0050 00,00,00,00,00,00,00,00

В новой записи байт 0x0022 равен 0x80 вместо 0x50. Как оказалось, я переместил раздел на 3 МБ, поэтому я подозреваю, что это часть смещения. Давайте посмотрим, что произойдет, если я переместу его еще на 4 МБ (всего 7 МБ) и создам новую запись BCD, не так ли? Хорошо ... 0x80 становится 0xC0, так что это соответствует.

Разумным предположением будет то, что восемь байтов (или, может быть, шестнадцать?) начиная с 0x0020 - байтовое смещение начала раздела. Значение 0x06C00000 равно 113246208 или точно 108 МБ; исследуя таблицу разделов, я обнаружил, что это действительно начало раздела. QED. :-)