That “The requested system device cannot be found” after answering Y means the Recovery environment found a Windows install but couldn’t add it into the BCD store — usually because the recovery environment is looking at the wrong disk/letters, the EFI/BCD area is inaccessible or corrupt, or the boot files/drivers it needs aren’t available. Don’t panic — try the checklist below, in order. I’ll give exact commands to run from WinRE / your rescue WinPE (what you used before). Each step explains why and what to paste back if it fails.
Quick plan (order)
1) Confirm the recovery environment is seeing the correct Windows + EFI volumes.
2) Recreate the UEFI boot store with bcdboot (the most reliable fix for a UEFI/GPT system).
3) If bcdboot fails, make the ESP writable / rename the old BCD and retry.
4) If it still fails, check for driver / storage‑access issues (rare after bcdboot succeeds) or fall back to repairing as Legacy (quick temporary rescue).
Do this now (copy/paste these one block at a time)
A — Identify volumes and confirm Windows installation (very important)
diskpart
list disk
list vol
exit
What to look for:
- Which disk is the NVMe (~1.86 TB) — make sure you will operate on that, not the 12 TB files drive.
- Which volume is the Windows install (largest NTFS; note the drive letter shown by list vol in WinRE — often E: in WinPE).
- Which volume is the small FAT32 EFI (ESP) and its volume number.
If the Windows folder might be on a different letter than you expect, verify:
dir <WinLetter>:\Windows
(e.g. dir E:\Windows). If you don’t see the Windows folder, post the list vol output here and don’t proceed further.
B — Recreate UEFI boot files (best next attempt)
(Replace <WinLetter> with the letter for your Windows partition shown above; replace <ESPvol> with the ESP volume number.
diskpart
select vol <ESPvol>
assign letter=S
exit
bcdboot <WinLetter>:\Windows /s S: /f UEFI
What this does and why: bcdboot copies winload.efi + supporting files to the ESP and rebuilds the BCD; it’s the recommended fix when /rebuildbcd fails on UEFI systems.
- If you get “Boot files successfully created” → reboot to firmware, set Boot Mode = UEFI (CSM disabled), make “Windows Boot Manager” first, Secure Boot OFF for first test, and try to boot.
- If bcdboot fails with an error (c000000f, access denied, etc., proceed to step C.
C — If bcdboot fails (ESP inaccessible / BCD locked) — clear readonly / rename existing BCD and retry
(Only do these if bcdboot failed previously.
diskpart
select disk 0 <-- confirm it’s the NVMe disk (check list disk output)
attributes disk clear readonly
select vol <ESPvol>
format fs=fat32 quick label=ESP <-- only if you decide to reformat (see note)
assign letter=S
exit
(If there was a BCD in S:\EFI\Microsoft\Boot rename it instead of formatting

ren S:\EFI\Microsoft\Boot\BCD BCD.old
Then rerun:
bcdboot <WinLetter>:\Windows /s S: /f UEFI
Notes:
- Formatting the ESP will remove any existing EFI data. Prefer renaming BCD.old first; only format if the EFI was badly corrupted and you have a backup or can recreate files.
- If you get “Access denied” on format/assign, paste the exact error.
D — If bcdboot succeeds but machine still BSODs 0xC0000001 (INACCESSIBLE_BOOT_DEVICE)
That usually means Windows can’t load the NVMe/storage driver early. Two things to check:
1) Make sure firmware storage setting is AHCI (or correct mode for your controller) and not switched to RAID/IRST unexpectedly. Changing mode can require registry driver tweaks.
2) If needed, load the offline SYSTEM hive and set storage drivers to boot start so Windows loads them early (storport, storahci, nvme). Example (only if you need it — I can walk these through):
reg load HKLM\TEMP_SYSTEM <WinLetter>:\Windows\System32\config\SYSTEM
reg add "HKLM\TEMP_SYSTEM\ControlSet001\Services\nvme" /v Start /t REG_DWORD /d 0 /f
(reg add for storport / storahci / msahci / iaStorV similarly)
reg unload HKLM\TEMP_SYSTEM
Then reboot and test. This is a common fix for inaccessible boot device after moving images between different NVMe/SATA controllers.
E — If you prefer a quick temporary rescue (fallback to Legacy/MBR) — get desktop back fast
If you urgently need to boot right now and don’t care about UEFI:
- In BIOS, enable CSM / Legacy boot and disable Secure Boot.
- Boot Windows Repair media (legacy/CSM).
- Run:
bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd
If rebuildbcd still fails with “The requested system device cannot be found,” do the diskpart/list vol checks and then run:
bcdboot <WinLetter>:\Windows
This often gets an MBR/Legacy restore running quickly; you can convert to UEFI later.
Extra troubleshooting notes (common gotchas)
- WinRE/WinPE uses temporary drive letters — the Windows partition letter in WinPE often isn’t C:. Always verify with diskpart/list vol and dir <letter>:\Windows before running bcdboot or bootrec.
- If DISM /Get-Drivers errors (Error 32) you saw earlier, that can mean WinPE couldn’t read the offline driver store — but bcdboot + ensuring the ESP is good is usually enough to fix boot first; driver injection is next if device driver mismatch remains.
- If multiple Windows installations or multiple system partitions exist, you may need to explicitly target the correct partition with bcdboot (use the Windows letter found in WinPE).
What I need from you now
1) Paste the output of diskpart → list disk and list vol (so I can confirm the Windows and ESP volume numbers/letters).
2) If you already ran bcdboot, paste its exact output (or paste the exact error you saw when you tried to add the install earlier).
3) Tell me whether you want me to continue trying to fix this UEFI boot (bcdboot + driver / registry steps) or you want the fast Legacy fallback to get back to the known‑good boots immediately.
I’ll stay with you and interpret the outputs. References: community guidance on recreating the EFI and using bcdboot as the reliable fix for UEFI systems, and posts describing the exact “requested system device cannot be found” cases and remedies.