Need Help w/ EasyBCD and Ntbootdd.sys

#1
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.) :smile:

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. :angry:

Many thanks; and again, congrats for the great work!

Bruce
 

Terry60

Knows where his towel is.
Staff member
#2
Hi Bruce, welcome to NST.
(Are you the same Patent Attourney, Bruce formerly of Boston ?)
The BCD doesn't contain multiple XP entries for XP. Just a single entry pointing to the copy of the XP boot files which must reside on the "system" partition. The copy of boot.ini found there discriminates between and points to the multiple XPs.
If you are "BDSBoston", EasyBCD has progressed a long way since your last visit.
Install EasyBCD 2.0 latest build on W7, delete the 2 entries for XP in the BCD, add a new XP entry and let Easy2 auto-configure for you when it offers.
Let us know if your particular configuration isn't handled automatically. Guru would obviously be interested while Easy2 is still Beta (v. close to release)
 
#3
Hi Bruce, welcome to NST.
(Are you the same Patent Attourney, Bruce formerly of Boston ?)
The BCD doesn't contain multiple XP entries for XP. Just a single entry pointing to the copy of the XP boot files which must reside on the "system" partition. The copy of boot.ini found there discriminates between and points to the multiple XPs.
If you are "BDSBoston", EasyBCD has progressed a long way since your last visit.
Install EasyBCD 2.0 latest build on W7, delete the 2 entries for XP in the BCD, add a new XP entry and let Easy2 auto-configure for you when it offers.
Let us know if your particular configuration isn't handled automatically. Guru would obviously be interested while Easy2 is still Beta (v. close to release)

Hi Terry, and thank you for the response.

No, I am not the same Bruce. I am Bruce Houston, have lived in San Antonio for the past 25 years, and only discovered this forum a few days ago.
Yes, I am aware that the two XP entries in the BCD are redundant in that they both point to the same boot.ini file in the root of D: (XP_SSD). I will delete one of them; however this is not germaine to my problem. It appears that I may not have communicated the problem very well.

I am using Easy2 Build 64. As to auto-configuring boot.ini for my configuration, Easy2 has no clue. As I mentioned in the marathon post, a disk controller that cannot be seen by the system BIOS cannot use the "multi(x)" ARC path form in boot.ini but rather must use the "scsi(x)" form. "In a mixed SCSI and IDE system, the MULTI() syntax will work only for the IDE drives on the first controller." --Microsoft Article ID: 102873.

Easy2 produces the following ARC path:

multi(0)disk(0)rdisk(0)partition(1)\windows="Windows XP on D:" /fastdetect

The proper ARC path is:

scsi(0)disk(0)rdisk(0)partition(1)\windows="(whatever)" /fastdetect (and other switches that I do not need help with), together with the proper SATA controller driver renamed as ntbootdd.sys.

Unless I am missing something fundamental, I believe that reliably auto-configuring boot.ini is way beyond a reasonable scope for this project. It would at a minimum, I believe, require scanning the PCI/PCIe, etc. buses for disk controllers, reading the system BIOS, figuring out whether the multi(x) or scsi(x) format is proper for each controller, finding the pseudo-scsi IDs, finding the controller drivers, renaming the applicable driver to ntbootdd.sys, etc. to be able to reliably automate the configuration of boot.ini for a generalized set of drives and controllers. Otherwise you might have check boxes and/or parameter fields (e.g., for scsi IDs) that the user might pre-fill to enable EasyBCD to build the proper ARC paths.

There was an additional problem that the author may want to correct. Easy2's current approach of locating all boot files in the (MS parlance) system partition root and pointing all BCD entries to that location leaves no (MS parlance) boot partition location information to use to build the boot.ini ARC paths. Thus it was no surprise to see that Easy2 created two identical ARC path entries for XP_SSD and XP_HD, even though these two instances of XP are on separate physical drives.

Perhaps a better approach would be to point each BCD entry directly to its corresponding (MS parlance) boot partition. Then EasyBCD could use this location information to coherently assemble a boot.ini file containing all ARC paths and distribute a copy to the root of each (MS parlance) boot partition. This is just a thought; what do I know? I cannot even get my simple system to work.

In any case, hopefully you can see that my problem has very little to do with all the above. The problem is related to the ntbootdd.sys mechanism in an XP/Win7 environment. I do not know whether it is even supposed to work or, if so, how to perform a trace to figure out where the process is dying.

So, thanks again, and please do not hesitate to share any additional thoughts or work-arounds that come to mind. If I cannot solve this very soon I will simply order the expensive, production-limited 160 GB version of the Intel X-25M like I should have done in the first place.

Many thanks,
Bruce Houston
 
Last edited:

Terry60

Knows where his towel is.
Staff member
#4
Strange coincidence. Only two Patent lawyers I've ever seen (here or anywhere else), and they're both called Bruce !
Sorry 2.0 was no use for your strange configuration, but blame MS not EasyBCD for pointing everything to "system". It's just putting the stuff where bootmgr expects to find it according to the Windows boot philosophy.
I'm not going to be a lot of use to you sorting out the scsi syntax to get your other XP booting through boot.ini, (not been there - not done that), but I suppose you have already browsed through the KB article on the subject ?
 
#5
Ok; thanks Terry.

Yes, I have been using that KB article as my bible trying to get this to work. I can only assume that the response from MS that I read in the other forum, that the ntbootdd.sys scsi driver loading process at boot time is no longer "supported" under bootmgr must be correct. MS must have removed something from the environment that prevents ntldr from performing this task.

In any case, I simply gave up this afternoon and ordered the 160 GB Intel SSD for overnight delivery tomorrow, as I should have done two weeks ago. My tenacity can be a very expensive personality trait.

Yes, it does seem a bit conincidental that both of the patent attorneys that you have communicated with are named Bruce. Maybe something about the Scottish highlands that breeds patent attorneys?

Thanks again for your willingness to assist; and all the best to those involved with this website and the support function.

Bruce