SOLUTION: “The requested system device cannot be found” on UEFI systems

With GPT disks and UEFI all the rage now, it’s not uncommon to encounter a scenario where boot parameters need to be repaired in order to reach the operating system.  Generally speaking, it’s often easy enough to accomplish this by executing the command bcdboot X:\windows (where X is the system drive letter) from a recovery environment.

However, other times, even in spite of this command properly completing, the system still will not boot.  In many cases the failure is evident when attempting to perform bcdedit /enum and receiving a message such as this one:

The boot configuration data store can not be opened.
The requested system device cannot be found.

Performing bootrec /fixboot also provokes the following error:

Element not found

This is bad news on a GPT disk using UEFI rather than BIOS.  Essentially, the system is looking for the EFI partition, which in this case is either missing or corrupt.

If it’s corrupt but still exists, you can simply enter diskpart, select the system partition (usually around 500 MB in size and with an ID of “EFI”) and assign it a letter, exit diskpart, and then perform a chkdsk command on the new partition assignment.  This sometimes will correct it.  Other times, forcibly removing the EFI and boot folders from the EFI partition and then executing the bcdboot command with a specific system partition parameter (e.g.: bcdboot X:\windows /s E:, where X: is the Windows partition and E: is the EFI paritition) works.

But let’s say the partition is missing altogether.  This is most often the case following a drive image using imaging tools to a new SSD for example.  Sometimes the tools (especially if executed externally on another system rather than live within the target OS) will remove the EFI partition and only image the Windows partition.

If this happens, most people will tell you that you will need to reinstall Windows from scratch.  However, all is not yet lost!  It’s fixable — but in order to accomplish it, you must recreate the EFI partition manually and then reload the boot parameters from there.

Here’s how it’s done at a command prompt from a recovery environment.  I’ve bolded the commands I typed to make it easier to read — hold on tight:

X:\windows\system32>diskpart

Microsoft DiskPart version 10.0.10240

Copyright (C) 1999-2013 Microsoft Corporation.
On computer: MININT-3A416N9

DISKPART> list disk

Disk ### Status Size Free Dyn Gpt
——– ————- ——- ——- — —
Disk 0 Online 489 GB 0 B *

DISKPART> sel disk 0

Disk 0 is now the selected disk.

DISKPART> list part

Partition ### Type Size Offset
————- —————- ——- ——-
Partition 1 Primary 489 GB 1024 KB

DISKPART> sel part 1

Partition 1 is now the selected partition.

DISKPART> shrink desired=1024

DiskPart successfully shrunk the volume by: 1024 MB

DISKPART> create partition efi size=260

DiskPart succeeded in creating the specified partition.

DISKPART> format quick fs=fat32

100 percent completed

DiskPart successfully formatted the volume.

DISKPART> exit

Leaving DiskPart…

X:\windows\system32>bcdboot c:\windows
Boot files successfully created.


Following these steps, the machine should now be bootable.  If it’s not, it’s probably time to call a professional!

Good luck!

 

Solution: STOP Error 0x0000007b (0xfffff880009a98e8 0xffffffffc000000d 0x0000000000000000…)

Hoo boy, this one’s a doozy.

So following the removal of certain rootkits (such as Rootkit.Boot.SST.a, which is associated with the Windows Recovery rogue), you may find that your Windows boot configuration data has been totally corrupted. Worse yet, the usual steps to remedy (such as those described in my earlier post about TDL4 and the resulting blue screen) all fall apart when you reach the bootrec /RebuildBCD command, which returns the message:

Total identified Windows installations: 0

Geez.  This essentially means that the bootrec command cannot identify your Windows installation, even though the Windows Recovery Environment has no trouble doing so upon starting.  So, now what?

Sometimes it’s as simple as opening up your favorite disk partitioning software and marking the C: partition as ACTIVE, and if there are still problems, subsequently recovering the boot data as I mentioned in the TDL4 post (keep in mind however that the System Managed partition is typically Active normally on a Windows 7 system thanks to the isolated boot partition that it uses).  This problem occurs because of some modern rootkits which create a hidden, encrypted partition at the end of the system drive and mark it as Active and Primary (while simultaneously marking the standard boot partition as Inactive).  This infection has been covered in other recent blog posts as well.

Sometimes, however, the BCD is totally corrupted and this doesn’t even work.  At this point, most every source on the internet comes up a dead end.  Everyone ends up reformatting or reinstalling Windows overtop their existing partition; nothing else seems to work.

You might not think it’d be helpful, but there’s an intimidating post over at the EasyBCD NeoSmart site which explains how to manually rebuild the Vista bootloader from the ground up in catastrophic situations.  As it turns out, this procedure applies to Windows 7 as well (which uses the same bootloader and BCD structure), and it’s the key to your recovery here.

It’s no easy feat however, so roll up your sleeves and get ready to do some typing.  Here’s the full procedure from start to finish:

  1. Boot to the Windows Recovery Environment either by selecting Repair Your Computer when Windows fails to boot, by inserting the Windows installation disc, or by using a Windows ERD/MS DART disc (if you happen to have access to one, that is).
  2. Cancel the recovery attempt if it tries to start on its own (it will fail anyway) and then choose the advanced options link at the bottom of the window.
  3. Choose to open the Command Prompt.
  4. Here’s the fun part.  Once at the prompt, enter the following commands one by one.  Take care not to mistype anything, and be sure to replace C: with whatever your system drive happens to be:

bootrec.exe /fixmbr
bootsect.exe /nt60 all /force
bcdedit /export C:\BCD_Backup
attrib -h -s C:\boot\BCD
ren C:\boot\BCD BCD.old
bcdedit /createstore c:\boot\bcd.temp
bcdedit.exe /store c:\boot\bcd.temp /create {bootmgr} /d “Windows Boot Manager”
bcdedit.exe /import c:\boot\bcd.temp
bcdedit.exe /set {bootmgr} device partition=C:
bcdedit.exe /timeout 10
attrib -h -s C:\boot\bcd.temp
del c:\boot\bcd.temp
bcdedit.exe /create /d “Windows 7” /application osloader

At this point, note the value within the curly braces {……..} as you will need it during the next steps.  Replace the dots within the curly braces below with that entire string on each line.  NOTE:  To make this easier, once you type it once, you can press the Up arrow to restore the last command and simply edit that line for the next one.

bcdedit.exe /set {…..} device partition=C:
bcdedit.exe /set {…..} osdevice partition=C:
bcdedit.exe /set {…..} path \Windows\system32\winload.exe
bcdedit.exe /set {…..} systemroot \Windows
bcdedit.exe /displayorder {…..}
bcdedit.exe /default {…..}
bcdedit.exe /set {…..} locale en-US

Thanks to Bitt Faulk for the final line, which restores the correct Windows loading screen as well.  You will need to replace the en-US entry with something different representing your region if you are not in the US.

Then you’re back in Windows, miraculously.  No reinstall necessary!

Side effects?  A little.  Hopefully you can handle not having the nifty new Windows 7 startup animation screen, because this will lose it for you.  Instead, you’ll be stuck with the old-school plain Jane Windows Vista progress bar.  You’ll also lose any special boot options you had previously.  But as a last resort, this works, and it’s still just as quick as ever.

Apart from that, once you’re back in Windows, of course, you’ll still have to disinfect the rest of the way.  In my customer’s case, the system damage was actually so bad that I ended up performing an in-place upgrade (the Vista/7 equivalent of a Repair Install), but after that, everything was great.  It was a triumph for sure, and yet another situation where the usual solution of reformat/reinstall was not necessary.  Now you know how to avoid it!

I hope you’ve found this post useful–if so, please take a moment to leave me a comment!

If you need computer help in the Louisville, KY area, there’s simply no one better.  Give me a call today!