0

Situation

I cloned the contents of my old (boot/OS) SSD to a new SSD. I then attempted (and failed) to edit the contents of the new SSD, and this has made me unable to boot from either drive.

Background

I have an old 256GB SSD (Windows 10) which serves as my main boot/OS drive. I wanted to replace this with a newer 1TB NVMe SSD. I used clonezilla to clone the contents of my old SSD to the new one (disk-disk, device-device, all options default). I did this successfully and was able to boot using the new SSD. After confirming that I could boot from the new SSD, I physically unplugged the old SSD. I also used GParted to extend the OS partition on the new SSD, as the size of the partition was small due to the smaller capacity of the old SSD. This was also successful.

At this point (being the greedy and stupid person I am) I booted into GParted again to delete one of the Windows recovery partitions that had transferred over from my old SSD to the new one. The size of this partition was 450MB, and windows partition manager said it was empty, so I thought why not. I used GParted to delete this partition and also extend the OS partition to encompass the freed space. Unfortunately, GParted threw an error (I forgot the exact error, but I think it had something to do with being unable to extend the OS partition).

This caused the new drive to be unbootable, with the error: The application or operating system could not be loaded because a required file is missing or contains errors. File: \windows\system32\winload.efi.

Assessment / Attempts to fix

My first reaction was to check the boot order in BIOS, and set new SSD's windows boot manager as the first device. This didn't fix the problem.

I then unplugged the new SSD and re-connected my old SSD. My naive reasoning was that, since I had done nothing to the old SSD except clone its contents, it would boot fine. This also threw an error, though a different one: A required drive isn't connected or cannot be accessed

My very general assessment of the situation is that it's "not too bad". Though I have not checked, I don't think the contents of my old SSD have been affected, meaning I should still have all the files on there. The new SSD I can just reformat and retry the cloning process again. There is also a HDD which has been connected the whole time, with some family photos on it (but no OS on it, so everything on there should be accessible using another device or fresh install).

Recommendations

I have minimal knowledge of the processes and files involved in Windows boot, so I'm not really sure what to do next..

  • Which drive is easier to fix?
  • What are the steps to troubleshooting and fixing boot drives with these errors, and in this context?

Update

Things I have tried:

  • Win10 Installation media > Startup Repair. I get the error Startup repair could not repair your PC
  • Repeating the clone from old SSD to new SSD (@John's suggestion). Booting from the new SSD now gives me the same error as booting from old: A required drive isn't connected or cannot be accessed

This leads me to believe the old SSD, which I thought had been untouched, is defective as well. I'm not sure what to do now

Update 2

Tried @dodrg's manual repair suggestion, and the computer now boots as normal! While using shell on live Windows, I was able to navigate my system drive using cd and dir, suggesting that only the files needed for booting were corrupted (not anything else). Thanks to everyone who gave me guidance and tips.

Improve this question
9
  • I cloned the contents of my old (boot/OS) SSD to a new SSD. ---- Can you repeat the process to start again with your new SSD? That is what I would try to do.
    – anon
    Commented Apr 25, 2023 at 12:48
  • And then do not delete partitions unless you know exactly what you're doing - that wasn't the case here, apparently - because you may make a mistake and delete the ESP (EFI System Partition) which is NOT a Windows recovery partition and is absolutely required to boot.
    – ChanganAuto
    Commented Apr 25, 2023 at 13:21
  • Or just restore the old SSD from the last backup disk image you made.
    – DrMoishe Pippik
    Commented Apr 25, 2023 at 17:51
  • @John – Thanks for the tip. This sounds logical, and I will give this a try if @dodrg’s solution doesn’t work.
    – tim9800
    Commented Apr 25, 2023 at 23:45
  • @John - Tried your suggestion (recloning old SSD to new SSD), and now booting from the new SSD is giving me the same error as when I try to boot from the old one: A required drive isn't connected or cannot be accessed. It seems the original SSD got damaged somehow in the process..
    – tim9800
    Commented Apr 26, 2023 at 11:33

1 Answer 1

Reset to default
0

The boot process is controlled by EFI. These informations are NOT stored on a disk but on the motherboard in the NVRAM.

The Current state

By [cloning|pluging|unplugging|deleting|booting|etc] without any plan, you probably managed to throw out some correct disk configurations and have an undefined state of your disks and an EFI system that tries to make the best of it.

Reading your description I assume:

  1. Your cloned copy is defect:
    1. EFI starts
    2. EFI chooses the cloned (?) disk
    3. EFI chooses the bootloader in the EFI partition
    4. The bootloader fails to find File: \windows\system32\winload.efi

=> Ergo the partition containing Windows is defect, probably due to the error while resizing with gparted.

  1. That the original disk does not boot (A required drive isn't connected or cannot be accessed) is probably due to the reactions of EFI on the missing disk. EFI will not change the data on the disk but its own in the motherboard's NVRAM. => If you didn't harm the disk the data should still be save.

The best thing you should have done BEFORE starting the whole action would have been to create the Recovery Media.
=> Very easy to do: Have a USB Stick > Access the Windows Menu > type "Recovery" > The app Create Recovery Media will show up and the wizard will lead you through the process.

The advantage of this recovery media is, that also your windows config and drivers for your system are included, making recovery actions easy also for complicated hardware constellations.
(should be updated on hardware changes or Windows upgrades)

A path for solving the problem:

1. Have a proper system disk

As you didn't write to the original disk (didn't you?) you should

  1. Re-clone the disk and work with the clone to keep the original untouched (as backup).
  2. You should not "optimize" the cloned disk (not now ...).
  3. Connect and configure the drives in BIOS as you want them to have in the final configuration.
2. Try to use the "Automatic Repair" functionality of Windows.
  1. Have a Windows Recovery media or a Windows installation media (hopefully a current one ...).
  2. Within the Recovery options you should search and choose the option to Repair the Boot Configuration Data

As hopefully you've provided an intact clone of a working Windows installation, this should succeed as broken BCD data is quite common.

3. Try a "Manual Repair" if "Automatic Repair" fails (simple version):
  1. Have a Windows Recovery media or a Windows installation media.
  2. Get a shell (Using the Windows installation disk press Shift+F10)
  3. Execute bcdboot C:\Windows
    (assuming your system drive is C:. Else replace)
  4. Reboot

Please note: To be able to update the answer with an useful next step, an accurate feedback is required. Here small deviations often will lead to total failure.

When done: Continue your migration project

When everything is working again without issues, you can go and resize your partition. The windows system tools also will do the job:

  • for command-line usage: start diskpart.exe
  • for graphical Management Console: start diskmgmt.msc
Improve this answer
7
  • I really appreciate the step-by-step explanation. I didn’t know that EFI is actually stored on the motherboard (not on the hard drive itself). Unfortunately, I don’t have a recovery media, though I do have a Win10 installation media handy so I will use that instead and report how it goes. For my own learning, how is gparted able to change EFI information located on the motherboard? As I thought gparted only edits information on the disk. Thanks again!
    – tim9800
    Commented Apr 25, 2023 at 23:44
  • gparted does not change the EFI settings (afaik). The EFI partition type itself has the attribute "bootable". Subsequent EFI will evaluate the content of the partition in context of its config in NVRAM. To change EFI settings manually, tools like bcdedit.exe (Windows), efibootmgr (Linux) or shellx64.efi (EFI Shell) are available. Type efibootmgr at the linux shell to see the config (use -v for more details). Usually you would see an entry called "Windows Boot Manger". In your config this entry might has vanished or contains values that have turned invalid due to your changes.
    – dodrg
    Commented Apr 26, 2023 at 7:39
  • Okay, I've tried the "Startup repair" option via installation media, and it was unable to fix the problem: "Startup Repair couldn't repair your PC". What now?
    – tim9800
    Commented Apr 26, 2023 at 9:56
  • Updated the answer. – Added a "Manual Repair" chapter
    – dodrg
    Commented Apr 26, 2023 at 12:55
  • You write "The boot process is controlled by EFI. These informations are NOT stored on a disk but on the board in the NVRAM." <-- You haven't said where the NVRAM is. And you've overlooked that an SSD might contain NVRAM(eg maybe they might store some firmware in NVRAM). And nowadays a hard drive is a board rather than disk. The whole statement is unclear. If you want to say that EFI info is stored on the motherboard(or in NVRAM on the motherboard), then say so. Don't just say board, when a hard drive like an SSD, is a board as much as a motherboard is. If you maen motherboard say motherboard.
    – barlop
    Commented Apr 26, 2023 at 13:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .