Fix a Windows boot loop with AHCI

My wife’s computer was stuck in a Windows boot loop. We’d get the Windows 7 boot screen, and it would display a single pixel of the Windows 7 logo, then reboot itself endlessly. Booting in safe mode made it fail on classpnp.sys.

Any number of things can cause this, and it usually happens after you swap a motherboard. Enabling AHCI turned out to be the fix. Enabling AHCI also can be easier said than done, but I figured it out. She’s running Windows 7 (for now) but these same tricks should also work for Windows 10.

The classpnp.sys red herring

The clue was that when I tried to boot in safe mode with a command prompt, it died on classpnp.sys. That’s a red herring, because it’s the storage driver it loaded just before classpnp.sys that was failing and making the boot fail with it. A tempting as it is to replace classpnp.sys, it’s not going to help.

Serial ATA can operate in several modes. “Native” mode emulates older parallel ATA controllers. AHCI is one of the modes that enables higher performance, partly because it enables advanced features like NCQ and TRIM. Why did I use native mode instead of AHCI when I built this machine? I have no idea, especially since the system has an SSD in it. SSDs use a lot of AHCI features. I probably meant to go back and change it and never did. I had already aligned the SSD.

Why couldn’t I just switch the BIOS back to native mode? I tried, and then the BIOS couldn’t find the boot drive. So why did it ever work in the first place? I wish I knew.

Older versions of Windows used to bluescreen and tell you what failed, but Microsoft changed this behavior at some point. The blue screen wasn’t friendly, but it gave you enough that a quick Google search could usually tell you how to fix it. The new approach works better when the condition is temporary. In this case, it makes things harder.

The quick fix

A lot of people tell you to run System Repair from your Windows boot media to fix problems like this. I did just that, numerous times, but all I got was an error code 0x490 with a status message: a patch is preventing the system from starting.

The usual fixes for reversing a bad patch didn’t work, so I won’t repeat those here.

By far the best thing to do is enable AHCI in the machine’s BIOS or UEFI (whichever it has) and enable Windows to also use AHCI. It’s faster, and apparently, more reliable.

For a quick fix, flip between native and AHCI modes in your BIOS if you’re having this issue. If you’re luckier than me, you can just change modes and render the system bootable again. Then you can enable AHCI in Windows (more on that at the end), enable it in your BIOS, and get on with life.

In my case, since Windows wouldn’t boot, I had to figure out how to get into the registry and enable AHCI within an unbootable copy of Windows.

Enable AHCI on a dead Windows install

Enabling AHCI on a dead Windows install takes some doing but it’s possible. I wrote Hiren’s Boot CD to a USB stick using YUMI. I booted into the mini XP environment, then clicked HBCD Menu. From there I navigated to Programs, Registry, Registry Editor PE.

Registry Editor PE works a little differently from Regedit inside of Windows. It first prompts you to find your dead Windows folder. It will usually be C:\Windows, but your machine may vary. Then it will prompt you to load the SAM hive. Pick the filename SAM with no extension, which should be in the list. Next, it will prompt you to load the Security hive. Again, pick the filename Security with no extension. Then it will prompt you to load the Software hive. Again, pick the filename Software with no extension. Finally, it will prompt you to load the System hive. Once again, pick the filename System with no extension. It will then ask you if you want to load a user profile hive. Click No. It will tell you when it’s finished loading the files. Click OK.

After it loads the registry files, it starts looking a lot more like the regular Windows standby Regedit.

Locate and then click the two registry subkeys:

HKEY_LOCAL_MACHINE\_Remote_ System\ControlSet001\Services\Msahci

HKEY_LOCAL_MACHINE\_Remote_System\ControlSet001\Services\IastorV

In the pane on the right side, right-click Start in the Name column, and then click Modify.

In the Value data box, type 0, and then click OK.

On the File menu, click Exit to close Registry Editor.

If you don’t have both IastorV and Msahci on your machine, just modify the one you have. Yes, counter-intuitively, a value of zero enables AHCI.

Enable AHCI on a working Windows install

It’s much easier to enable AHCI on a system where you’ve coaxed Windows into booting. Hit the Windows key+R to bring up a Run prompt. Type regedit and hit Enter to launch Regedit.

Locate and then click the two registry subkeys:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IastorV

In the pane on the right side, right-click Start in the Name column, and then click Modify.

In the Value data box, type 0, and then click OK.

On the File menu, click Exit to close Registry Editor.

Again, if you don’t have both IastorV and Msahci on your machine, just modify the one you have. Reboot your machine, go into the BIOS and enable AHCI, and your system will boot normally.

This step isn’t strictly necessary, but you’ll get better performance, especially with an SSD. And you won’t get a mystery the next time the setting changes for some odd reason. I don’t mind you coming back here and reading this again, but you might.