Mega-ZBlog

In the spirit of the The Case of the… blog posts by Mark Russinovich, I am going to post about a particularly vexing problem I had over the past few days.

It all started when I decided I wanted to try out the latest public build of the Windows 10 Technical Preview, that being build 9879. I installed to VHD (it’s not really relevant to this story so I won’t go into details; it’s very easy to test and clean up while booting from a VHD though) and made sure my bootloader was configured to natively boot from the VHD. Then I rebooted.

I had some weird issues with setting everything up in Windows 10 but I figured I would resolve them the next day… I should have started earlier. I put the system to sleep and went to bed.

At 4:45am my computer spontaneously woke up, waking me up. It sat on a “Recovery” screen complaining it could not load winload.exe.  I did not want to deal with this at 4:45am on a Sunday and so hard powered the system off.

Next morning, powered the system on… I was met with the same screen.

Whatever, Windows 10 ate itself, I’ll just boot back into Windows 7. Thankfully even though this screen shows up before the Windows 8/10 GUI bootloader, it helpfully has an option to boot from the next OS instead. I chose it.

Windows 7 boots… and most of my desktop/taskbar icons are missing, most startup programs are missing, and the ones that do run either crash or scream at me that something on my second hard drive can’t be found.

I open My Computer… and two of my hard drives are gone. Disk Management… not there either. Device Manager… nope.

At this point I fear the worst, but I figure it is probably a weird Windows 10 side effect. One of the drives had hit a SMART error some weeks ago (and I had already replaced it, the data is now duplicated to another drive) but the other contained all my application files, user files, and plenty of misc files: downloads, photos, virtual machines, my website backup… anything important was backed up but it would still be a pain to replace.

First thing I tried was to use the bcdboot tool to regenerate the bootloader files. I did so and rebooted… other than the Windows 7 bootloader now popping up and allowing me to boot into Windows 7 directly, nothing changed. The next step was to completely remove Windows 10 (I was certain at this point I was no longer interested in beta testing it!) which was trivial with the VHD setup I’d used. Of course the problem still remained, most likely establishing Windows 10 had done something permanent.

Fortunately, a quick Google revealed this was not an isolated incident, and quickly got me up to speed on what had happened to me.

The summary is that Windows 10 9879 seems to like to enable Power Up In Standby, or PUIS, on drives even when the BIOS or motherboard doesn’t support it. When this happens the BIOS has no way to know the drive hasn’t powered up, and simply sees a malfunctioning drive it can’t query. Windows, in turn, can’t see the drive at all.

Ironically, Linux will automatically tell any spun-down drives to spin up, so Linux can use them just fine even without the BIOS support, it seems. However this solution only works until the next time you power off, when the drives will once again spin down until something explicitly tells them to spin up (most likely Linux).

I didn’t realize this at first and was just happy to get my drives back after booting an Ubunto LiveCD then rebooting into Windows 7. Next time I woke up my PC though, the Windows kernel bluescreened (likely because I kept a page file on one of the drives). A reboot later revealed the problem was still there. I didn’t have time then to fix it but I did enough research to find out the issue was with the PUIS setting on the drives, and that there were tools to adjust that. I also noted that the BIOS timed out querying the drives on boot, which gave me a quick way to see if any solution I tried was working or not.

That night after work I tried HDAT2 and Hitachi’s Feature Tool (both drives of mine that stopped working were Hitachi). I had various issues with the CD version of HDAT2 being unable to find my CD drive (an issue with MS-DOS bootable CDs, they need the proper drivers) and a USB-stick bootable Feature Tool hanging on boot. Eventually I got them boot running on a USB stick (aell, a 16MB SD card pretending to be one) and a CD respectively, however HDAT2 could not identify my hard disks and so refused to give me the option to issue commands to them. Hitachi’s tool couldn’t see my SATA-connected drives at all.

Then I was looking for any other tools I could use, I found a reference to hdparm, a Linux-based tool. Then I had an epiphany.

“If Linux fixed the problem originally, clearly I only need to use MORE LINUX for a permanent fix!”

Spoiler: It goes just as well as I’d hoped.

After booting from the Live CD I had used earlier, I found hdparm already installed. After 5 minutes of figuring out syntax and ensuring I had identified the correct block files for the drives, I cleared the PUIS flags from both of them.

Then I shut down the system… waited… and booted back up…

The BIOS happily identified both drives and booted back into Windows, where all my disks were available.