Re: hibernation file location
- From: "Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx>
- Date: Mon, 18 Jun 2007 14:55:54 +0900
"John Hensley" <resqware@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:4BAD07F6-CFCD-44C9-BCAD-EFE37DB6A369@xxxxxxxxxxxxxxxx
"Norman Diamond" wrote:"John Hensley" <resqware@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4099A8F2-BEF5-4D94-A090-2490C5F598D1@xxxxxxxxxxxxxxxx
which can only access the file via ROMBIOS int 13h.
No. I see you remember NTBOOTDD.SYS but I'm going to explain anyway.
If a disk controller driver was copied to system partition (where NTLDR, BOOT.INI, and NTDETECT.COM reside), and renamed as NTBOOTDD.SYS, then NTLDR would be able to read a kernel and drivers from the boot partition on a drive connected to that controller, even if the controller didn't have a BIOS. Windows NT4 SP4 and later automatically generated a file NTBOOTDD.SYS but it could also be done manually for the working version SP3, and for Windows 2000 and XP.
IIRC the NTBOOTDD.SYS driver is only loaded if the the ARC path in the boot.ini file uses the SCSI or SIGNATURE format when specifying the system drive. According "Windows Internals 4th Ed." the boot.ini file is not processed when resuming from hibernation so this would prevent the NTBOOTDD.SYS driver being involved with resume from hibernation. This actually makes sense because the hiberfile contains all of the boot driver stacks and there would be no need to load the NTBOOTDD.SYS driver when resuming from hibernation.
This seems impossible to me. How would NTLDR know which hiberfile.sys to load before it even looks for partitions that contain hiberfile.sys files?
It's also important to remember that the NTBOOTDD.SYS driver is used to provide access to the system volume and not the boot volume. Windows keeps a separate ARC path name for each volume and these will be different anytime the system volume is not the same partition as the boot partiton. Even when the NTBOOTDD.SYS driver is used to access the system drive Windows will still consider the partition that NTLDR was loaded from as the boot drive.
You're using the words "system partition" and "boot partition" with meanings that sound the way they do in English. More on this later.
I don't recall if I tried hibernating XP in that configuration.
Thinking about the generalities of the BOOT.INI file, specifying a number of controllers and drives and partitions, I'm still trying to figure out how NTLDR could load drivers for all of those controllers when all of the drivers had to be given the same filename NTBOOTDD.SYS.
As explained above, boot.ini does get processed when resuming from hibernation (at least according to "Windows Internals").
Your later correction to "does not get processed" is noted. It still seems impossible, for the reason stated above (and below, and previously).
Though it is common to load the non-bootstrap components of the OS from a non-int 13h accessible drive using an ntbootdd.sys mini-port driver, I am assuming NTLDR doesn't search anything other than the actual boot drive since the presence of a valid hiberfile prevents boot.ini from being processed and thus any information about the actual system drive would not be available.
But how does NTLDR even know which partition to read HIBERFILE.SYS from? Even though NTLDR refuses to give the user a choice to boot another partition's system instead of resuming the hibernated one, the hibernation file still resides on a boot partition with a kernel and system files of a Windows installation, not on the system partition with the boot loader. The boot loader still has to read BOOT.INI and scan to see if a hibernation file somewhere is ready to be loaded.
I think you have it reversed. The kernel and drivers reside on the system partition. NTLDR, the hiberfile and all other bootstrap files reside on the boot partition which is accessible via the ROMBIOS int 13h interface.
You have it reversed ^_^ Who are you going to trust, the English language or Microsoft ^_^ Why do you think I went to such pains to clarify which partition I was talking about in each case ^_^
NTLDR always knows how to get to the boot partition using int 13h because that information is provided to NTLDR by the code in the partition boot record that loads NTLDR.
Yes, NTLDR still has to use int 13h to read NTBOOTDD.SYS in the same partition where the BIOS helped the PBR read NTLDR.
The boot.ini file on the boot partitioin tells NTLDR how to locate the kernel on the system partition.
The boot.ini file tells NTLDR which partitions contain kernels (and hiberfile.sys files), but it doesn't tell NTLDR how to read those partitions. Some of those partitions might be accessible through int 13h, some might be accessible through NTBOOTDD.SYS, and some might not be bootable (as far as I can tell). The boot.ini file doesn't tell NTLDR which Windows system was the latest one to hibernate itself. So I still think NTLDR has to do some scanning in order to figure out which hiberfile.sys to reload.
.
- References:
- Re: hibernation file location
- From: Don Burn
- Re: hibernation file location
- From: John Hensley
- Re: hibernation file location
- From: Norman Diamond
- Re: hibernation file location
- From: John Hensley
- Re: hibernation file location
- Prev by Date: Problem while using 'CM_Locate_DevNode_Ex'
- Next by Date: Re: Problem while using 'CM_Locate_DevNode_Ex'
- Previous by thread: Re: hibernation file location
- Next by thread: Re: hibernation file location
- Index(es):
Relevant Pages
|
