For a number of years now I’ve been using a SATA SSD with a “portable” Windows XP installation on it. Portable in the sense that it was capable of booting on a number of my machines, either in IDE mode or in some cases, in AHCI mode. But not anymore—now it no longer booted on some boards either in IDE or in AHCI mode, and failed with everyone’s favorite, bug check 0x7B (INACCESSIBLE_BOOT_DEVICE). I couldn’t make heads nor tails of it; it still worked perfectly fine on a number of boards, but on some it just wouldn’t boot.
I suspected that this was triggered by my failed attempts to get the XP install booting on my DX79SR Stormville board in AHCI mode. In the end I concluded that it couldn’t be done, but not before I tried installing several different AHCI drivers; to be clear, those drivers did make a difference—they made the OS crash at boot-up with bug check 0x7E (completely different from 0x7B and indicating a buggy driver). The Stormville board has a somewhat uncommon IDE/AHCI chip (related to the C600 chipset rather than any Intel desktop chipset) and it was released late enough (2011) that XP support was not provided.
After my failed experiments, I was no longer able to boot on the Stormville board even in IDE mode. I was also no longer able to boot that XP install on an older Intel D975XBX2 (Bad Axe 2) board, which previously worked fine in AHCI mode. But now it just sulked and gave me INACCESSIBLE_BOOT_DEVICE in both IDE and AHCI mode.
I attempted various fixes including a number of attempts of fix_hdc from Hiren’s boot CD. It did something, but that definitely did not include getting rid of the INACCESSIBLE_BOOT_DEVICE bug checks.
In desperation, I hooked up the XP install to a kernel debugger. It was already set up for kernel debugging (not that it would have been hard to do) and the Bad Axe 2 board is old enough to have a real serial port on the back panel. I booted up with the SATA controller in AHCI mode and kernel debugger attached. What the kernel debugger told me was odd.
The system loaded two AHCI drivers, iaStor.sys (version 18.104.22.1684) and IASTOR7.sys (22.214.171.1246). The latter I’m pretty sure was put in place by fix_hdc on Hiren’s boot CD. The system also loaded pciide.sys, as well as a couple of other standard storage drivers.
The trouble clearly was that pciide was the only driver with child devices. And those were all on the “real” IDE controller on the D975XBX2 board’s ICH7DH chipset (which is for all intents and purposes identical to ICH7R). This was clearly visible in the kernel debugger (
!drvobj pciide vs.
!drvobj iastor and
The odd thing was the output of the
!arbiter command. I compared the resources with what
!pci 100 0 1f 2 told me (device 1Fh, function 2 is the SATA controller). I found that all the resources (memory and I/O ports) of the AHCI controller were owned by the pciide.sys driver. Well, that would explain why this configuration wasn’t working—if pciide.sys claimed all the AHCI resources, the AHCI driver had no chance. This was confirmed by poking around with the
0: kd> !devnode 8c1f9ca8 DevNode 0x8c1f9ca8 for PDO 0x8c1d4030 Parent 0x8c226220 Sibling 0x8c1f9b88 Child 0x8c1cf660 InstancePath is "PCI\VEN_8086&DEV_27C1&SUBSYS_58428086&REV_01\3&61aaa01&0&FA" ServiceName is "pciide" State = DeviceNodeStarted (0x308) Previous State = DeviceNodeStarted (0x308) StateHistory = DeviceNodeQueryStopped (0x309) ... StateHistory = DeviceNodeStarted (0x308) StateHistory = DeviceNodeEnumerateCompletion (0x30d) StateHistory = DeviceNodeStarted (0x308) StateHistory = DeviceNodeEnumerateCompletion (0x30d) StateHistory = DeviceNodeStarted (0x308) Flags (0x000000f0) DNF_ENUMERATED, DNF_IDS_QUERIED, DNF_HAS_BOOT_CONFIG, DNF_BOOT_CONFIG_RESERVED
PCI\VEN_8086&DEV_27C1 is the ICH7DH SATA device in AHCI mode, but there’s no way it can work with the
But why did that happen and how to fix that? The trigger may have been me trying to follow this and other guides in an attempt to get the XP setup booting on the D975XBX2 board in IDE mode.
Only before trying to fix this, maybe I should first see what happens with the SATA controller in IDE mode. Whereupon I discovered that instead of dying with INACCESSIBLE_BOOT_DEVICE, XP now died with BAD_POOL_HEADER with iaStor.sys on the call stack. Hmm.
So I disabled iaStor.sys by renaming the driver file and rebooted again. This time it was back to INACCESSIBLE_BOOT_DEVICE. Interestingly, the
pciide driver still owned all the SATA chip resources, and it still didn’t see any drives. Oh, here’s why:
0: kd> !devnode 8c1a9a68 DevNode 0x8c1a9a68 for PDO 0x8c1a9030 Parent 0x8c2393a8 Sibling 0x8c1a9948 Child 0000000000 InstancePath is "PCIIDE\IDEChannel\4&16ecd62b&0&0" ServiceName is "iaStor" State = DeviceNodeInitialized (0x302) Previous State = DeviceNodeUninitialized (0x301) StateHistory = DeviceNodeUninitialized (0x301) StateHistory = Unknown State (0x0) ... StateHistory = Unknown State (0x0) Flags (0x000002f0) DNF_ENUMERATED, DNF_IDS_QUERIED, DNF_HAS_BOOT_CONFIG, DNF_BOOT_CONFIG_RESERVED, DNF_RESOURCE_REQUIREMENTS_NEED_FILTERED
So the short story is that in AHCI mode, the IDE driver owned all the resources, and in IDE mode, the AHCI driver owned the IDE channel. No wonder it wouldn’t work!
Here’s part of the mess:
PCI\VEN_8086&DEV_27C1 is the ICH7DH SATA controller in AHCI mode. Of course it’s not going to work as IDE, but it actually appears to prevent the proper driver (iaStor.sys) from working. This is where Windows PnP fell flat on its face—this should never have been possible to do, because the device’s PCI class does not match.
OK, now I understood how I got probably there: The common advice for switching an existing Windows XP install from IDE to AHCI is actually terrible. It works, but at the cost of screwing up the initial configuration. That is, if you force the AHCI driver on the IDE controller, XP will boot up when you switch the controller from IDE to AHCI, but it will no longer work in IDE mode. Because Windows PnP is so stupid that it lets you install an AHCI driver on an IDE controller or vice versa, breaking the innocent device that you forced it on.
Get Me Out of Here!
Understanding the problem is all well and good, but how do I fix it? If the broken XP install was on an IDE drive, I could just plug it into a separate PCI IDE controller that’s supported out of the box by Windows XP (and I’d have one or two of those), but I have no add-in card that would take a SATA drive and present an IDE interface to the system. In fact I have no add-in SATA controller at all.
It is probably possible to manually edit the registry to get rid of the problematic entries. But to be honest, I trust manual registry editing even less than I trust the XP PnP subsystem. I’d rather not go that route.
But wait… actually I do have an add-in SATA adapter! Only I didn’t think of it immediately because it’s SAS. It’s an LSI Logic SAS3041E controller (PCI Express, HP branded) that is supported by Windows XP and has four SATA style ports so SATA drives can be directly attached without any funny cables or adapters.
But of course this HBA won’t just boot XP out of the box because this particular XP setup has never seen that adapter. So this is going to be a multi-step process:
- Grab a board where the half-broken XP install still boots, either in AHCI or IDE mode. Closest at hand was a Supermicro X7DCL-3, that will do fine.
- Plug the SATA SSD with the sick XP install into an onboard SATA port and plug in the SAS3041E PCIe adapter with no drives connected to it.
- Boot Windows XP, install drivers for the SAS HBA (I used the ones from LSI, with the symmpi.sys driver).
- Optional: Move the SATA drive from the onboard port to the SAS HBA, verify that the XP install really boots (it does).
- Bring back one of the problem boards. I started with the D975XBX2 in case I needed the kernel debugger (I didn’t). Plug in the SAS HBA, attach the SATA SSD to that.
- Boot up Windows XP. It works!
- Now observe how broken things are in the Device Manager:
Note that there are two primary and two secondary IDE channels because the ICH7DH chipset has a separate IDE controller. Also note that they are both broken by the IDE driver incorrectly “installed” on the AHCI device. Now let’s continue fixing things:
- Uninstall the driver from the AHCI device and let Windows re-detect hardware.
- Chances are Windows will pick up the right AHCI driver; if not, install manually.
- Optional: Reboot and make sure the drivers are all properly loaded before moving the drive.
- Move the SATA drive from the SAS HBA to the onboard port, remove SAS HBA, boot up. If nothing went wrong, XP will now successfully boot.
Here’s what things look like after fixing the drivers: The AHCI driver is loaded, and the separate chipset IDE controller works as well.
For the sake of completeness, I decided to also fix the IDE drivers while I was at it. With the onboard SATA configured for IDE and Windows still booted from the SAS HBA, I uninstalled the SATA controller device and let Windows install the standard IDE drivers for it.
Now the existing XP installation that didn’t boot in either AHCI or IDE mode on the DX975XBX2 board works both ways. Mission accomplished! And I have to say, this is so much easier with Linux.
Now that my XP install was working on the Bad Axe 2 board again (and probably better than before, because I don’t think it previously worked in both IDE and AHCI mode), it was time to fix it for the DX79SR Stormville board.
That was slightly more involved. As previously mentioned, I never could find a functioning XP AHCI driver for the Patsburg chipset in the Stormville board, so booting in AHCI mode was not expected to work. But in IDE mode, the iaStor.sys driver was crashing the OS. So again there was a multi-step process:
- Plug the SAS HBA in the DX79SR board, attach the Windows drive to it.
- Set the onboard SATA controller to AHCI mode so that XP wouldn’t crash at boot.
- Once booted, uninstall any non-functional AHCI driver and rename \Windows\system32\drivers\iaStor.sys so that it couldn’t load.
- Switch onboard SATA controller to IDE, boot up XP again, still using the SAS HBA.
- The OS now boots up, but the drivers are still messed up. Uninstall the SATA/IDE controller device, let Windows install the standard IDE drivers for it.
- Plug the drive into the onboard SATA port, remove SAS HBA, reboot.
- XP now boots again (finally!), rename iaStor.sys back as it will no longer cause harm.
The XP install was now functional on the Stormville board again. For reference, here’s the utter disaster that manually forcing the AHCI driver on to the SATA IDE controller caused:
Moral of the story? If anything, it’s that it is much better to work with the Windows PnP subsystem than against it. Also, having a separate boot-capable storage controller on hand can be a lifesaver. And I’m really glad that I didn’t have to throw out that XP install and start from scratch.
Based on helpful reader comments, I adapted a method to cleanly manually add Intel AHCI support to an existing Windows XP installation. This was tested in a VirtualBox VM. Here’s the recipe:
- Install Windows XP on an IDE controller (or really any non-AHCI controller)
- Copy iaStor.sys from your favorite Intel AHCI driver package to \Windows\system32\drivers
- Run the following command with sufficient privileges in order to get the iaStor.sys driver loading at boot time:
sc create iastor binPath= \SystemRoot\system32\DRIVERS\iaStor.sys start= boot type= kernel group= "SCSI miniport"
Please note that the bizarre spacing around the equals signs is required. The service could be created through a regedit script, too.
- Save the following regedit snippet as, say, intel_ahci.reg and again run it with sufficient privileges:
Should cover any Intel AHCI SATA controller
That should work for any Intel AHCI controller since it only matches by PCI vendor ID and device class.
- Reconfigure the system so that the boot drive moves to the Intel AHCI controller.
- Once Windows boots up from the new AHCI controller, install the AHCI driver package using standard PnP procedures.
Note that unlike the recipe this is based on, it’s meant to be run on the system that is about to be switched to AHCI, but (obviously) while it’s still booting from a different controller.
And unlike manually forcing the AHCI driver onto an existing IDE controller, this method has the major advantage of not destroying the ability to boot from the original storage controller. Once the AHCI driver is in place, the boot drive can freely move between IDE and AHCI and continues booting.
Ugh, the one thing I hated about 2000/XP, moving an install to a different disk controller. I’m so happy newer Windows versions fixed this. Even UniATA couldn’t fix this problem (yet?): http://alter.org.ua/soft/win/uni_ata/uniata_pnp.php
Yeah, it was terrible. Microsoft’s official recommendation was “reinstall Windows”. No other OS was as stubborn. I remember how XP would even blow up if you had the audacity to install on one flavor of a PCI IDE controller and later switched to a different one. Basically even if you had all the drivers in place, it might still not work. OS/2 was ironically much easier to work with in this regard because it was much dumber.
I’m actually not sure how much Vista fixed the problem vs. avoided it in 99% of cases by providing a generic AHCI driver.
Yuck, what a mess. Such was life in the old days when you tried to DIY “Windows To Go”.
I was over the moon when Windows 8 came along, so we don’t have to deal with horrors like this anymore. I still keep my HDC_UNIVERSALISE.REG file around (which does little more than change Start to 1 for a bunch of drivers in HKLM\SYSTEM\CCS\Services) for the stubborn Windows 7 users I know.
Does Windows 8 actually solve the problem for good?
The real problem with the older versions (definitely XP, AFAIK Windows 7 as well) is that PnP does not fully kick in during boot. You have to tell Windows which drivers it should load at boot time, and exactly those drivers will be loaded regardless of what the detected hardware is. This is complicated by PnP doing some work, which enabled Microsoft to achieve the amazing feat of force-loading the PCI IDE disk driver and then refusing to use it because the hardware has the wrong PCI device ID.
So does XP (in normal non broken situations) not function if you set both pciide.sys and iastor.sys to 1 for a start type?
Was this method of forcing the driver onto the wrong controller done to add the iastor driver to the system so that XP will survive the next boot with the mode flipped to AHCI?
I know Lenovo’s Intel Matrix Storage Manager driver came with a PREPARE folder that includes an inf to add iastor.sys to the registry. I’ve modified that script in the past to add support for other hardware IDs that weren’t in there initially, usually splicing information from the proper inf for hardware with that prep inf.
It does work with pciide.sys and iastor.sys both loading at boot time. In fact that is common with the Intel chipsets that have both SATA and IDE controllers (quite common).
And yes, the method of forcing the driver onto the wrong controller was used exactly so that iastor.sys would load at boot time. It would load early and find the AHCI controller, and the boot process would be able to continue. Later on, the OS would do the PnP detection and install the drivers for the right chip (that is a big part of why the XP PnP is so broken, it only fully works after boot!).
The major downside, as explained in the article, is that this methods breaks the IDE boot functionality because it destroys the IDE controller’s driver stack.
Yeah the preparation script bundled into Lenovo’s IMSM drivers would be a cleaner method.
The T60ish family one is below:
It contains all the registry information needed to add iastor without the controller being present/active.
I’m somewhat tempted to try this manually. It should be possible to install the iastor.sys service (driver) and set its start type without messing with the PnP nonsense at all. I’m not surprised that Lenovo figured out a better way, because pretty much any alternative has to be better.
CriticalDeviceDatabase section in 2k/xp/2k3 registry controls which pci id will force load which driver f.e. iastor.sys
This helps me a lot transferring Windows XP or Server 2003 bootable hdd over different either raid or ahci systems. I use iastor.sys version 11.2. I’ve also as you mentioned collecting and using Intel-branded desktop boards. DP43BF/DG33FB/DH77EB and so on…
Just add entries there with pci id’s and code to start iastor.sys in addition to atapi.sys
>Does Windows 8 actually solve the problem for good?
I don’t know for an absolute fact – corner cases and all – but after a few hundred installs on 50+ differently-configured machines, I’m yet to see STOP 0x7B (or 0x7E for that matter) on anything after Windows 7.
I was always under the impression that boot-start services (that is, drivers) are supposed to simply not do anything if they don’t find the hardware they’re expecting. I’ve never really looked into WHY Windows 8+ is more tolerant of the storage subsystem changing out from under it; I just assumed that it was because Microsoft made a whack of mass storage/miniport/whatever services boot-start – as the various “universalise” .REG files floating around do.
It could be a coincidence since Windows 8 (or at least 8.1) supports IDE, AHCI, and NVMe out of the box, and should thus cover all common storage controllers.
The “drivers should not do anything if they don’t find their hardware” thing is definitely true, and that is how it’s been since the beginning or NT. It is also what the NT installation CDs have relied on for ages, the boot process tries to load tons of storage drivers and most of them simply do nothing since they find no hardware.
Thanks, I updated the post with an addendum that’s based on the richud.com recipe, but adapted to work with an existing booted OS rather than Hiren’s Boot CD or similar. It really does work nicely and cleanly, without blowing up the IDE boot capability.
I can somewhat get that Microsoft didn’t want to touch something that “works” – i.e. risking force starting drivers that might cause some kind of trouble. But it’s surprising that the boot process just stops with a blue screen if it can’ find the boot device, instead of just attempting to start every driver for any bus better than ISA and reattempt the boot. Later on during boot when the desktop is in a usable state it could run something that will set the correct configuration for autostarting drivers early on.
This is one of the downsides of the closed source seldom-update cycles. There are both upsides and downsides, but in this case it’s mostly a downside.
Btw it would be nice if there were any way to pass boot options to Windows with a list of device drivers to force load. Sure, there aren’t any easy way to enter boot options during boot – that needs disk editing – but it would still be better than nothing.
I wounder if all of this at least partially were due to business decisions and not due to some technical issue? By causing this kind of trouble they made it a tiny bit harder for anyone to pirate copy an image of an existing system. They could also charge hardware vendors for including their drivers with Windows and also for the “certified for…” thingy.
As a side track, my impression is that Mac OS X handles these issues as good as for example Linux.
I doubt it was a business decision beyond “let’s not spend time on this”. The NT boot process was somewhat inflexible which probably goes back to the fact that it is a circa 1990 design. It certainly inconvenienced NT customers, I really don’t think they were happy to be told “sure you can upgrade your SCSI HBA, all you need to do is reinstall the OS”. Which was the standard Microsoft advice, even with a so-called PnP OS like Windows 2000.
The craziness of XP not (by default) surviving a move to a different IDE controller is something that certainly caused $millions of damage worldwide. Here you have to keep in mind that NT (including XP) failed to boot even if both old and new driver came on the installation CD, and even if the driver for new hardware was actually installed on the disk. It was just that the system couldn’t figure out that it should be loaded.
OS X just re-discovers hardware on every boot and loads whatever drivers (KEXTs) it can find, so yeah, it is pretty PnP. AFAIK OS X can handle things like switching the boot disk between AHCI and IDE just fine.
I guess NT5 was already a project taking years to develop.
Michal: Someone by the name of MovAX0xDEAD has managed to port the generic AHCI driver (along with the genric USB 3.0 and NVMe drivers) from Windows 8 to XP!
If you want to see an example of it in use, Windows XP Integral Edition comes with a patcher to add it to its install iso, but that patcher works on a regular XP setup iso as well. (Although it doesn’t actually install the driver unless you initially install on an ACHI system.)
You may want to have a look. The github for the port is here:
If you want to see how XP Integral Edition is using it, the latest version can be found here; the zip includes the iso, the patch batch file, etc :