Booting Windows XP, Or Not

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 9.6.0.1014) and IASTOR7.sys (11.2.0.1006). 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 !drvobj iastor7).

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 !devnode command:

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[05] = DeviceNodeQueryStopped (0x309)
...
StateHistory[10] = DeviceNodeStarted (0x308)
StateHistory[09] = DeviceNodeEnumerateCompletion (0x30d)
StateHistory[08] = DeviceNodeStarted (0x308)
StateHistory[07] = DeviceNodeEnumerateCompletion (0x30d)
StateHistory[06] = DeviceNodeStarted (0x308)
Flags (0x000000f0) DNF_ENUMERATED, DNF_IDS_QUERIED,
DNF_HAS_BOOT_CONFIG, DNF_BOOT_CONFIG_RESERVED

Sure enough, PCI\VEN_8086&DEV_27C1 is the ICH7DH SATA device in AHCI mode, but there’s no way it can work with the pciide driver.

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[00] = DeviceNodeUninitialized (0x301)
StateHistory[19] = Unknown State (0x0)
...
StateHistory[01] = 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:

Again, 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.

Addendum

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:

1. Install Windows XP on an IDE controller (or really any non-AHCI controller)
2. Copy iaStor.sys from your favorite Intel AHCI driver package to \Windows\system32\drivers
3. 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.
4. Save the following regedit snippet as, say, intel_ahci.reg and again run it with sufficient privileges:
   
   REGEDIT4
   ; Should cover any Intel AHCI SATA controller
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&CC_0106]
"Service"="iaStor"
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
   
   That should work for any Intel AHCI controller since it only matches by PCI vendor ID and device class.
5. Reconfigure the system so that the boot drive moves to the Intel AHCI controller.
6. 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.