Part 1 – The sad story
Chris and I went to a client’s site today to do some requirements capture – thank goodness it wasn’t a demo. We both have Shuttle PCs which I love, and we just ask the client to find a monitor or two and maybe a keyboard and mouse for the duration of our visits. The result is we have workstation-grade developer machines which are semi-portable. The trouble is, my new Mazda 3 MPS has quite a firm ride, and Shuttle have stopped making the excellent PF60 XPC-2-GO carry bag, so I had Chris’s PC on the floor in the back of the car which was the best place I could think of so it wouldn’t bang about. Anyway, I think that at some point on the journey, the little CR3032 battery which keeps the NVRAM in Chris’s PC must have slipped, because when we arrived and plugged it in we got that innocuous message along the lines of “CMOS Error: Press F2 to continue or Del to enter setup”.
Now, usually when the happens, you do the “Enter Setup” option, make sure any particular tweaks you like are applied, save it and off you go. Not this time – it POST tested, went to boot, and got nothing but a blinking cursor on a black screen. I spent ages mucking around with boots orders and BIOS settings, but no – nothing worked. Eventually we came home early with tails between our legs, as it were. While I couldn’t see how, the disk appears to be b0rked. We’d been warned about SSDs…
Part 2 – The investigation and the cause
Back at base I ran up Chris’s Crucial C300 SSD in a StarTech eSATA USB to SATA External HDD Dock attached to the eSATA port on my Shuttle SD329P2. It appeared OK in disk manager, so I copied off everything of interest. I also ran ChkDsk, but it came up clean. Then something caught my eye – in DISKPART, I noticed it was a GPT – Guid Partition Table drive. Now this confused me, because I thought they weren’t bootable. For a while, we scratched our heads wondering how it got to be GPT by accident.
It turns out that Chris’s new Shuttle SH67H3, like many (most?) machines with the Intel Sandy Bridge chipset has a BIOS which supports UEFI – Unified Extensible Firmware Interface. There are some key facts to realise in this situation:
- The BIOS can boot devices in either old-school BIOS mode or new-skool UEFI mode.
- UEFI provides non-volatile storage for boot configuration, which is (typically) written to by the OS installer
- Unbeknown to me, when I originally installed windows, I had booted a Windows 7 x64 DVD with SP1 slipstreamed into it in UEFI mode. When I installed onto an unformatted SSD, it must have quietly initialised it as a GPT disk and written the boot configuration to the CMOS NVRAM
So, when the NVRAM got lost, so did any evidence of how to boot the PC. And unlike the old days with MBR, no amount of fiddling with the BIOS screens was going to write it back there. The penny started to drop when I realised that, with the Windows 7 x64 SP1 DVD in the drive, the boot menu gave me a choice of two options to boot off the DVD, “P3: ATAPI iHAS122” and “UEFI: ATAPI iHAS122”. When there was no disk in the DVD drive, there was no UEFI choice. When the P3: option (I assume this meant “BIOS-mode SATA Port 3”) was selected, the Windows installer started, but then selecting the Repair option came up with:
This version of the System Recovery Options is not compatible with the version of windows you are trying to repair
That’s because it had booted in BIOS mode, and couldn’t understand the idea of bootable GPT disks.
Part 3- The solution
After changing the boot order in the BIOS to prioritise the UEFI: version of the DVD drive, we were able to see and select the Windows 7 installation. After that, all it took was the first option to run Startup Repair:
This, among other things, writes the boot configuration back to the UEFI NVRAM, and that’s it – you’re done. Interestingly, it creates a new entry in the list of bootable devices in the BIOS called “Windows Boot Manager”, and it’s that which was lost when the CMOS got cleared…