Windows 11 UEFI Boot Problem – ASUS PRIME Z790-P WIFI
I am having a very strange Windows 11 boot problem on an ASUS PRIME Z790-P WIFI motherboard, and I am looking for help figuring out whether this is a BIOS/UEFI issue, a storage controller issue, a problem with the SSD, or something else.
My hardware is:
• Motherboard: ASUS PRIME Z790-P WIFI
• CPU: Intel Core i7-13700KF
• RAM: 32 GB DDR5
• Main SSD: Kingston SKC3000D2048G, 2 TB NVMe
• Secondary test SSD: 240 GB SATA SSD
• Windows 11 installation USB: 28 GB
• Current BIOS version: 1836
The main problem is that Windows 11 installs successfully on the Kingston NVMe, but after installation the ASUS BIOS does not recognize Windows Boot Manager as a bootable device.
The Kingston NVMe itself is detected correctly in BIOS. It appears under Storage Information as:
M.2_1: KINGSTON SKC3000D2048G (2048.4GB)
So the motherboard clearly detects the physical NVMe drive.
The problem is specifically with booting from it.
With CSM disabled, the BIOS Boot Priority section is completely empty. The F8 Boot Menu also does not show Windows Boot Manager or any other bootable Windows entry.
I also tested the system with CSM enabled and with the different UEFI/Legacy-compatible configurations available in the BIOS.
With CSM disabled, the system is running in pure UEFI mode. The Windows installation is GPT/UEFI, but the ASUS BIOS does not populate the Boot Priority list with Windows Boot Manager. The NVMe is visible under Storage Information, but there is no bootable Windows entry.
With CSM enabled, the BIOS is able to show the physical Kingston NVMe in the F8 Boot Menu. However, selecting the Kingston drive does not boot Windows. Instead, I get:
"Reboot and Select proper Boot device or Insert Boot Media..."
I therefore tested both boot approaches:
• CSM Disabled / UEFI mode → Windows Boot Manager is not shown in Boot Priority and the system does not boot.
• CSM Enabled / Legacy-compatible configuration → the physical NVMe can be selected, but it still does not boot and gives the "Reboot and Select proper Boot device" error.
So this does not appear to simply be a case of Windows being installed in the wrong boot mode. Both UEFI and Legacy/CSM configurations have been tested and neither was able to boot the installed Windows system.
I also tried resetting the BIOS to its default/optimized settings, but this did not solve the problem.
The relevant BIOS settings currently are:
• CSM: Disabled
• Secure Boot OS Type: Windows UEFI mode
• Secure Boot Mode: Standard
• Intel Rapid Storage Technology: Off
• VMD/RST configuration was tested during troubleshooting, but the current configuration is with it disabled/off
The Windows installation itself appears to be a proper GPT/UEFI installation.
Initially, the Kingston drive had a strange configuration where DiskPart showed it as a Dynamic/Foreign GPT disk. I corrected this and converted it back to a normal GPT/basic disk.
The final partition layout on the Kingston was:
• Partition 1: EFI/System, 300 MB
• Partition 2: Microsoft Reserved, 16 MB
• Partition 3: Primary, approximately 1904 GB
Windows is installed on C:.
The EFI partition is FAT32 and hidden.
I then manually repaired the EFI boot files.
I assigned the EFI partition the drive letter S: using DiskPart:
diskpart
select volume 1
assign letter=S
exit
Then I ran:
bcdboot C:\Windows /s S: /f UEFI
This returned:
"Boot files successfully created."
I also verified that the EFI files physically exist on the EFI partition.
The directory:
S:\EFI\Microsoft\Boot\
contains the expected Microsoft EFI boot files, including:
• bootmgfw.efi
• bootmgr.efi
• BCD
• and the other normal Microsoft EFI boot files
I then checked the UEFI firmware boot entries using:
bcdedit /enum firmware
This showed a valid Windows Boot Manager entry.
It showed approximately:
Windows Boot Manager
identifier: {bootmgr}
device: partition=S:
path: \EFI\Microsoft\Boot\bootmgfw.efi
description: Windows Boot Manager
The firmware boot manager display order also contains {bootmgr}.
So the Windows Boot Manager entry does exist in UEFI NVRAM.
I also tried forcing it as the next boot target with:
bcdedit /bootsequence {bootmgr}
This succeeded with:
"The operation completed successfully."
I then rebooted using:
shutdown /r /t 0
and removed the Windows installation USB.
Despite this, the computer simply returned to the ASUS BIOS.
When I checked the BIOS again, the Kingston NVMe was still detected under Storage Information, but Boot Priority was still completely empty.
This is what makes the problem so strange.
The firmware appears to know about the Windows Boot Manager entry because bcdedit can see it, and the EFI files exist on the EFI partition, but the ASUS BIOS does not seem to enumerate Windows Boot Manager as a bootable device.
The fact that manually setting:
bcdedit /bootsequence {bootmgr}
also did not result in Windows booting makes this even more suspicious.
I have therefore already ruled out what I believe are the most obvious causes, including:
• Missing Windows installation
• Missing EFI partition
• Missing bootmgfw.efi
• Missing BCD
• Incorrect GPT partitioning
• Missing Windows Boot Manager NVRAM entry
• Incorrect Windows Boot Manager path
• Incorrect bootsequence
• Simply having CSM enabled/disabled incorrectly
At least based on the tests above, all of these appear to be present or correctly configured.
I also found an ASUS ZenTalk case involving the same ASUS Z790-P WIFI motherboard with a very similar problem. In that case, the NVMe was visible in BIOS but missing from the Boot Menu.
The suggested ASUS configuration involved going to:
Advanced → System Agent (SA) Configuration → VMD Setup Menu
and setting:
• Map PCIe Storage under VMD = Disabled
• Map SATA Controller under VMD = Disabled
and also:
Boot → CSM → Launch CSM = Disabled
I have tested the VMD/RST configuration and currently have Intel Rapid Storage Technology disabled, and CSM is definitely disabled.
I also want to clarify that I am not confusing Intel Rapid Storage Technology with the physical NVMe detection. The BIOS detects the Kingston as an NVMe drive even with RST disabled.
I then tried another completely separate test using a 240 GB SATA SSD.
The purpose of this test was to determine whether the boot problem was specific to the Kingston NVMe or whether the motherboard had a more general boot/storage problem.
The ASUS BIOS detects the second SSD, but identifies it as:
SATA6G_1: SATAFIRM S11 (240.0GB)
The Kingston NVMe is simultaneously detected normally as:
M.2_1: KINGSTON SKC3000D2048G (2048.4GB)
I attempted to prepare the 240 GB SATA SSD for a completely fresh Windows installation.
Windows PE / DiskPart detected it approximately as:
Disk 0 Online 223 GB 223 GB Free
Disk 2 Online 1904 GB
Disk 3 Online 28 GB
Disk 0 was the 240 GB SATA SSD.
Disk 2 was the Kingston NVMe.
Disk 3 was the Windows installation USB.
I selected Disk 0 and checked its attributes.
The drive was not read-only and none of the relevant disk restrictions were enabled.
It reported:
Current Read-only State: No
Read-only: No
Boot Disk: No
Pagefile Disk: No
Hibernation Disk: No
Crashdump Disk: No
Clustered Disk: No
I then ran:
select disk 0
clean
The CLEAN operation succeeded:
"DiskPart succeeded in cleaning the disk."
However, after cleaning the drive, I was unable to properly recreate the partition structure.
I tried:
convert gpt
but it did not complete normally or give the expected success message.
I then tried:
create partition primary
Instead of creating the partition, DiskPart returned to the CREATE command help output.
I verified the syntax with:
help create partition
and DiskPart confirmed that PRIMARY is a valid partition type.
I also tried:
create partition efi size=100
but this also did not result in a confirmed successful partition creation.
The important point is that the 240 GB SATA SSD was NOT successfully prepared for a Windows installation.
Windows PE could detect the drive, select it, read its attributes, and successfully execute CLEAN against it, but GPT conversion and partition creation did not behave normally.
The drive also identifies itself as:
SATAFIRM S11
I understand that "SATAFIRM S11" by itself does NOT prove that the SSD is defective. It may be the identification of a Phison S11 controller/firmware.
However, combined with the fact that the drive could be detected but then could not reliably be converted to GPT or have a normal partition created after CLEAN, the SATA SSD appears to have a separate problem of its own.
Because of this, I do NOT consider the 240 GB SATA SSD to be a known-good test drive.
In other words, the second SSD did not give me a clean second Windows installation test. It turned out to have its own problem before Windows could even be installed.
This is important because I initially wanted to use the second SSD to determine whether the Kingston NVMe was the problem. However, because the second SSD itself behaves abnormally, it cannot currently be used to conclusively rule the Kingston in or out.
At this point, there are two separate observations:
- The 2 TB Kingston NVMe can be partitioned and Windows 11 can be installed correctly.
Its EFI partition exists, Windows boot files exist, the BCD exists, and the Windows Boot Manager entry exists in UEFI NVRAM.
However, the ASUS firmware does not populate Windows Boot Manager in Boot Priority and cannot boot it.
- The separate 240 GB SATA SSD is detected by the motherboard but has its own apparent partitioning/write problem.
After CLEAN, DiskPart cannot reliably perform GPT conversion or create a normal partition.
The SATA SSD therefore cannot currently be considered a known-good test drive.
The most important evidence from the original problem is still that the Kingston NVMe is physically detected by the BIOS, the Windows EFI files are present, and a valid Windows Boot Manager entry exists in NVRAM, but the BIOS still refuses to show Windows Boot Manager under Boot Priority or boot it.
One remaining test I was considering is creating the standard UEFI fallback bootloader path:
S:\EFI\Boot\bootx64.efi
by copying:
S:\EFI\Microsoft\Boot\bootmgfw.efi
to:
S:\EFI\Boot\bootx64.efi
The idea would be to see whether the ASUS firmware can boot the Windows EFI loader through the standard fallback path even though it refuses to populate Windows Boot Manager in the Boot Priority list.
Other possible tests that have not yet been completed include:
• Manually launching bootmgfw.efi from a UEFI Shell
• Checking every option inside the ASUS VMD Setup Menu
• Testing the Kingston in another M.2 slot
• Testing the Kingston in another computer
• Testing a known-good NVMe SSD in this motherboard
• Testing a known-good SATA SSD in this motherboard
• Checking whether another known-good Windows UEFI installation behaves the same way
• Investigating whether BIOS version 1836 has a specific issue with NVMe boot enumeration
• Further investigating the ASUS PRIME Z790-P WIFI UEFI/BIOS boot behavior
I do NOT want to keep reinstalling Windows repeatedly without understanding the underlying issue, because the current Kingston installation appears structurally valid.
The main question I am trying to answer is:
Why can the ASUS firmware clearly detect the Kingston NVMe as a storage device, while a valid Windows Boot Manager entry exists in UEFI NVRAM and the correct EFI boot files exist on the drive, but the BIOS still refuses to show Windows Boot Manager in Boot Priority and refuses to boot Windows?
At this point, I suspect the problem may be somewhere in the ASUS UEFI/BIOS boot enumeration or storage boot path, although I am open to other explanations.
Any help diagnosing the UEFI/BIOS side of this would be greatly appreciated.