Disabling Secure Boot

 Article
 12/15/2021
 2 minutes to read
 8 contributors
Feedback

If you're running certain PC graphics cards, hardware, or operating

systems such as Linux or previous version of Windows you may need to
disable Secure Boot.

Secure Boot helps to make sure that your PC boots using only firmware
that is trusted by the manufacturer. You can usually disable Secure Boot
through the PC’s firmware (BIOS) menus, but the way you disable it varies
by PC manufacturer. If you are having trouble disabling Secure Boot after
following the steps below, contact your manufacturer for help.

Warning
 After disabling Secure Boot and installing other software and
hardware, you may need to restore your PC to the factory state
to re-activate Secure Boot.
 Be careful when changing BIOS settings. The BIOS menu is
designed for advanced users, and it's possible to change a
setting that could prevent your PC from starting correctly. Be
sure to follow the manufacturer's instructions exactly.

Disable Secure Boot

1. Before disabling Secure Boot, consider whether it is necessary.
From time to time, your manufacturer may update the list of
trusted hardware, drivers, and operating systems for your PC.
To check for updates, go to Windows Update, or check your
manufacturer's website.
2. Open the PC BIOS menu:

 You can often access this menu by pressing a key

while your PC is booting, such as F1, F2, F12, or Esc.

Or

 From Windows, hold the Shift key while

selecting Restart. Go to Troubleshoot >
Advanced Options: UEFI Firmware Settings.

3. Find the Secure Boot setting in your BIOS menu. If possible,

set it to Disabled. This option is usually in either
the Security tab, the Boot tab, or the Authentication tab.
4. Save changes and exit. The PC reboots.
 5. Install the graphics card, hardware, or operating system that’s
not compatible with Secure Boot.

In some cases, you may need to change other settings in the

firmware, such as enabling a Compatibility Support Module
(CSM) to support legacy BIOS operating systems. To use a CSM,
you may also need to reformat the hard drive using the Master
Boot Record (MBR) format, and then reinstall Windows. For
more info, see Windows Setup: Installing using the MBR or GPT
partition style.

Re-enable Secure Boot

1. Uninstall any graphics cards, hardware, or operating systems
that aren’t compatible with Secure Boot.
2. Open the PC BIOS menu:

 You can often access this menu by pressing a key

while your PC is booting, such as F1, F2, F12, or Esc.

Or

 From Windows, hold the Shift key while

selecting Restart. Go to Troubleshoot >
Advanced Options: UEFI Firmware Settings.

3. Find the Secure Boot setting, and if possible, set it

to Enabled. This option is usually in either the Security tab,
the Boot tab, or the Authentication tab.

On some PCs, select Custom, and then load the Secure Boot
keys that are built into the PC.

If the PC doesn't allow you to enable Secure Boot, try resetting

the BIOS back to the factory settings.

4. Save changes and exit. The PC reboots.

5. If the PC isn't able to boot after enabling Secure Boot, go back
into the BIOS menus, disable Secure Boot, and try to boot the
PC again.

Tip

In some cases, you may need to refresh or Remove everything

to its original state before you can turn on Secure Boot. For
more info, see How to restore, refresh, or Remove
everything.
 6. If the above steps don't work, and you still want to use Secure
Boot, contact your manufacturer for help.

Related topics
Secure Boot Overview

Recommended content

Secure boot

Provides guidance on what an OEM should do to enable Securely

booting a device

Windows Secure Boot Key Creation and Management
Guidance

Windows Secure Boot Key Creation and Management Guidance


Enable Secure Boot on Windows devices - Microsoft Intune

Learn how to make your enrolled device compliant again by

enabling Secure Boot.

Trusted Platform Module (TPM) 2.0

Provides guidance on what an OEM should know about TPM 2.0 and
the features that require it
Show more

BCD System Store Settings for

UEFI
 Article
 10/08/2021
 6 minutes to read
 5 contributors
Feedback

For a typical deployment scenario, you do not need to modify the BCD
store. This topic discusses the various BCD settings in the BCD store that
you can modify. On UEFI systems, this includes settings for the following
boot applications:

 Windows Boot Manager

  Windows Boot Loader
 Windows Memory Tester

The following sections describe the available settings for each of these
boot applications in detail and how to modify each application for UEFI
systems.

For simplicity, the BCDEdit examples in this section modify the BCD
system store. To modify another store, such as a copy of the BCD-
template, include the store name in the command line.

Windows Boot Manager Settings for UEFI

Windows Boot Manager ({bootmgr}) manages the boot process. UEFI-based
systems contain a firmware boot manager, Bootmgfw.efi, that loads an EFI
application that is based on variables that are stored in NVRAM.

The BCD settings for the device and path elements in Windows Boot
Manager indicate the firmware boot manager. The template that is named
BCD-template for Windows includes the following settings for Windows
Boot Manager.

cmdCopy
## Windows Boot Manager

identifier {bootmgr}
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager

Device Setting

The device element specifies the volume that contains Windows Boot
Manager. For UEFI systems, the device element for Windows Boot Manager
is set to the system partition volume letter. To determine the correct
volume letter, use the Diskpart tool to view the disk partitions. The
following example assumes that the system has a single hard drive that
has multiple partitions, including a system partition that has been
assigned a drive letter of S.

The following Diskpart commands select disk 0 and then list the details of
the volumes on that disk, including their drive letters. It shows volume 2
as the system partition.

cmdCopy
DISKPART> select disk 0
DISKPART> list volume

Volume ### Ltr Label Fs Type Size Status Info

---------- --- ------ ----- ---------- ------- --------- ------
Volume 0 D NTFS Partition 103 GB Healthy
 Volume 1 C NTFS Partition 49 GB Healthy Boot
Volume 2 S FAT32 Partition 200 MB Healthy System

If the system partition does not have an assigned drive letter, assign one
by using the Diskpart assign command. The following example assumes
that the system partition is volume 2 and assigns it S as the drive letter.

cmdCopy
Diskpart
select disk 0
list volume
select volume 2 // assuming volume 2 is the system partition
assign letter=s

After you have determined the system partition volume, set

the device element for Windows Boot Manager to the corresponding drive
letter. The following example sets device to drive S.

cmdCopy
Bcdedit /set {bootmgr} device partition=s:// system partition
Tip

If you've previously used Diskpart to get drive letters and then rebooted
your PC, use Diskpart to check your drive letters again prior to running
this command. Depending on your environment, drive letters could
change so be sure that you're setting the right partition.

Path Setting

The path element specifies the location of the Windows Boot Manager
application on that volume. For UEFI systems, path indicates the firmware
boot manager, whose path is \EFI\Microsoft\Boot\Bootmgfw.efi.

You can confirm that BCD-template has the correct path by enumerating
the values in the store, as follows:

cmdCopy
bcdedit /store bcd-template /enum all

To explicitly set path to \EFI\Microsoft\Boot\Bootmgfw.efi, use the following

command.

Copy
Bcdedit /set {bootmgr} path \efi\microsoft\boot\bootmgfw.efi

Other Settings

You should set Windows Boot Manager to be the first item in the display
order of the UEFI firmware, as shown in the following example.

cmdCopy
Bcdedit /set {fwbootmgr} displayorder {bootmgr} /addfirst

You should also specify the topmost Windows boot loader application in
the Windows Boot Manager display order. The following example shows
how to put a specified Windows boot loader at the top of the display
order.

cmdCopy
Bcdedit /set {bootmgr} displayorder {<GUID>} /addfirst

In the preceding example, <GUID> is the identifier for the specified

Windows boot loader object. The next section discusses this identifier in
greater detail.

Note

A multiboot system that has multiple installed operating systems has

multiple instances of the Windows boot loader. Each instance of the
Windows boot loader has its own identifier. You can set the default
Windows boot loader ({default}) to any of these identifiers.

Windows Boot Loader Settings

A BCD store has at least one instance, and optionally multiple instances,
of the Windows boot loader. A separate BCD object represents each
instance. Each instance loads one of the installed versions of Windows
that has a configuration that the object's elements have specified. Each
Windows boot loader object has its own identifier, and the
object's device and path settings indicate the correct partition and boot
application.

BCD-template for Windows has a single Windows boot loader object that has
the following settings.

cmdCopy
## Windows Boot Loader

identifier {9f25ee7a-e7b7-11db-94b5-f7e662935912}
device partition=C:
path \Windows\system32\winload.efi
description Microsoft Windows Server
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows

The identifier for this Windows boot loader is {9f25ee7a-e7b7-11db-94b5-

f7e662935912}. You can use this GUID on your system or let the BCDEdit
tool generate a new GUID for you.
To simplify BCDEdit commands, you can specify one of the Windows boot
loaders in the BCD system store as the default loader. You can then use
the standard identifier ({default}) in place of the full GUID.The following
example specifies the Windows boot loader for EFI as the default boot
loader, assuming that it uses the identifier GUID from BCD-template.

cmdCopy
Bcdedit /default {9f25ee7a-e7b7-11db-94b5-f7e662935912}

Device and OSDevice Settings

The following elements specify key locations:

 The device element specifies the partition that contains the

boot application.
 The osdevice element specifies the partition that contains the
system root.

For the Windows boot loader for EFI, both elements are usually set to the
drive letter of the Windows system partition. However, if BitLocker is
enabled or a computer has multiple installed versions of
Windows, osdevice and device might be set to different partitions.BCD-
template sets both elements to drive C, which is the typical value. You can
also explicitly set the osdevice and device values, as shown in the following
example. The example also assumes that you have specified the Windows
boot loader for EFI as the default boot-loader object.

cmdCopy
Bcdedit /set {default} device partition=c:
Bcdedit /set {default} osdevice partition=c:

Path Setting

The path element of a Windows boot loader specifies the location of the
boot loader on that volume. For UEFI systems, path indicates the Windows
boot loader for EFI, whose path is \Windows\System32\Winload.efi.

You can confirm that BCD-template has the correct path value by
enumerating the values in the store. You can also explicitly set
the path value, as shown in the following example.

cmdCopy
Bcdedit /set {default} path \windows\system32\winload.efi

Windows Memory Tester Settings

The Windows memory tester ({memdiag}) runs memory diagnostics at boot
time. The BCD settings for the application's device and path elements
indicate the correct application.
Note

Intel Itanium computers don't include a Windows memory tester and do

not require {memdiag} settings.

BCD-template for Windows has the following settings.

cmdCopy
## Windows Memory Tester

identifier {memdiag}
device partition=\Device\HarddiskVolume1
path \boot\memtest.exe
description Windows Memory Diagnostic

Device Setting

For UEFI systems, the device element for the Windows memory tester is
set to the system partition drive letter. The following example assumes
that the system partition is drive S, as used in earlier examples.

cmdCopy
Bcdedit /set {bootmgr} device partition=s: // system partition

Path Setting

The path element specifies the location of Windows Test Manager on the
volume that the device element has specified. For UEFI
systems, path indicates the EFI version of the application ( \EFI\Microsoft\
Boot\Memtest.efi).

You can confirm that BCD-template has the correct path value by
enumerating the values in the store. You can also use the BCDEdit tool to
explicitly set the path value, as shown in the following example.

cmdCopy
Bcdedit /set {memdiag} path \efi\microsoft\boot\memtest.efi

Recommended content

Boot and UEFI - Windows drivers

Provides guidance about the boot process and UEFI implementation

requirements for devices that run Windows 10.

BCDEdit Command-Line Options
 BCDEdit is a command-line tool for managing Boot Configuration
Data (BCD).

BCDBoot Command-Line Options

BCDBoot Command-Line Options


Adding Boot Entries - Windows drivers

Adding Boot Entries in Windows Vista and later, Windows Server

2008 and later, and Windows Recovery Environment
Show more

Validating Windows UEFI

Firmware Update Platform
Functionality
 Article
 10/12/2021
 9 minutes to read
 5 contributors
Feedback

This document lists the basic validation scenarios that are required to
pass before signing-off on the Windows UEFI Firmware Update Platform
functionality.

Prerequisites
 For each EFI System Resource Table (ESRT) entry, you need a
capsule for the latest firmware version. The scenarios will refer to the
latest version as X. Each ESRT entry is identified using a unique
GUID.
 For each ESRT entry exposed, create a capsule package that its
version is incremented above the package created in step 1. These
capsules will be referred to as X+1.
 Capsules that aid in simulating failure conditions such as a capsule
for which the payload is not signed or signed with an invalid PK.
 Make sure all capsules to be used are signed appropriately from the
OS perspective, catalog signed, and firmware signed, PK signed.
Unless, you are specifically testing the negative PK signing cases.
See “Signing the Firmware driver Package” in the specification for
details on how to sign a capsule or firmware driver package.
How To
Install a new capsule or reinstall a previously installed
capsule
1. Open up device manager.
2. Find the device node that represents your firmware, it is usually
under the “Firmware” devices.
 3. Right click on the firmware device you wish to update.
4. Select Update driver software. You will get a popup that states
“Update Driver Software - <Firmware>”.
5. Select Browse my computer for driver software.
6. On the next window, select Let me pick from a list of device
drivers on my computer.
7. If the driver has been installed before, select it from the Show
compatible hardware box. If it does not exist, select Have
disk and continue on. Otherwise, select OK and reboot the system.
8. If you select Have Disk, you will get a popup labeled Install From
Disk.
9. Use Browse to go to the directory that has the capsule of the
firmware you wish to install.
10.Select the INF file in that directory and hit OK to install.
11.During installation, if you get a popup saying the driver is not signed,
go ahead and accept this driver.
12.The system asks you to reboot.
13.After you installed the capsule for the firmware, you need to reboot.
If you wish to install multiple capsule packages, then wait to reboot
until all capsules are installed and then reboot on the final capsule.
Query the version and status details
 Run the QueryVersionAndStatus.ps1 PowerShell (PS) script to query
the current firmware version, last attempt firmware version and last
attempt status.
To run the script
1. Run PowerShell as administrator.
2. Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force (This
only has to be done once.)
3. Display the version and status details for the given GUID. For
example: .\QueryVersionAndStatus.ps1 6bd2efb9-23ab-4b4c-bc37-
016517413e9a
4. Check if firmware update was successful: Refer to the section
“Validating the status of the firmware update” in the specification
document. Make sure that the Last Attempt Status and the Current
Version matches the expected version.
5. Recommended: Check to make sure that the devices you are
updating are also still functioning.
6. Set the rollback policy: Some of the scenarios might require rolling
back firmware. Rollback is not a production scenario. In order to be
able to rollback, a registry policy key has to be created. Create a
REG_DWORD key with the name “Policy” under the node
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
FirmwareResources\{<GUID>} and set the value of the Policy key to
1. Note that the GUID should be replaced with the actual GUID from
the ESRT.
Scenarios
S1: Each ESRT entry is successfully updatable through
capsule

The following steps should be completed for each ESRT entry that is
supported by the platform. Or in other words, for System firmware and
each device firmware that supports updating firmware through
UpdateCapsule.

S1 Steps
1. For each ESRT entry, install the capsule for firmware version X.
2. Make sure all the above capsules are installed, prior to rebooting.
S1 Expected Result

Firmware update should be successful for each ESRT entry that was
updated. For all ESRT entries, for which the update was attempted,
validate that:

 Current Firmware Version = X

 Last Attempt Version = X
 Last Attempt Status = 0 (STATUS_SUCCESS)
S2: The latest firmware version X is also updatable to X+1

The following steps should be completed for each ESRT entry that is
supported by the platform. Or in other words, for System firmware and
each device firmware that supports updating firmware through
UpdateCapsule.

S2 Steps
1. Complete scenario S1 above.
2. For each ESRT entry, install the capsule for firmware version X+1.
S2 Expected Result

Firmware update should be successful for each ESRT entry that was
updated. For all ESRT entries, for which the update was attempted,
validate that:

 Current Firmware Version = X+1

 Last Attempt Version = X+1
 Last Attempt Status = 0 (STATUS_SUCCESS)
S3: On failure, firmware update returns the right status
code as defined in the specification

The Status codes are defined in the section named “UEFI System
Resource Table Definition”, in the table with the title “ESRT Last Attempt
Status Field Values”.

S3.1 Insufficient Battery and UEFI System Firmware

update
S3.1 Steps
1. Drain the battery charge to less than 25% and then plug-in the AC
power.
2. Install the capsule for UEFI System Firmware version X+1. Let’s
assume that the current version is X.
3. Before rebooting, make sure that the battery charge is less than 25%
S3.1 Expected Result

Firmware update should fail. For ESRT entry corresponding to the System
Firmware, validate that:

 Current Firmware Version = X

 Last Attempt Version = X+1
 Last Attempt Status = 0xc00002de (STATUS_INSUFFICIENT_POWER)
S3.2 Insufficient Battery and Device Firmware update
S3.2 Steps
1. Drain the battery charge to less than 25% and then plug-in the AC
power.
2. Install the capsules for ALL supported devices in the system with
firmware version X+1. Let’s assume that the current firmware
version for the given device is X.
3. Before rebooting, make sure that the battery charge is less than 25%
.
S3.2 Expected Result

Firmware update should fail. For all ESRT entries, for which the update
was attempted, validate that:

 Current Firmware Version = X

 Last Attempt Version = X+1
 Last Attempt Status = 0xc00002de (STATUS_INSUFFICIENT_POWER)
S3.3 Insufficient Battery, UEFI System and Device
Firmware update at the same time
S3.3 Steps
1. Drain the battery charge to less than 25% and then plug-in the AC
power.
2. Install the capsules for UEFI System Firmware and all Device
Firmware with version X+1.
3. Before rebooting, make sure that the battery charge is less than
25%.
S3.3 Expected Result

Firmware update should fail for the System firmware and for all the device
firmware for which the update was attempted. For all ESRT entries, for
which the update was attempted, validate that:

 Current Firmware Version = X

 Last Attempt Version = X+1
 Last Attempt Status = 0xc00002de (STATUS_INSUFFICIENT_POWER)
S3.4 Firmware update should fail when the capsule is not
PK signed

The following steps should be completed for each ESRT entry that is
supported by the platform. Or in other words, for System firmware and
each device firmware that supports updating firmware through
UpdateCapsule.
S3.4 Steps
1. For each ESRT entry, create a capsule X+2, the payload for which is
not signed.
2. Install the capsules X+2. Let’s assume that the current version is X.
S3.4 Expected Result

Firmware update should fail for all the ESRT entries for which the update
was attempted. For all ESRT entries, for which the update was attempted,
validate that:

 Current Firmware Version = X

 Last Attempt Version = X+2
 Last Attempt Status = 0xC0000022 (STATUS_ACCESS_DENIED)
S3.5 Firmware update should fail when the capsule is
signed with the wrong PK certificate

The following steps should be completed for each ESRT entry that is
supported by the platform. Or in other words, for System firmware and
each device firmware that supports updating firmware through
UpdateCapsule.

S3.5 Steps
1. For each ESRT entry, create a capsule X+2, sign the payload with a
wrong key or certificate (for example use a debug signed capsule on
a production device).
2. Install the capsules X+2. Let’s assume that the current version is X.
S3.5 Expected Result

Firmware update should fail for all the ESRT entries for which the update
was attempted. For all ESRT entries, for which the update was attempted,
validate that:

 Current Firmware Version = X

 Last Attempt Version = X+2
 Last Attempt Status = 0xC0000022 (STATUS_ACCESS_DENIED)
S3.6 Firmware update should fail when the capsule
payload is tampered with

The following steps should be completed for each ESRT entry that is
supported by the platform. Or in other words, for System firmware and
each device firmware that supports updating firmware through
UpdateCapsule.

S3.6 Steps
1. For each ESRT entry, create a capsule X+2, sign the payload with the
right key or certificate. Then open the firmware bin file and flip 1 or
more bits in the file and save the file back.
2. Regenerate the catalog for the bin file and the INF file.
3. Install the capsules X+2. Let’s assume that the current version is X.
S3.6 Expected Result

Firmware update should fail for all the ESRT entries for which the update
was attempted. For all ESRT entries, for which the update was attempted,
validate that:

 Current Firmware Version = X

 Last Attempt Version = X+2
 Last Attempt Status = 0xC0000022 (STATUS_ACCESS_DENIED) or
0xC000007B (STATUS_INVALID_IMAGE_FORMAT)
S3.7: Firmware does not allow rollback beyond the
LowestSupportedFirmwareVersion

The following steps should also be carried out for other device firmware
(lower priority).

S3.7 Steps
1. For UEFI System Firmware, create a capsule X+1 such that the
“LowestSupportedFirmwareVersion” in the ESRT entry for the system
firmware is set to X+1.
2. Install the capsule X+1 and make sure that the update succeeds.
3. Create a UEFI System firmware update capsules, such that the
version in the INF is X+2 but the actual firmware binary file is of
version X.
4. Install the capsule X+2 and reboot the system.
S3.7 Expected Result

Firmware update should fail. For ESRT entry corresponding to the System
Firmware, validate that:

 Current Firmware Version = X+1

 Last Attempt Version = X+2
 Last Attempt Status = 0xC0000059 (STATUS_REVISION_MISMATCH)
S4: Seamless recovery and firmware update (if
implemented)

This scenario varies from platform to platform depending on the

implementation of the seamless recovery. Based on the implementation,
the validation might require creating bad capsules that forces the system
into recovery or disconnecting the power in the middle of an update or
through any other means of exercising the recovery flows.

S4 Expected Result

The system should boot into the OS and the firmware update should be
marked as failed. The version reported by the UEFI firmware resource
device should not have changed.

S5: Firmware Update adheres to the User Experience (UX)

requirement
S5 Steps
 This scenario can be validated while executing any of the above
scenarios that lead to a successful firmware update.
S5 Expected Result

The user experience is in accordance to the specification, see section on

“User Experience”.

 The only text that is displayed on the screen is “Please wait while we
install a system update”. The text is displayed at the right co-
ordinates on the screen as called out in the specification.
 OEM Logo is displayed as described in the specification.
Related topics
Windows UEFI Firmware Update Platform

UEFI Validation Option ROM Validation Guidance

QueryVersionAndStatus.ps1 PowerShell (PS) script

Recommended content

UEFI firmware requirements

Provides guidance on what an OEM should do to enable UEFI


Windows Secure Boot Key Creation and Management
Guidance

Windows Secure Boot Key Creation and Management Guidance


Windows UEFI firmware update platform - Windows drivers

Windows supports installing system and device firmware updates

via driver packages that are processed using the UpdateCapsule
function.

Windows Hardware Compatibility Program Specifications
and Policies

When products meet the minimum requirements as defined in the

below documents, it ensures that applications and devices are
compatible.
Show more