Hello All,
Thank you for the excellent work that you are doing here! I see from reading the posts that many Vista/Win7 users owe the bootability of their systems to your assistance.
Although I am a EE and should be able to figure this out, I admit to being stymied and to having spent way more time on this problem than I should have. (I could have bought 10 new SSDs for all the wasted time.)
I shrunk a sole XP partition on an 80GB Intel SSD (internal HDD on Dell D620 laptop, Disk 0) by 16 GB to accommodate a new partition to hold a new Win7 install. Although dual boot is working perfectly, I soon realized that the 80GB drive is insufficient for my migration plan from XP to Win7 using Virtual XP, etc.
The laptop is inserted into a Dell D/Dock docking station. The docking station includes a single PCI slot into which is installed a SATA controller card. I plan to move XP to a SATA drive (Disk 1) attached to the SATA controller card. I created an image of the XP partition from the SSD drive and copied the image to the SATA drive, minus the MBR. I then created a new MBR to accurately reflect the SATA drive geometry and partition tables, etc.
The Dell D620 BIOS (latest version, A10) is very simple and does not detect the SATA controller. As a result, the ARC path in boot.ini for the SATA drive must be of the form "scsi(x)" and not of the "multi(0)" form, and the SATA controller card driver must be renamed to "ntbootdd.sys" and copied to the boot partition (or, in MS parlance, to the "system" partition). (To the XP partition on the SSD, in any case.) This is the mechanism designed by MS to load a SCSI controller driver at boot time so that NTLDR can read from the SATA drive in order to load Ntoskrnl.exe and the HAL from the SATA drive.
In my particular case, the SATA controller is Silicon Image Sil 3512-based, with the latest version of mini-port driver Si3112 renamed to ntbootdd.sys and placed in the root of XP_SSD. Note that "helper" drivers SiRemFil.sys, SiWinAcc.sys, and SilSupp.dll also show up in the SATA controller properties.
This is all well and good in theory; but I cannot make it work, no matter how I tilt my head or wiggle my nose. The laptop BIOS finds the SSD MBR code, of course, and the MBR code loads the SSD_XP boot sector code, which loads BOOTMGR, which in turn presents the BCD boot menu. I have three entries in the BCD boot menu, XP_SSD (default), Windows 7 (SSD), and XP_HD, as follows:
There are a total of 3 entries listed in the bootloader.
Default: XP_SSD
Timeout: 10 seconds.
Boot Drive: D:\
Entry #1
Name: XP_SSD
BCD ID: {ntldr}
Drive: D:\
Bootloader Path: \ntldr
Entry #2
Name: Windows 7
BCD ID: {current}
Drive: C:\
Bootloader Path: \Windows\system32\winload.exe
Entry #3
Name: XP_HD
BCD ID: {8b20ffaa-aa38-11de-a5ab-00188bd69e8b}
Drive: D:\
Bootloader Path: \NTLDR
To be clear, the drives and partitions (from the point of view of Win 7) are:
Disk 0 = SSD containing: C: = Windows 7 partition; D: = XP_SSD partition.
Disk 1 = SATA drive, containing F: = XP_HD partition.
Entries 1 and 3 both point to boot.ini located in the root of partition D:, which reads as follows:
[boot loader]
timeout=20
default=multi(0)disk(0)rdisk(0)partition(1)\windows
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\windows="XP_SSD" /PAE /noexecute=optin /fastdetect
scsi(0)disk(0)rdisk(0)partition(1)\windows="XP_HD" /PAE /NOEXECUTE=OPTIN /FASTDETECT /bootlog /sos
signature(fc46922a)disk(0)rdisk(0)partition(1)\windows="XP_HD1" /PAE /NOEXECUTE=OPTIN /FASTDETECT /bootlog /sos
Note that there are two entries for XP_HD, used to experiment with the "scsi(x)" form and the "signature(drive signature #)" form. I did this as one of many futile experiments to try to get this to work. The windows device manager is ambiguous as to identifying the "pseudo-scsi" device numbers associated with SATA controller/drives. The controller properties indicate channel=0, target=0. The drive properties indicate bus=0, target=0, LUN=0.
In any case, NTLDR duly presents the two-item menu showing "XP_HD" and "XP_HD1." With either choice I get the error message:
"Windows could not start because of a computer disk hardware configuration problem. Could not read from the selected boot disk. Check boot path and disk hardware. Please check the Windows documentation about hardware disk configuration an dyour hardware disk configuration and your hardware reference manuales for additional information."
Several possibilities occur to me:
(1) Somehow the ARC path(s) in boot.ini are wrong and do not point to the instance of Ntoskrnl.exe on XP_HD.
(2) Somehow the process is not finding, not recognizing, or failing to load the SATA controller driver presented as "ntbootdd.sys." In such case, the boot loader process would be unable to read the XP kernel files located on the XP_HD partition.
(3) The SATA controller driver is a 32-bit protected-mode driver; however the boot process at this point is operating in real mode. Should this work?
(4) The ntbootdd.sys driver loader process appears to accommodate only a single (monolithic) driver file; however there are three additional "helper" files associated with the SATA controller board. Should this work?
(5) I read in some forum that the ntbootdd.sys mechanism is no longer "supported" in the Vista/Win7 BOOTMGR process. But what does that mean? That it no longer works, or that Microsoft would like it not to? What I mean is, for NT/2000/XP systems, BOOTMGR calls NTLDR. As far as I know, this is the same old NTLDR used to load an XP stand-alone system. And the ntbootdd.sys loading process is built into NTLDR. So, I do not know what there is for BOOTMGR to "support." (Unless by this it is meant that Microsoft has removed something from the environment that is required for the ntbootdd.sys process to function.) In the latter case, is there a work-around?
So, I am at my wits end, and any assistance with this perplexing problem would be greatly appreciated. My apologies for the long-winded presentation. As a patent attorney I am loathe to leave ambiguities in place. If I cannot get this working soon I will order an expensive, production limited 160 GB version of the Intel X-25M SSD like I should have done in the first place.
Many thanks; and again, congrats for the great work!
Bruce
Thank you for the excellent work that you are doing here! I see from reading the posts that many Vista/Win7 users owe the bootability of their systems to your assistance.
Although I am a EE and should be able to figure this out, I admit to being stymied and to having spent way more time on this problem than I should have. (I could have bought 10 new SSDs for all the wasted time.)
I shrunk a sole XP partition on an 80GB Intel SSD (internal HDD on Dell D620 laptop, Disk 0) by 16 GB to accommodate a new partition to hold a new Win7 install. Although dual boot is working perfectly, I soon realized that the 80GB drive is insufficient for my migration plan from XP to Win7 using Virtual XP, etc.
The laptop is inserted into a Dell D/Dock docking station. The docking station includes a single PCI slot into which is installed a SATA controller card. I plan to move XP to a SATA drive (Disk 1) attached to the SATA controller card. I created an image of the XP partition from the SSD drive and copied the image to the SATA drive, minus the MBR. I then created a new MBR to accurately reflect the SATA drive geometry and partition tables, etc.
The Dell D620 BIOS (latest version, A10) is very simple and does not detect the SATA controller. As a result, the ARC path in boot.ini for the SATA drive must be of the form "scsi(x)" and not of the "multi(0)" form, and the SATA controller card driver must be renamed to "ntbootdd.sys" and copied to the boot partition (or, in MS parlance, to the "system" partition). (To the XP partition on the SSD, in any case.) This is the mechanism designed by MS to load a SCSI controller driver at boot time so that NTLDR can read from the SATA drive in order to load Ntoskrnl.exe and the HAL from the SATA drive.
In my particular case, the SATA controller is Silicon Image Sil 3512-based, with the latest version of mini-port driver Si3112 renamed to ntbootdd.sys and placed in the root of XP_SSD. Note that "helper" drivers SiRemFil.sys, SiWinAcc.sys, and SilSupp.dll also show up in the SATA controller properties.
This is all well and good in theory; but I cannot make it work, no matter how I tilt my head or wiggle my nose. The laptop BIOS finds the SSD MBR code, of course, and the MBR code loads the SSD_XP boot sector code, which loads BOOTMGR, which in turn presents the BCD boot menu. I have three entries in the BCD boot menu, XP_SSD (default), Windows 7 (SSD), and XP_HD, as follows:
There are a total of 3 entries listed in the bootloader.
Default: XP_SSD
Timeout: 10 seconds.
Boot Drive: D:\
Entry #1
Name: XP_SSD
BCD ID: {ntldr}
Drive: D:\
Bootloader Path: \ntldr
Entry #2
Name: Windows 7
BCD ID: {current}
Drive: C:\
Bootloader Path: \Windows\system32\winload.exe
Entry #3
Name: XP_HD
BCD ID: {8b20ffaa-aa38-11de-a5ab-00188bd69e8b}
Drive: D:\
Bootloader Path: \NTLDR
To be clear, the drives and partitions (from the point of view of Win 7) are:
Disk 0 = SSD containing: C: = Windows 7 partition; D: = XP_SSD partition.
Disk 1 = SATA drive, containing F: = XP_HD partition.
Entries 1 and 3 both point to boot.ini located in the root of partition D:, which reads as follows:
[boot loader]
timeout=20
default=multi(0)disk(0)rdisk(0)partition(1)\windows
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\windows="XP_SSD" /PAE /noexecute=optin /fastdetect
scsi(0)disk(0)rdisk(0)partition(1)\windows="XP_HD" /PAE /NOEXECUTE=OPTIN /FASTDETECT /bootlog /sos
signature(fc46922a)disk(0)rdisk(0)partition(1)\windows="XP_HD1" /PAE /NOEXECUTE=OPTIN /FASTDETECT /bootlog /sos
Note that there are two entries for XP_HD, used to experiment with the "scsi(x)" form and the "signature(drive signature #)" form. I did this as one of many futile experiments to try to get this to work. The windows device manager is ambiguous as to identifying the "pseudo-scsi" device numbers associated with SATA controller/drives. The controller properties indicate channel=0, target=0. The drive properties indicate bus=0, target=0, LUN=0.
In any case, NTLDR duly presents the two-item menu showing "XP_HD" and "XP_HD1." With either choice I get the error message:
"Windows could not start because of a computer disk hardware configuration problem. Could not read from the selected boot disk. Check boot path and disk hardware. Please check the Windows documentation about hardware disk configuration an dyour hardware disk configuration and your hardware reference manuales for additional information."
Several possibilities occur to me:
(1) Somehow the ARC path(s) in boot.ini are wrong and do not point to the instance of Ntoskrnl.exe on XP_HD.
(2) Somehow the process is not finding, not recognizing, or failing to load the SATA controller driver presented as "ntbootdd.sys." In such case, the boot loader process would be unable to read the XP kernel files located on the XP_HD partition.
(3) The SATA controller driver is a 32-bit protected-mode driver; however the boot process at this point is operating in real mode. Should this work?
(4) The ntbootdd.sys driver loader process appears to accommodate only a single (monolithic) driver file; however there are three additional "helper" files associated with the SATA controller board. Should this work?
(5) I read in some forum that the ntbootdd.sys mechanism is no longer "supported" in the Vista/Win7 BOOTMGR process. But what does that mean? That it no longer works, or that Microsoft would like it not to? What I mean is, for NT/2000/XP systems, BOOTMGR calls NTLDR. As far as I know, this is the same old NTLDR used to load an XP stand-alone system. And the ntbootdd.sys loading process is built into NTLDR. So, I do not know what there is for BOOTMGR to "support." (Unless by this it is meant that Microsoft has removed something from the environment that is required for the ntbootdd.sys process to function.) In the latter case, is there a work-around?
So, I am at my wits end, and any assistance with this perplexing problem would be greatly appreciated. My apologies for the long-winded presentation. As a patent attorney I am loathe to leave ambiguities in place. If I cannot get this working soon I will order an expensive, production limited 160 GB version of the Intel X-25M SSD like I should have done in the first place.
Many thanks; and again, congrats for the great work!
Bruce
