Quick fix: bootrec /fixboot returns “Access denied” on UEFI systems because Windows 8+ secured the EFI partition. Use bcdboot C:\Windows /s S: /f UEFI instead, where S: is the EFI System Partition letter assigned via diskpart.

You’re fixing a non-bootable Windows install. You boot from a Windows install USB, open Command Prompt, run the standard repair sequence — bootrec /fixmbr, bootrec /fixboot — and the /fixboot step returns “Access denied.” The cause is UEFI: on UEFI installs, the EFI System Partition (ESP) doesn’t have a drive letter accessible from Recovery Environment, so bootrec can’t write to it. The fix is to mount the ESP manually and use bcdboot.

Symptom: bootrec /fixboot returns “Access denied” or 0x80092011 in Windows Recovery Environment on UEFI systems.
Affects: Windows 11 (and Windows 10) on UEFI-booted PCs.
Fix time: ~15 minutes.

What causes this

The bootrec /fixboot command writes a new boot sector to the system partition. On legacy MBR/BIOS installs, the system partition has a regular drive letter and bootrec can write to it. On UEFI/GPT installs, the boot configuration lives on a separate hidden EFI System Partition (ESP, FAT32, ~100 MB). The ESP doesn’t mount with a drive letter automatically — Windows reserves it for system use only.

When bootrec /fixboot runs and can’t find a writable system partition, it returns “Access denied.” The fix is to manually assign a drive letter to the ESP, then use bcdboot (which natively handles UEFI) instead of bootrec.

Method 1: Mount ESP and use bcdboot (recommended)

The supported path for UEFI systems.

Boot from Windows 11 install USB. Choose Repair your computer → Troubleshoot → Command Prompt.
Identify the Windows install drive and ESP:
```
diskpart
list disk
select disk 0
list volume
```
Look in the output for:
- A volume labeled Windows or showing your install (~100+ GB used). Note its letter (often C:, sometimes D:).
- A small (~100 MB) FAT32 volume — the ESP. Note its volume number.
Assign a letter to the ESP:
```
select volume N
assign letter=S
exit
```
Replace N with the ESP volume number.
Format ESP if it’s damaged (skip if you want to preserve existing BCD):
```
format S: /FS:FAT32 /Q
```
Use bcdboot to lay down a fresh boot environment on the ESP:
```
bcdboot C:\Windows /s S: /f UEFI
```
Adjust C: to your Windows install drive. Output should say Boot files successfully created.

Remove the temporary letter from ESP:

diskpart
select volume N
remove letter=S
exit

Reboot normally. Windows should now boot.

This is the canonical fix when bootrec /fixboot returns Access denied.

Method 2: Recreate the EFI System Partition if it’s missing

For when diskpart list volume doesn’t show any FAT32 ESP-like partition.

From the Recovery Command Prompt, run diskpart.
Verify your disks and partitions:
```
list disk
select disk 0
list partition
```
If the ESP is missing entirely, look for unallocated space at the start of the disk (where ESP normally lives).

If unallocated space exists at the start:

select disk 0
create partition efi size=100
format quick fs=fat32 label="System"
assign letter=S

If your C: partition fills the disk and there’s no unallocated space: you’ll need to shrink C: first. Boot to GParted Live USB (free Linux tool) to safely resize NTFS partitions.
Once ESP exists with a letter, run bcdboot as in Method 1.
Exit diskpart and reboot.

This handles the worst case: ESP was deleted by a third-party partition tool.

Method 3: Try bootrec with elevated rights on the underlying volume

For when you specifically need bootrec /fixboot to work (some recovery scripts depend on it).

From Recovery Command Prompt, identify Windows install drive: typically C: or D:.
Switch to the Windows install drive: C: (or D:).

Take ownership of the boot directory:

cd \boot
takeown /f bootmgr
icacls bootmgr /grant administrators:F

Try bootrec /fixboot again. On some systems this resolves Access denied.
If still failing: the issue is genuinely UEFI vs. MBR mismatch — bootrec isn’t the right tool for UEFI. Fall back to Method 1.
For MBR systems specifically: ensure the system partition has the Active flag:
```
diskpart
select disk 0
select partition 1
active
exit
```
Then retry bootrec /fixmbr and bootrec /fixboot.

The trade-off: this attempts to keep bootrec as the tool, which is the wrong approach on UEFI. Method 1 is cleaner.

How to verify the fix worked

Reboot the PC. Windows should boot to the login screen without intervention.
Open Terminal (Admin) and run bcdedit /enum. Output should show Windows Boot Manager and Windows Boot Loader entries with valid paths.
Check the ESP is properly hidden again: diskpart → list volume. The ESP should appear as FAT32 with no drive letter (System type).

If none of these work

If bcdboot succeeds but Windows still won’t boot, deeper corruption is present. Check the BCD store for orphans: bcdedit /enum all. Look for entries with paths pointing to non-existent partitions. Delete them with bcdedit /delete {identifier}. Verify the Windows partition is healthy: chkdsk C: /f from Recovery Command Prompt. If CHKDSK finds many errors, the disk may be failing — image to another drive before further troubleshooting. Check for non-Windows boot loaders: dual-boot setups with Linux (GRUB) sometimes leave conflicting EFI entries. From Recovery, run bcdedit /enum firmware to see all EFI boot entries. Remove non-Windows entries with bcdedit /delete {GUID}. For PCs that recently had a Windows feature update: in-place upgrade via Windows 11 ISO (mount ISO, run setup.exe, choose Keep personal files and apps) is often faster than further BCD repair. Same end result, less debugging.

Bottom line: bootrec /fixboot returns Access denied on UEFI because the ESP isn’t writable from Recovery. Mount the ESP via diskpart, use bcdboot instead. This is the supported path Microsoft uses internally.