Je peux répondre à la question de savoir comment il le localise sur un disque MBR avec Windows 7.
Le site Table IPL du BIOS contient le numéro du disque à partir duquel démarrer et le transmet au vecteur de l'entrée qui sera le code partagé par tous les BAIDs. Ce code charge le premier secteur du disque à l'aide de INT 13h a 0x7c00 vérifie si le MBR est valide et passe le contrôle. Le MBR contient un stub qui s'éloigne de l'écran de l'ordinateur. 0x7c00 et charge celui de la partition active (qui correspond au volume A: sur mon OS) d'abord, c'est-à-dire le secteur VBR à 0x7c00 et saute au premier octet de ce premier secteur, qui est le VBR. Je suppose qu'il transmet le numéro de disque au VBR pour qu'il soit utilisé avec les services en mode réel du BIOS.
Le VBR de la partition active charge alors l'IPL (rien à voir avec l'acronyme IPL mentionné précédemment) des secteurs 1 à 15 de la partition dans la mémoire qu'il localise en utilisant HiddenSectors dans la BPB du VBR (HiddenSectors lui indique son numéro de secteur (secteur 0 de la partition) par rapport au début du disque). Le VBR sait où se trouve la BPB par rapport à lui-même et peut donc passer un handle au code IPL (il a déjà été chargé en mémoire parce qu'il fait partie du secteur 0, qui est ce que le MBR a chargé). Il transmet également le numéro du disque, j'imagine. Le code IPL connaît maintenant le nombre de secteurs par cluster et le cluster du MFT, il peut donc chercher le BCD dans le fichier \Boot\BCD en utilisant le code primitif du pilote NTFS dans l'IPL. Il se contente donc de rechercher le répertoire racine sur le MFT dans la BPB qui lui est donnée, qui est bien sûr la BPB de la partition actuelle. C'est pourquoi la partition réservée au système doit être active, sinon le MBR de Windows ne saura pas quelle partition est la partition réservée au système et ne saura donc pas quel VBR charger. La partition MBR+system rsvd VBR+IPL+Bootmgr est le bootloader primaire et winload est le secondaire. Si vous installez Grub, il écrasera le MBR avec son propre stub pour charger son propre bootloader primaire et ne se soucie pas de savoir quelle partition est active. Pour récupérer le MBR qui charge le VBR de la partition active, utilisez bootrec /fixmbr . bootsect /nt60 SYS /mbr est ce qui fixe le VBR et l'IPL sur la partition système.
Je crois que c'est l'IPL qui charge le BCD et le transmet à Startup.com. Cela pourrait facilement être startup.com ou bootmgr qui fait cela mais l'indice est dans le fait qu'il y a une entrée bootmgr avec un chemin bootmgr dans le BCD, donc cela indique à l'IPL l'emplacement de bootmgr.
L'IPL analyse le MFT du système de fichiers NTFS, localise bootmgr, charge la partie startup.com dans l'espace d'adressage en mode réel, dans mon cas, il semble qu'il s'agisse d'environ 0x20000 alias. 2000:0000 et lui transmet le contrôle. Startup.com semble être un fichier CP/M ou CP/M 3 sans la balise C9 numéro magique ou en-tête de 256 octets. Il ne s'agit donc pas d'un fichier DOS, et certainement pas d'un 'DOS stub' (il y en a un au début de bootmgr.exe).
Le programme en mode réel (Startup.com) passe du mode réel 16 bits au mode protégé 16 bits puis 32 bits avec la pagination désactivée. Startup.com utilise l'entrée bootmgr dans le BCD pour localiser bootmgr afin de pouvoir y localiser bootmgr.exe, analyse le MFT sur le volume spécifié (notez que l'entrée contient un nom de périphérique de volume de style volmgr et non la lettre du lecteur, car bootmgr est utilisé par plusieurs installations de Windows et leurs winload.exes respectifs, donc une lettre de lecteur ne signifie rien). bootmgr.exe est à l'offset 0x7BF3 dans bootmgr, pour 0x400000 sur mon système, et le décompresser en utilisant lznt1 à partir de 0x7BF0 . Il passe ensuite le contrôle à bootmgr!BmMain qui reçoit un PBOOT_APPLICATION_PARAMETER_BLOCK contenant un décalage vers un BL_APPLICATION_ENTRY qui contient un BL_BCD_OPTION qui est le premier d'une chaîne d'entiers BCD.
Bootmgr va activer la pagination et passer en mode long 64 bits avant de charger et de passer le contrôle à l'entrée sélectionnée, en utilisant le volume et le chemin de winload.exe dans l'entrée BCD pour analyser le MFT. A ce moment, il sait quelle partition un lien symbolique de volume comme C: correspond à. Je crois que lorsque vous faites bcdedit vous verrez la lettre de lecteur du point de vue du système d'exploitation que vous utilisez actuellement - le BCD stocke simplement la signature MBR + le décalage de la partition dans l'entrée et celle-ci est affichée ou modifiée en utilisant une lettre de lecteur dans le contexte des liens symboliques du système d'exploitation actuel (construits à partir de la base de données mountmgr) pour plus de commodité.
Il charge le winload.exe pour l'entrée du système d'exploitation pour 0x2ef000 sur mon système et passe le contrôle à winload!OslMain . Bootmgr.exe est son propre noyau avec son propre moteur de débogage et ses pilotes. Winload est son propre noyau avec son propre moteur de débogage et ses pilotes. Tous deux ne peuvent gérer le débogage que sur le port COM 1. Winload est responsable du chargement du noyau principal ntosrkrnl.exe, qui possède son propre moteur de débogage et ses pilotes. Notez que x64 supporte toujours MP et qu'il n'y a pas de PAE (donc pas ntkrnlpamp.exe), ils sont donc appelés hal.dll et ntoskrnl.exe au lieu de halmapic.dll et ntkrnlmp.exe, bien qu'il s'agisse essentiellement de ntkrnlmp.exe. Vous pouvez utiliser le .pdb qui a été téléchargé pour le binaire avant que l'option ! Ainsi, si c'est ntkrnlmp.pdb, ce qui sera le cas pour ntoskrnl.exe de Windows 7, vous pouvez utiliser ntkrnlmp! 代わりに nt! dans les débogueurs du noyau de Windows.
