Windows 10 can't fix 0xc000000e winload boot error

[estrogenEsports]

hi there, earlier this week I started on what I would assume to be a simple process of upgrading my PC. I recently got a 2TB NVME SSD to replace my old 1TB SATA SSD, as the relatively low storage capacity was at this point my main bottleneck for my PC, given I'd often need to download games to a 4TB HDD I have separately

the day came to finally do the installation, I had the new drive sitting in my PC for a few days as I needed to find a USB drive to run Clonezilla off of. about an hour later I had presumably cloned my drive successfully, and I booted into windows 10 like normal. I missed the timing to press f11 to make sure I was booting from the drive, and upon seeing my desktop for what would be the final time I opened the drive manager to see that I was in fact still on my old one. oddly my new drive still showed up as unformatted, but I assumed that was just some weird error and restarted my PC again.

now this is where all of my problems arise, as I was given the 0xc000000e error code telling me 'A required device isn't connected or can't be accessed'. Pressing either Enter or F8 as prompted does nothing other than refreshing the screen, and adding an extra error message, that being 'The application or operating system couldn't be loaded because a required file is missing or contains errors.' 'File:\Windows\system32\winload.exe' following this is a prompt telling me I'll need to use recovery tools

yesterday with the help of a friend I was able to get a windows 10 installation USB to repair my installation, however no set of commands we tried seemed to repair the installation on either drive, and I have since removed the new drive (the 2TB NVME) as it seems to have more errors and unless I decide to just reinstall Windows (which I really don't wanna do here unless I Absolutely Have To) I don't wanna use it until I'm able to fix whatever was going on with my original drive, since at this point it is my assumption that I was having some sort of issue with installation before I cloned my drive, and that issue was copied over to the new drive (making it much more complicated since I in my initial round of troubleshooting I was looking to see if anyone else had this problem after using Clonezilla and noticed it's pretty common to need to boot into safe mode and fix your drivers, however this isn't even an option for me here, at least not yet)

I'm not sure what to do at this point, I just wanna fix my windows installation and be done with it, I don't wanna make a new installation and have to reinstall all my programs and stuff since that would take me ages considering I've already spent ages configuring this thing to my liking and preferences as best I can

 

[ChatGPT]

Hi estrogenEsports — that 0xc000000e + winload.exe screen almost always boils down to Windows Boot Manager / BCD pointing at the wrong “device” (partition GUID / disk) or the boot files on the EFI/System partition being damaged. Cloning + having both drives installed can trigger exactly that (UEFI entries can end up pointing to the “other” copy, or to a device ID that no longer matches).
Below is the most reliable way to fix it without reinstalling Windows, starting from the assumption you currently want to boot the original 1TB SATA SSD.

---

0) Quick BIOS/UEFI sanity check (very important)​

1) Physically disconnect everything except:

• the 1TB SATA SSD (your old Windows drive)
• keyboard/mouse
• (optionally) the Windows installer USB
  Also disconnect the 4TB HDD for now (it can confuse boot repair if it has old boot code).

2) Boot into BIOS/UEFI and verify:

• Boot mode: ideally UEFI (not Legacy/CSM) if your Windows was installed that way.
• Boot order: pick Windows Boot Manager (your SATA SSD) if it’s listed.
• If you see multiple “Windows Boot Manager” entries, choose the one that references the SATA SSD.

If you can’t clearly tell which entry is which, don’t worry—do the command-line repair below; it will recreate a clean boot entry.

---

1) Rebuild boot files the “UEFI/GPT” way (most common on modern systems)​

Boot from the Windows 10 installer USB → Repair your computer → Troubleshoot → Advanced options → Command Prompt.

A) Find your Windows partition letter​

In Command Prompt:

diskpart
list vol

Look for:

• A large NTFS volume (hundreds of GB) — that’s usually your Windows partition.
• A small FAT32 volume around 100–300 MB — that’s the EFI System Partition (ESP).

Now do these (replace X with the correct volume numbers you see):

select vol X (this is the FAT32 EFI volume)
assign letter=S
exit

Now find the Windows letter (often it’s D: in recovery, not C. Check which one contains Windows:

dir C:\Windows
dir D:\Windows
dir E:\Windows

Assume the one that works is D: for the next step.

B) Run a disk check (good idea before rebuilding)​

chkdsk D: /f

C) Recreate the boot files + BCD​

bcdboot D:\Windows /s S: /f UEFI
Now reboot (remove the USB when it restarts) and see if Windows loads.

---

2) If your system is Legacy/MBR instead (alternative path)​

If in diskpart you do not see a small FAT32 EFI partition, you may be using Legacy boot.
Back in Command Prompt:

bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd

If /fixboot says “Access is denied”​

That’s common on some Windows 10 media. Tell me if you hit it and paste the exact message—there are a couple safe ways around it depending on your partition layout.

---

3) If it still won’t boot: offline system file repair​

From the same Command Prompt (using the correct Windows letter, example D:
sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
If SFC reports it can’t fix some files, tell me what it says (the summary line), and we’ll move to DISM offline repair.

---

4) Two key questions (so I can tailor the next step exactly)​

1) In BIOS, do you boot via an entry called “Windows Boot Manager”, or does it just list the SSD model name?
2) In diskpart → list vol, do you see a FAT32 volume ~100–300MB (EFI), yes or no?
If you can, paste the output of:

• diskpart → list disk
• diskpart → list vol

(Just a phone photo of the screen is fine.

---

Important note about the NVMe showing as “unformatted”​

If Clonezilla had successfully cloned the whole disk, the NVMe would normally show partitions, not “unformatted.” That strongly suggests either:

• the clone didn’t actually write the partition table, or
• Windows was seeing the NVMe as Offline / conflicting / not initialized, or
• there’s an NVMe/controller/slot issue.

But first priority is getting the original SATA install booting again—then we can circle back and clone/migrate cleanly (best practice is: clone with only source+target connected, then first boot with ONLY the target connected).
Post those diskpart results and I’ll tell you exactly which volumes to select and which commands to run for your specific layout.

 

[estrogenEsports]

Hi estrogenEsports — that 0xc000000e + winload.exe screen almost always boils down to Windows Boot Manager / BCD pointing at the wrong “device” (partition GUID / disk) or the boot files on the EFI/System partition being damaged. Cloning + having both drives installed can trigger exactly that (UEFI entries can end up pointing to the “other” copy, or to a device ID that no longer matches).
Below is the most reliable way to fix it without reinstalling Windows, starting from the assumption you currently want to boot the original 1TB SATA SSD.

---

0) Quick BIOS/UEFI sanity check (very important)​

1) Physically disconnect everything except:

• the 1TB SATA SSD (your old Windows drive)
• keyboard/mouse
• (optionally) the Windows installer USB
  Also disconnect the 4TB HDD for now (it can confuse boot repair if it has old boot code).

2) Boot into BIOS/UEFI and verify:

• Boot mode: ideally UEFI (not Legacy/CSM) if your Windows was installed that way.
• Boot order: pick Windows Boot Manager (your SATA SSD) if it’s listed.
• If you see multiple “Windows Boot Manager” entries, choose the one that references the SATA SSD.

If you can’t clearly tell which entry is which, don’t worry—do the command-line repair below; it will recreate a clean boot entry.

---

1) Rebuild boot files the “UEFI/GPT” way (most common on modern systems)​

Boot from the Windows 10 installer USB → Repair your computer → Troubleshoot → Advanced options → Command Prompt.

A) Find your Windows partition letter​

In Command Prompt:

diskpart
list vol

Look for:

• A large NTFS volume (hundreds of GB) — that’s usually your Windows partition.
• A small FAT32 volume around 100–300 MB — that’s the EFI System Partition (ESP).

Now do these (replace X with the correct volume numbers you see):

select vol X   (this is the FAT32 EFI volume)
assign letter=S
exit

Now find the Windows letter (often it’s D: in recovery, not C. Check which one contains Windows:

dir C:\Windows
dir D:\Windows
dir E:\Windows

Assume the one that works is D: for the next step.

B) Run a disk check (good idea before rebuilding)​

chkdsk D: /f

C) Recreate the boot files + BCD​

bcdboot D:\Windows /s S: /f UEFI
Now reboot (remove the USB when it restarts) and see if Windows loads.

---

2) If your system is Legacy/MBR instead (alternative path)​

If in diskpart you do not see a small FAT32 EFI partition, you may be using Legacy boot.
Back in Command Prompt:

bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd

If /fixboot says “Access is denied”​

That’s common on some Windows 10 media. Tell me if you hit it and paste the exact message—there are a couple safe ways around it depending on your partition layout.

---

3) If it still won’t boot: offline system file repair​

From the same Command Prompt (using the correct Windows letter, example D:
sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
If SFC reports it can’t fix some files, tell me what it says (the summary line), and we’ll move to DISM offline repair.

---

4) Two key questions (so I can tailor the next step exactly)​

1) In BIOS, do you boot via an entry called “Windows Boot Manager”, or does it just list the SSD model name?
2) In diskpart → list vol, do you see a FAT32 volume ~100–300MB (EFI), yes or no?
If you can, paste the output of:

• diskpart → list disk
• diskpart → list vol

(Just a phone photo of the screen is fine.)

---

Important note about the NVMe showing as “unformatted”​

If Clonezilla had successfully cloned the whole disk, the NVMe would normally show partitions, not “unformatted.” That strongly suggests either:

• the clone didn’t actually write the partition table, or
• Windows was seeing the NVMe as Offline / conflicting / not initialized, or
• there’s an NVMe/controller/slot issue.

But first priority is getting the original SATA install booting again—then we can circle back and clone/migrate cleanly (best practice is: clone with only source+target connected, then first boot with ONLY the target connected).
Post those diskpart results and I’ll tell you exactly which volumes to select and which commands to run for your specific layout.

Hi estrogenEsports — that 0xc000000e + winload.exe screen almost always boils down to Windows Boot Manager / BCD pointing at the wrong “device” (partition GUID / disk) or the boot files on the EFI/System partition being damaged. Cloning + having both drives installed can trigger exactly that (UEFI entries can end up pointing to the “other” copy, or to a device ID that no longer matches).
Below is the most reliable way to fix it without reinstalling Windows, starting from the assumption you currently want to boot the original 1TB SATA SSD.

---

0) Quick BIOS/UEFI sanity check (very important)​

1) Physically disconnect everything except:

• the 1TB SATA SSD (your old Windows drive)
• keyboard/mouse
• (optionally) the Windows installer USB
  Also disconnect the 4TB HDD for now (it can confuse boot repair if it has old boot code).

2) Boot into BIOS/UEFI and verify:

• Boot mode: ideally UEFI (not Legacy/CSM) if your Windows was installed that way.
• Boot order: pick Windows Boot Manager (your SATA SSD) if it’s listed.
• If you see multiple “Windows Boot Manager” entries, choose the one that references the SATA SSD.

If you can’t clearly tell which entry is which, don’t worry—do the command-line repair below; it will recreate a clean boot entry.

---

1) Rebuild boot files the “UEFI/GPT” way (most common on modern systems)​

Boot from the Windows 10 installer USB → Repair your computer → Troubleshoot → Advanced options → Command Prompt.

A) Find your Windows partition letter​

In Command Prompt:

diskpart
list vol

Look for:

• A large NTFS volume (hundreds of GB) — that’s usually your Windows partition.
• A small FAT32 volume around 100–300 MB — that’s the EFI System Partition (ESP).

Now do these (replace X with the correct volume numbers you see):

select vol X   (this is the FAT32 EFI volume)
assign letter=S
exit

Now find the Windows letter (often it’s D: in recovery, not C. Check which one contains Windows:

dir C:\Windows
dir D:\Windows
dir E:\Windows

Assume the one that works is D: for the next step.

B) Run a disk check (good idea before rebuilding)​

chkdsk D: /f

C) Recreate the boot files + BCD​

bcdboot D:\Windows /s S: /f UEFI
Now reboot (remove the USB when it restarts) and see if Windows loads.

---

2) If your system is Legacy/MBR instead (alternative path)​

If in diskpart you do not see a small FAT32 EFI partition, you may be using Legacy boot.
Back in Command Prompt:

bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd

If /fixboot says “Access is denied”​

That’s common on some Windows 10 media. Tell me if you hit it and paste the exact message—there are a couple safe ways around it depending on your partition layout.

---

3) If it still won’t boot: offline system file repair​

From the same Command Prompt (using the correct Windows letter, example D:
sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
If SFC reports it can’t fix some files, tell me what it says (the summary line), and we’ll move to DISM offline repair.

---

4) Two key questions (so I can tailor the next step exactly)​

1) In BIOS, do you boot via an entry called “Windows Boot Manager”, or does it just list the SSD model name?
2) In diskpart → list vol, do you see a FAT32 volume ~100–300MB (EFI), yes or no?
If you can, paste the output of:

• diskpart → list disk
• diskpart → list vol

(Just a phone photo of the screen is fine.)

---

Important note about the NVMe showing as “unformatted”​

If Clonezilla had successfully cloned the whole disk, the NVMe would normally show partitions, not “unformatted.” That strongly suggests either:

• the clone didn’t actually write the partition table, or
• Windows was seeing the NVMe as Offline / conflicting / not initialized, or
• there’s an NVMe/controller/slot issue.

But first priority is getting the original SATA install booting again—then we can circle back and clone/migrate cleanly (best practice is: clone with only source+target connected, then first boot with ONLY the target connected).
Post those diskpart results and I’ll tell you exactly which volumes to select and which commands to run for your specific layout.

my system is UEFI, so I went straight to step 2. the fixmbr, fixboot and scanos commands all worked fine, however rebuildbcd did not, with it first asking me if I wanted to add my identified windows installation (E:\Windows) to the boot list. after pressing Y and enter to add it it said 'The requested system device cannot be found.

No other methods listed here were successful either. As for the key questions, my BIOS simply listed the name of my drive and not Windows at all. I also do not see a fat32 volume

 

[ChatGPT]

Thanks — what you’ve described actually explains the contradiction:

• The boot error references \Windows\System32\winload.exe (that’s the Legacy/BIOS loader).
• In true UEFI boot, you normally see winload.efi and you’d have a FAT32 EFI System Partition (ESP).
• You also said: BIOS shows only the drive model (not “Windows Boot Manager”) and you do not have a FAT32 volume.

So the most likely reality is:

Your Windows install on that SATA SSD is currently Legacy/MBR boot, even though your motherboard firmware supports UEFI.​

That’s also why bootrec /rebuildbcd is failing with “The requested system device cannot be found”: it can see E:\Windows, but it can’t find a valid system boot partition (active “System Reserved” NTFS partition) to write boot files to.
Below are two safe paths. Path A gets you booting ASAP. Path B converts you to proper UEFI (recommended long-term, especially if you want to migrate to NVMe cleanly).

---

Before anything (prevents making it worse)​

1) Disconnect the NVMe and the 4TB HDD. Leave only the 1TB SATA SSD connected.
2) Boot the Windows 10 USB → Repair → Command Prompt.

---

Step 1: Confirm if the disk is MBR or GPT (please do this)​

In Command Prompt:

diskpart
list disk

Look at the GPT column:

• If there’s a * under GPT for Disk 0 → it’s GPT/UEFI-capable.
• If there’s no * → it’s MBR/Legacy.

Also run:
list vol
Then post a photo or type the output of list disk and list vol here. (This lets me tell you the exact partition to target.

---

Path A (fastest): Boot in Legacy/CSM and rebuild boot files to an NTFS “System” partition​

This is the quickest “get me back into Windows” route.

A1) Identify (or create) the “System” boot partition​

In DiskPart:

select disk 0
list part

You’re looking for either:

• A small partition ~100–500MB often called System Reserved (NTFS), OR
• If it doesn’t exist, we may temporarily use the Windows partition itself.

If you DO see a small NTFS partition, do:

select part X
active
assign letter=R
exit

If you do NOT see a small partition, tell me what list part shows before we mark anything “active” (marking the wrong partition active can prevent boot).

A2) Write boot files​

(You said Windows is at E:\Windows in recovery, so I’ll use E: below.
If you assigned R: to a System Reserved partition:

bcdboot E:\Windows /s R: /f BIOS
bootsect /nt60 R: /mbr

If you end up using the Windows partition as system (not ideal, but works in emergencies), it would be:

bcdboot E:\Windows /s E: /f BIOS
bootsect /nt60 E: /mbr

A3) BIOS setting​

Reboot and in BIOS enable CSM/Legacy boot (or “UEFI + Legacy”). If you force “UEFI only” while the disk is MBR/Legacy, it typically won’t boot.

---

Path B (recommended): Convert the install to true UEFI (MBR → GPT) without reinstalling​

This is usually the “best fix” if your goal is UEFI + NVMe + “Windows Boot Manager”.

B1) Validate and convert​

From the same recovery Command Prompt:

mbr2gpt /validate /disk:0
mbr2gpt /convert /disk:0

If it says validation failed, paste the exact message (common reasons: too many partitions, not enough free space, etc..

B2) After conversion, rebuild UEFI boot files​

After conversion you should have (or be able to create) a FAT32 EFI partition. Then:

diskpart
list vol

Select the FAT32 EFI volume and assign it S:

select vol X
assign letter=S
exit

Then:
bcdboot E:\Windows /s S: /f UEFI
Finally set BIOS to UEFI boot and choose Windows Boot Manager.

---

One more important question​

When you boot and it fails, does the firmware boot menu show something like:

• “UEFI: <USB name>” and “<USB name>” as separate entries?

If yes, always pick the UEFI: version when doing UEFI repairs.

---

What I need from you to give the exact “do this, then this” steps​

Please paste (or photo) the outputs of:

1. diskpart → list disk
2. diskpart → list vol
3. diskpart → select disk 0 then list part

Then I’ll tell you exactly whether to use Path A or B, and which partition letter to use so you don’t accidentally target the wrong volume.

 

[estrogenEsports]

Thanks — what you’ve described actually explains the contradiction:

• The boot error references \Windows\System32\winload.exe (that’s the Legacy/BIOS loader).
• In true UEFI boot, you normally see winload.efi and you’d have a FAT32 EFI System Partition (ESP).
• You also said: BIOS shows only the drive model (not “Windows Boot Manager”) and you do not have a FAT32 volume.

So the most likely reality is:

Your Windows install on that SATA SSD is currently Legacy/MBR boot, even though your motherboard firmware supports UEFI.​

That’s also why bootrec /rebuildbcd is failing with “The requested system device cannot be found”: it can see E:\Windows, but it can’t find a valid system boot partition (active “System Reserved” NTFS partition) to write boot files to.
Below are two safe paths. Path A gets you booting ASAP. Path B converts you to proper UEFI (recommended long-term, especially if you want to migrate to NVMe cleanly).

---

Before anything (prevents making it worse)​

1) Disconnect the NVMe and the 4TB HDD. Leave only the 1TB SATA SSD connected.
2) Boot the Windows 10 USB → Repair → Command Prompt.

---

Step 1: Confirm if the disk is MBR or GPT (please do this)​

In Command Prompt:

diskpart
list disk

Look at the GPT column:

• If there’s a * under GPT for Disk 0 → it’s GPT/UEFI-capable.
• If there’s no * → it’s MBR/Legacy.

Also run:
list vol
Then post a photo or type the output of list disk and list vol here. (This lets me tell you the exact partition to target.)

---

Path A (fastest): Boot in Legacy/CSM and rebuild boot files to an NTFS “System” partition​

This is the quickest “get me back into Windows” route.

A1) Identify (or create) the “System” boot partition​

In DiskPart:

select disk 0
list part

You’re looking for either:

• A small partition ~100–500MB often called System Reserved (NTFS), OR
• If it doesn’t exist, we may temporarily use the Windows partition itself.

If you DO see a small NTFS partition, do:

select part X
active
assign letter=R
exit

If you do NOT see a small partition, tell me what list part shows before we mark anything “active” (marking the wrong partition active can prevent boot).

A2) Write boot files​

(You said Windows is at E:\Windows in recovery, so I’ll use E: below.)
If you assigned R: to a System Reserved partition:

bcdboot E:\Windows /s R: /f BIOS
bootsect /nt60 R: /mbr

If you end up using the Windows partition as system (not ideal, but works in emergencies), it would be:

bcdboot E:\Windows /s E: /f BIOS
bootsect /nt60 E: /mbr

A3) BIOS setting​

Reboot and in BIOS enable CSM/Legacy boot (or “UEFI + Legacy”). If you force “UEFI only” while the disk is MBR/Legacy, it typically won’t boot.

---

Path B (recommended): Convert the install to true UEFI (MBR → GPT) without reinstalling​

This is usually the “best fix” if your goal is UEFI + NVMe + “Windows Boot Manager”.

B1) Validate and convert​

From the same recovery Command Prompt:

mbr2gpt /validate /disk:0
mbr2gpt /convert /disk:0

If it says validation failed, paste the exact message (common reasons: too many partitions, not enough free space, etc.).

B2) After conversion, rebuild UEFI boot files​

After conversion you should have (or be able to create) a FAT32 EFI partition. Then:

diskpart
list vol

Select the FAT32 EFI volume and assign it S:

select vol X
assign letter=S
exit

Then:
bcdboot E:\Windows /s S: /f UEFI
Finally set BIOS to UEFI boot and choose Windows Boot Manager.

---

One more important question​

When you boot and it fails, does the firmware boot menu show something like:

• “UEFI: <USB name>” and “<USB name>” as separate entries?

If yes, always pick the UEFI: version when doing UEFI repairs.

---

What I need from you to give the exact “do this, then this” steps​

Please paste (or photo) the outputs of:

1. diskpart → list disk
2. diskpart → list vol
3. diskpart → select disk 0 then list part

Then I’ll tell you exactly whether to use Path A or B, and which partition letter to use so you don’t accidentally target the wrong volume.

I followed the first set of steps as instructed and it got me right back to my desktop. However, now when I boot up it asks me if I want to go to Windows or Windows on volume 2. Is there a way to get rid of this first volume as it is seemingly the one I was having issues with. It no longer works and I would not like to deal with this prompt every time I open my computer

 

[ChatGPT]

Yes — that prompt is just the Windows Boot Manager menu showing two BCD entries (usually created during the clone/repair). You can remove the unwanted entry and/or make it stop asking every boot.

Option 1 (easiest): Remove the extra entry via MSConfig​

1. Boot into the Windows install you want to keep.
2. Press Win + R → type msconfig → Enter.
3. Go to the Boot tab.
4. Click the entry that is your working Windows → click Set as default.
5. Click the other entry (the one you don’t want, e.g. “Windows on volume 2”) → click Delete.
6. Set Timeout to 0 (or 3 seconds if you want a safety net).
7. Click Apply → OK → restart.

That should remove the menu entirely.

---

Option 2 (more precise): Delete the bad boot entry with BCDEdit (Admin)​

1. Boot into the Windows install you want to keep.
2. Open Command Prompt (Admin) or Windows Terminal (Admin).
3. Run:

bcdedit /enum

1. Identify:
   • The entry you are currently booted into (often marked as identifier {current}).
   • The other entry (the one that says “Windows on volume 2”) and note its identifier GUID (looks like {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}).
2. Delete the unwanted one (replace {GUID} with the identifier you noted):

bcdedit /delete {GUID}

1. Optional: hide the menu / set timeout to 0:

bcdedit /timeout 0
Reboot and it should go straight in.
Important: Only delete the entry you’re sure you don’t need. If you’re not 100% sure which is which, tell me what bcdedit /enum shows for the two “Windows…” entries (you can paste it), and I’ll point out the safe one to remove.

---

If by “get rid of this first volume” you mean an actual partition​

Removing the boot menu entry does not delete any partitions/data. If you truly have an extra/broken Windows partition you want to reclaim, we can do that next in Disk Management, but we should first confirm:

• which partition you’re currently booting from
• where the boot files are (the “System” / “Active” partition in Legacy mode)

If you want, paste a screenshot (or text) of Disk Management showing Disk 0 partitions, and I’ll tell you exactly which partition is safe to delete/extend into.