Как диспетчер загрузки Windows обнаруживает BCD?

Диспетчер загрузки ищет BCD на ESP, потому что это единственный раздел, известный на этом этапе, и микропрограмма, вероятно, может только читать разделы FAT. Путь к БХД (/EFI/Microsoft/Boot/BCD) на ESP, вероятно, жестко закодированы. UEFI был разработан с самого начала, чтобы поддерживать сосуществование программного обеспечения от разных поставщиков, и /EFI/Microsoft это "игровая площадка" Microsoft на ESP.

Я могу ответить, как он находит его на MBR-диске с Windows 7.

Таблица IPL BIOS содержит номер диска для загрузки и передает его вектору в записи, который будет кодом, общим для всех BAID. Этот код загружает первый сектор с диска, используяINT 13hдля проверки допустимого MBR, а затем передает управление. MBR содержит заглушку, которая удаляется и загружает активный раздел (что соответствует объему тома).A:в моей ОС) первый сектор, т.е. VBR для0x7c00и переходит к первому байту этого первого сектора, который является VBR. Я предполагаю, что он передает номер диска в VBR для использования со службами реального режима BIOS.

Затем VBR активного раздела загружает IPL (не имеет ничего общего с ранее упомянутой аббревиатурой IPL) из секторов 1–15 раздела в память, которую он находит с помощью HiddenSectors в VBR BPB (HiddenSectors сообщает номер своего сектора (сектор 0 из раздел) относительно начала диска). VBR знает, где находится BPB относительно самого себя, поэтому он может передать его дескриптор в код IPL (он уже загружен в память, поскольку является частью сектора 0, который загружает MBR). Он также передает номер диска, который я должен себе представить. Код IPL теперь знает, сколько секторов имеется в кластере, и кластер MFT, поскольку информация находится в BPB, поэтому он может искать BCD в разделе, к которому принадлежит BPB, используя примитивный код драйвера NTFS в IPL. Поэтому он просто просматривает корневой каталог MFT в предоставленном ему BPB, который, конечно же, является BPB текущего раздела. Вот почему раздел, зарезервированный системой, должен быть активным, потому что в противном случае MBR Windows не будет знать, какой раздел является разделом, зарезервированным системой, поэтому он не будет знать, какой VBR загружать. Раздел MBR+system rsvd VBR+IPL+Bootmgr является основным загрузчиком, а winload — вторичным. Если вы установите GRUB, он перезапишет MBR своей собственной заглушкой, чтобы загрузить собственный основной загрузчик, и ему не важно, какой раздел активен. Чтобы вернуть MBR, который загружает VBR активного раздела, используйтеbootrec /fixmbr.bootsect /nt60 SYSилиbootrec /fixbootэто то, что исправляет VBR и IPL в системном разделе.bootsect /nt60 SYS /mbrтакже исправляет mbr.

IPL находит bootmgr (предположительно сначала через BCD, иначе я не знаю, какой будет точка в записи bootmgr в BCD), загружает часть start.com из начала bootmgr в адресное пространство реального режима, в моем случае, если он загружает его в0x20000ака.2000:0000и передает ему управление. Startup.com — это COM-файл DOS, начинающийся с перехода E9, а не «заглушки DOS» (один из них есть в начале bootmgr.exe).

Программа реального режима (Startup.com) переключается с 16-битного реального режима на 16-битный, а затем на 32-битный защищенный режим с отключенной подкачкой. Затем Startup.com предположительно считывает BCD (через свою собственную логику NTFS, или использует IPL, или BCD передается ему в памяти) и загружает bootmgr.exe со смещением.0x7BF3в bootmgr, чтобы0x400000в моей системе и распаковать его с помощьюlznt1. Затем он передает управлениеbootmgr!BmMain, а не «заглушка DOS», которая получаетPBOOT_APPLICATION_PARAMETER_BLOCKсодержащий смещение кBL_APPLICATION_ENTRY, который содержитBL_BCD_OPTIONкоторый является первым в цепочке вариантов BCD для записи приложения (bootmgr, winload и т. д.). Для MBR записи приложения BCD содержат смещение диска и раздела в опции «устройство», а не буквы дисков (поскольку bootmgr используется несколькими установками Windows и соответствующими файлами winload.exe, поэтому буква диска ничего не значит). Кажется, winload и ОС тоже могут находиться на разных разделах.

Bootmgr включит подкачку и переключится в 64-битный режим перед загрузкой и передачей управления выбранной записи, используя том и путь к файлу winload.exe в записи BCD для анализа MFT. В настоящее время он знает, на каком разделе находится символическая ссылка тома, напримерC:соответствует. Я верю, что когда ты это сделаешьbcdedit, вы увидите букву диска с точки зрения любой операционной системы, которую вы используете в данный момент — BCD просто сохраняет подпись MBR + смещение раздела в записи, и это отображается или редактируется с использованием буквы диска в контексте текущего Символические ссылки ОС (собранные из базы данных mountmgr) для удобства.

Он загружает winload.exe для записи ОС в0x2ef000в моей системе и передает управлениеwinload!OslMain. Bootmgr.exe — это собственное ядро ​​со своим механизмом отладки и драйверами. Winload — это собственное ядро ​​со своим механизмом отладки и драйверами. Оба они могут выполнять отладку только через COM-порт 1. Winload отвечает за загрузку основного ядра ntosrkrnl.exe, которое имеет собственный механизм отладки и драйверы. Обратите внимание, что x64 всегда поддерживает MP и не имеет PAE (поэтому нет ntkrnlpamp.exe), поэтому они называются hal.dll и ntoskrnl.exe вместо halmapic.dll и ntkrnlmp.exe, хотя по сути это ntkrnlmp.exe. Вы можете использовать.pdbимя, которое было загружено для двоичного файла до!, поэтому, если это ntkrnlmp.pdb, который будет для Windows 7, ntoskrnl.exe, вы можете использоватьntkrnlmp!вместоnt!в отладчиках ядра Windows.