In the age of UEFI PCs running Windows 10 and later, you may find a situation where the BCD Boot Menu is invisible as a black screen, but still works if navigated from the keyboard. Enter will end the timeout, arrow keys will change the selection, etc.
This problem pattern is not the same as others that are more commonly described online; the menu that does not appear because it is bypassed (Fast Start, Timeout = 0, etc.) or other boot issues that may use a different BCD, bypass the BCD altogether, boot the wrong storage device, hang or crash before reaching UEFI boot due to hardware issues, etc.
Recently I saw my 3rd case of this problem pattern, having described the first and second cases previously. In all three cases, the boot menu works just fine, but can't be seen because the screen (or all screens, if multiple connected) stay black. There's signal to the screen that the monitor accepts, rather than suspending due to incompatibility, but everything is black, with no visible mouse pointer or text-mode blinking cursor.
One fix is to disable the graphics adapter in Windows Device Manager, forcing Windows to use the Microsoft Basic Adapter driver instead of the driver specific to the system's GPU (as detected by Windows). This proves this to be a "kick away the ladder" metabug, where something that should affect only Windows (the choice of graphics driver) affects the underlying UEFI system level beneath, with the potential to make it impossible to boot Windows to undo the damage.
Another fix for older systems, is to avoid UEFI in favor of CSM "BIOS", but this option is no longer available with Class 3 UEFI, and is increasingly untenable as Windows and hardware evolves.
Today's fix is to force the "legacy" type of BCD Boot Menu via a BCDEdit setting, specifically...
bcdedit /set "{current}" bootmenupolicy legacy
...where "{Current}" can be replaced with "{Default}" or more specific OSLoader GUIDs, as displayed explicitly via the /V option in BCDEdit. The visible impact is a text-mode white on black boot menu instead of the blue graphic boot menu; also, the menu text for OSLoaders that use RAMDisk will be taken from the RAMDisk defining GUID in BCD, rather than the OSLoader's GUID.
The implications of all this are twofold.
First, the pre-Windows UEFI boot process is affected by choice of drivers in Windows, extending to how the BCD registry hive is interpreted by {bootmgr} (as seen from BCDEdit).
Second, the code that processes the BCD to display the Boot Menu has two pathways; that of the Windows 7 era Boot Menu that still works when forced via "bootmenupolicy legacy", and the newer Windows 10 era code that screws up the display when problematic drivers are in effect.
The safety implications go deeper; that an attack can be made through Windows to "brick" the system at the pre-Windows UEFI system level, such that no storage device can boot. "Windows" device drivers should not integrate into the system as firmware "Extensions"!
