boot question

  • Thread starter Thread starter TerryW
  • Start date Start date
T

TerryW

First off, everything that I have done with XPE works great.
I make an image, I resea it, I copy it onto the target and it unseals
when I boot it.

I am just curious about how this works.
How does my computer know to use ntLoader?
What part of XPE or PE writes to the MBR to tell the computer that the
disk is bootable? Or is it even necessary to write to the MBR?

Ease my pain... foolish inconsistency (simple mind here)
TIA
Terry W
 
First off, everything that I have done with XPE works great.
I make an image, I resea it, I copy it onto the target and it unseals
when I boot it.

I am just curious about how this works.
How does my computer know to use ntLoader?
What part of XPE or PE writes to the MBR to tell the computer that the
disk is bootable? Or is it even necessary to write to the MBR?

Ease my pain... foolish inconsistency (simple mind here)
TIA
Terry W

Forgive me if I get this wrong in parts - I'm sick today...

To start with, the BIOS looks for which drive to boot from. It loads the
boot sector and looks the MBR. It then locates the partition that is marked
active in the MBR and loads the first sector from it and executes. That
sector has instruction on what to load next. For NT style partitions, it
knows to deal with NTLDR, etc. For DOS style partitions, it knows to deal
with IO.SYS and MSDOS.SYS. After that, the OS loads.
 
In more detail,
NTLDR loads the files system drivers (so that it can read the hard
disk) and lreads Boot.ini in order to decide which OS to load and where
to load it from. Fo a DOS option NTLDR passes control to BOOTSECT.DOS,
othrwise it loads NTDETECT.COM. This scans all the associated hardware
and passes it to a the system hive in the registry. Finally NTLDR
loads NTOSKRNL.EXE and the kernal phase of booting begins.

Once this is loaded, HAL.DLL is laoded and the system hive generated
earlier is loaded, followed by appropriate drivers (this is where the
dots pass across the screen). The CurrentControlSet aspect of the
registry is saved and all the hardware is configured in the registry.
Next the Session manager is started (SMSS.EXE) and the BootExecute
sequence is run; then the pagefile is generated, the CurrentControlSet
is written to the registry and the Win32 subsystem loads.
The Win32 subsystem starts the WinLogon process (WINLOGON.EXE), the
Local Security Authority is started. When logon is successful the
clone set becomes the last known good set.

I hope that the above is still correct, it was actually derived from an
NT reference, but it still looks to be appropriate.

Regards

Justin
 
Thank you both very much for very complete replies.

I wonder now, however, how my system boots at all. I create three
partitions and quick format them all, marking the first one as active.
I then just xcopy the files from my build on to the first partition.
Viola! It boots.

Please note I haven't done a thing to the MBR.

I have copied NTLDR to the partition, but I haven't done anything to
point the system to it. I wonder what has?

Still a little confused...
 
The trick lies in making the first one active. This is the process
which places information in the MBR to direct it to the partition to
boot from. The original writing of the MBR is a little bit more subtle
- it doesn't happen very often. I believe that most disk come with an
MBR in place which canbe modified by the making active process. If you
set up a disk to use Linux, then inux rewrites the MBR in a way that
Windows boots cannot use and even re-partitioning will not make it
work. I haven't tried reovering a Linux disk with Diskpart, but with
the old FPART there was an undomuneted /MBR switch which would force it
to write new, clean MBR.
 
Forgot to mention, selecting a new partition as a primary partition is
also important so that it contains the initial boot sector which is
called by the MBR code.
So you can see that you are in fact doing everything that is required,
even though you weren't aware of it.

Regards

justin
 
Back
Top