Prevent Windows from rewriting EFI & BCD

With regards to the issue of windows automatically recreating /EFI/Microsoft/Boot/bootmgfw.efi and /EFI/Microsoft/Boot/BCD is there a tested way to prevent this happening? If you have already come across this and solved it please share your work around.

some thoughts
1) restrict windows access to efi partition, without breaking booting (considering FAT32 so cannot apply perms)
2) make a service to /EFI/Microsoft/Boot nuke itself automatically
3) an API to prevent windows writing these files
4) stop windows updates completely (would like to avoid this however)
5) if all else fails BCD entry to launch grub2.efi

Edited by ndog37, 01 August 2017 - 10:58 AM.

1) Besides the many good things that Rufus does, Akeo wrote a NTFS filesystem driver for EFI/UEFI (which should allow to have the BCD and the various boot files on a NTFS volume).

Whether it will work on your setup or if some NTFS permission can actually prevent that, is another thing.

2) and 3) maybe a filter driver?

4) which seems like a good idea, actually.

5) Not a bad workaround, IMHO.

 

Please specify (as I believe ) that you are talking of Windows 10.

 

Wonko

With regards to the issue of windows

What*s your situation?
Which firmware (UEFI version and manufacturer release) do you use?

Does the UEFI firmware boot the first NVRAM entry?

Does the UEFI firmware boot a fixed windows file name?
e.g. \EFI\Microsoft\Boot\bootmgfw.efi

Does the UEFI firmware boot a default UEFI file name?
e.g. \EFI\Boot\bootx64.efi

Given one GPT disk with a single FAT32 EFI partition.
Create a second NVRAM entry and set this to default boot.
Example, adjust the GUID numbers {919*}


bcdedit /copy {bootmgr} /d "UEFI \EFI\Boot\bootx64.efi"
bcdedit /set {9190511b-779b-11e7-baff-ea3d13e64229} path \EFI\Boot\bootx64.efi
bcdedit /enum firmware
bcdedit /set {fwbootmgr} displayorder {9190511b-779b-11e7-baff-ea3d13e64229} {bootmgr} {91905113-779b-11e7-baff-ea3d13e64229} {91905114-779b-11e7-baff-ea3d13e64229} {91905115-779b-11e7-baff-ea3d13e64229} {91905116-779b-11e7-baff-ea3d13e64229}

mountvol s: /s

Copy grub2 files to the EFI partition.
S:\>xcopy e:\efi s:\efi\ /s /y
E:\efi\BOOT\grubx64.efi
E:\efi\BOOT\BOOTX64.efi
E:\efi\BOOT\grub.cfg
E:\efi\BOOT\fonts\unicode.pf2

notepad s:\efi\BOOT\grub.cfg
menuentry "UEFI: Windows /EFI/Microsoft/Boot/bootmgfw.efi" {
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

A Windows 10 monthly update is possible. Grub 2 is active still.
I doubt a Windows 10 upgrade installation (1607 to 1703), not tested. A windows startup entry 'bcdedit /set {fwbootmgr} displayorder *' may be useful.

Or does the strange firmware boot a NVRAM entry name "Windows Boot manager"?
Then try a almost duplicate name:
bcdedit /copy {bootmgr} /d "Windows Boot manager 2"
Does the machine boots this?



Upgrade installation Windows 10 1607 to 1703:
1703 DVD inserted, setup.exe launched.
At reboot the UEFI boots to grub still.
Windows 10 upgrade does keep the firmware default entry.
However the installation failed because of this.
Press shift F10, run bcdedit /set {fwbootmgr} displayorder {bootmgr}
Setup continuoes and 1703 is installed.

/efi/boot/bootx64.efi is preserved, not overwritten, it's the grub/shim file still.

run bcdedit /set {fwbootmgr} displayorder again, set grub2 as default
Grub2 to is the default boot entry again.


Addional idea:
Do not use the fixed UEFI name \EFI\Boot\bootx64.efi
Use a \EFI\Boot\shim.efi
bcdedit /set {9190511b-779b-11e7-baff-ea3d13e64229} path \EFI\Boot\shim.efi

HI Wonko and cdob,

 

Yes you are right, windows 10, is the culprit, it likes to break repair the EFI system after an update.

 

The option to keep the BCD file in \EFI\Microsoft\Boot seems to be the best, simply because on the various machines, HP acer etc, some machines force to boot \EFI\Microsoft\Boot\bootmgfw.efi, and the windows update continues to generate this file if not present

 

Does the UEFI firmware boot a fixed windows file name?
e.g. \EFI\Microsoft\Boot\bootmgfw.efi 

yes it does

Does the UEFI firmware boot a default UEFI file name?
e.g. \EFI\Boot\bootx64.efi

yes it does (as long as \EFI\Microsoft\Boot\bootmgfw.efi is not present)

and windows likes to restore itself either on boot, or installing windows 

 

 

I have the grub2.efi and grub2.cfg

/efi/boot/bootx64.efi

/efi/boot/grubx64.efi

/efi/boot/grub.cfg

 

working boot windows - as long as UEFI boots from \EFI\Boot\BOOTX64.EFI

load_env default

function load_video {
  insmod efi_gop
  insmod efi_uga
  insmod video_bochs
  insmod video_cirrus
  insmod all_video
}

load_video
set gfxpayload=keep

insmod gzio
insmod part_gpt

set timeout=4

menuentry "Windows 10 UEFI" {
set default=$1
save_env default
insmod chain
search --file --no-floppy --set=root /efi/Microsoft/win10/bootmgfw.efi
chainloader (${root})/efi/Microsoft/win10/bootmgfw.efi
}

After install windows 10 for example move the boot folder to win10

 

However I would like to assume that there is no BCD file, as this may be on a fresh machine.

 

I am trying to create the \EFI\Microsoft\Boot\BCD file to point at my shim.efi or bootx64.efi fallback loader, from a windows PE environment with no pre-existing BCD file, which is proving difficult. Because I am not good with the command line + the commands used don't seem to work, I have also attempted to use BOOTICE to generate the BCD file as such, however when booting it gets a 7b error. Will soldier on!

 

windows 10, is the culprit, it likes to break repair the EFI system after an update.

Yes, windows update replaces \EFI\Microsoft\Boot\bootmgfw.efi, but not \EFI\Boot\bootx64.efi. No idead about a upgrade currently.
In my opinion Windows may write to \EFI\Microsoft\. That's the operation system efi folder.

The hardware is broken: prefering \EFI\Microsoft\Boot\bootmgfw.efi creates a windows only machine for average end user. The clean solution would be to change the UEFI implementation, to be done by the hardware manufacturer.
Yes, it's simpler to change the OS part.


https://h30434.www3....tu/td-p/2503733

There is some sort of a "recovery feature" or so that on every boot sets the very first UEFI load option to point to one of the two locations, in this order:
\EFI\Microsoft\Boot\bootmgfw.efi
\EFI\Boot\bootx64.efi

This option is displayed as "OS boot Manager" (for the first path) and something akin to "UEFI partition" for the second path, completely ignoring the actual name given to it (when you look at the EFI variables through efibootmgr, you can see that what is displayed as "OS boot Manager" actually is set to the name "Windows Boot Manager"; why anyone would do such renaming is beyond me).

BCD file to point at my shim.ef

bootmgfw.efi dosn't chainload another efi boot loader.
It may load another efi apllication.



Do you use Windows 10 pro?
Try a shutdwon script.

Given a file \efi\boot\shim.efi

Testing, brute force windows UEFI:
mountvol.exe s: /s
bcdboot c:\windows /s s: /F UEFI
UEFI boots Windows by default.

mountvol.exe s: /s
S:\EFI\Microsoft\Boot>copy bootmgfw.efi bootwin.efi

menuentry "UEFI: Windows /EFI/Microsoft/Boot/bootwin.efi" {
chainloader /EFI/Microsoft/Boot/bootwin.efi
}


Set a shutdown script at Group Policy Editor gpedit.msc:

cd /d C:\Windows\System32\GroupPolicy\Machine\Scripts\Shutdown
notepad grub.cmd
 

%SystemRoot%\system32\mountvol.exe s: /s
(echo. &echo %date% %time%) >> bootmgfw.log
dir s:\EFI\Microsoft\Boot\bootmgfw.efi >> bootmgfw.log
cd /d S:\EFI\Microsoft\Boot
copy \efi\boot\shim.efi bootmgfw.efi /y
%SystemRoot%\system32\mountvol.exe s: /d

.
No windows update in between: At next UEFI boot, grub is loaded.

May be add this at shut up too.
If there is a windows update interference, next boot goes to windows.
A second boot should give grub back.