Skip to main content

64 bit - Windows 8.1 UEFI x64 is not able to boot-up UEFI Images


The question appeared after asking this one. It seems that the Win8.1 UEFI x64 Boot Manager is unable to boot anything other than the windows itself (winload.efi). Trying to launch any other UEFI image (.efi) from it gives the error code 0xC000007B and I'm pretty sure that this isn't because of a missing file but instead because the file is 'invalid' as when I rename that file the error changes to 0xC000000F. I have disabled the secure boot but without any luck.


At the moment I'm trying to integrate the rEFInd bootloader. I can say that it's UEFI image is working as it is able to boot from a USB flash drive using the firmware. Using the Windows Boot Manager however give the same results explained above (error code 0xC000007B). At the moment my BCD configuration is (picture):


Command line screenshot http://imageshack.com/a/img811/7857/kbth.png


As F:\rEfit\refind is the directory where refind is stored and "refind_x64.efi" is the program image.


NOTE: I'm also wondering are only UEFI images (.efi files) allowed to boot in an UEFI Windows and also what is the format of the non-UEFI one's (like ntldr, bootmgr)?


EDIT: Moving rEFInd to a standard directory ("EFI") didn't solved the problem.



Answer



After 1 year I came across the same problem again. Luckily this time I found a solution. In order to add an OsLoader in windows Boot-Manager which loads non-Windows UEFI images you need to manually edit BCD registry. In RegEdit there is a key named "HKEY_LOCAL_MACHINE\BCD00000000" - which is loaded from Windows EFI System-Partition and editing it's subkeys directly edit the BSD file. There is a key named "Description" under it but we'll focus on the other one named "Objects". Under it you need to a new object (or modify existing). Then under the target-object-GUID-name you need to edit the "Description" Type value to "0x10100003" (which means firmware application osloader - credits for this find go to this page). That's it - then the 'path' and 'device' elements of this object specify an UEFI file which will be loaded when the OS-Loader is selected.


BIG WARNING:


Don't do the above just to test it - loading an Uefi this way burns it down into the Uefi Boot configuration and after loading - you may wouldn't be able booting to Windows again (unless the app you loaded doesn't reset the Uefi Boot Cfg) - so use this only if you're sure about it.


I did so and then I should manually fix my Windows boot-up using Uefi Boot Cfg. Which is prefered to use.


EDIT: I forgot to add that you first need to own permission for editing "HKEY_LOCAL_MACHINE\BCD00000000", which is easy - just click Properties on it and change permissions ;).


EDIT: This discovery shows that the most powerful (and easy - at least for me) way of editing Windows BSD is using the registry. The behavior I accomplished by doing so - isn't possible to be done using BCDedit, neither the BCD WMI.


Comments

Popular Posts

How do I transmit a single hexadecimal value serial data in PuTTY using an Alt code?

I am trying to sent a specific hexadecimal value across a serial COM port using PuTTY. Specifically, I want to send the hex codes 9C, B6, FC, and 8B. I have looked up the Alt codes for these and they are 156, 182, 252, and 139 respectively. However, whenever I input the Alt codes, a preceding hex value of C2 is sent before 9C, B6, and 8B so the values that are sent are C2 9C, C2 B6, and C2 8B. The value for FC is changed to C3 FC. Why are these values being placed before the hex value and why is FC being changed altogether? To me, it seems like there is a problem internally converting the Alt code to hex. Is there a way to directly input hex values without using Alt codes in PuTTY? Answer What you're seeing is just ordinary text character set conversion. As far as PuTTY is concerned, you are typing (and reading) text , not raw binary data, therefore it has to convert the text to bytes in whatever configured character set before sending it over the wire. In other words, when y...

linux - Extract/save a mail attachment using bash

Using normal bash tools (ie, built-ins or commonly-available command-line tools), is it possible, and how to extract/save attachments on emails? For example, say I have a nightly report which arrives via email but is a zip archive of several log files. I want to save all those zips into a backup directory. How would I accomplish that? Answer If you're aiming for portability, beware that there are several different versions of mail(1) and mailx(1) . There's a POSIX mailx command, but with very few requirements. And none of the implementations I have seem to parse attachments anyway. You might have the mpack package . Its munpack command saves all parts of a MIME message into separate files, then all you have to do is save the interesting parts and clean up the rest. There's also metamail . An equivalent of munpack is metamail -wy .

ubuntu - Why does my USB hdd returns SG_IO: bad/missing sense data?

I am able to boot and run commands from external USB hdd; the message in question appears for about 45 seconds then booting continues. GRUB2 is installed on internal HDD. When choosing to boot directly to /dev/sdb the message doesn't appear, however boot time is about the same as booting to internal HDD. /dev/sdb: Timing cached reads: 1018 MB in 2.00 seconds = 508.97 MB/sec Timing buffered disk reads: 80 MB in 3.03 seconds = 26.37 MB/sec pfeiffep@de:~$ sudo hdparm -i /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 10 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 HDIO_GET_IDENTITY failed: Invalid argument Gparted correctly identifies the drive as SAMSUNG MP0402H. Any ideas how to remedy the HDIO & SG_IO messages?

Desktop reboots itself on sleep or hibernate

I have been using an ASUS M2NPV-VM motherboard for main home desktop workstation, operating Windows Vista x64. This computer has right from day one not been able to enter hibernate or standby; after Windows performs its final actions and brings the machine down, it would automatically revive itself for a reboot. Updating to the second latest BIOS (1201)has not helped (the latest BIOS revision would induce video refresh problems rendering it unusable). I have been reading related discussions on incidents similar to mine to no avail of a true workable solution. They appear to be more speculative guesses rather than actual knowledge on the inner workings of motherboard hardware. Does anybody have any electronic engineering experience on PC energy-saving standards to provide a more informed opinion how to go about getting this to work? More stories: this motherboard could not even reboot properly the first thing i used it. It was due to refresh rate of the onboard GPU, which had no influe...