You did the conversion, the install seemed to finish — and now the PC powers on to 'No bootable device' or loops straight back to the BIOS. Before you conclude the disk is ruined, understand the most likely truth: Windows is sitting complete on that disk, but the firmware cannot find boot files that match the mode it is now using. Boot files are scheme-specific, and a mismatch is fixable.
A disk converted from MBR to GPT carries a Windows whose boot files were built for Legacy booting — a boot sector and a BCD store on a normal partition. A UEFI firmware does not read any of that. It looks for an EFI System Partition formatted FAT32 containing the Windows Boot Manager, and if conversion or a mode-flip left the machine without one, it reports no bootable device. The same failure runs in reverse: a GPT/UEFI Windows is invisible when firmware is set to Legacy. The fix order matters: first correct the mode, then — only if the mode is right — rebuild the boot files.
Half the 'conversion killed my PC' cases end here. A PC whose Windows was installed in UEFI mode will also refuse to boot if someone later enables CSM or flips to Legacy — same mismatch, zero damage, setting reverted.
A subtler failure: Setup itself was booted in the wrong mode, so it happily installed Windows with boot files for that mode — but your firmware is set the other way, or you converted the disk afterwards with a third-party tool that changed the style without touching the boot files. Symptoms are identical: no bootable device.
Decide now which end state you want (for any modern PC and all Windows 11: UEFI plus GPT), set the firmware to it, and if the boot files do not match that choice, rebuild them — next section. Do not keep flipping both variables at random; fix the mode first, permanently, then repair the boot files once.
If the mode is correct and the PC still will not boot, the boot files themselves are missing or belong to the other scheme. The outline of the repair, done from a Windows USB booted in the SAME mode as your target:
diskpart with list volume to find two things: the letter of your Windows partition in this environment (letters shift — it is often D: here) and the EFI System Partition (FAT32, about 100 MB, often letterless)assign letter=Z inside DiskPart, then exitbcdboot C:\Windows /s Z: /f UEFI — replacing C: with the Windows partition's actual letter you found. This writes fresh UEFI boot files into the EFI partitionIf the disk has NO EFI partition at all — a plain-converted disk may not — one must be created by shrinking the Windows partition, which is delicate work. That exact procedure, with its diskpart create partition efi steps, deserves a screen in front of you: it is demonstrated in repair videos, and it is the point where a beginner should slow down or call a technician rather than improvise.
clean and convert again would erase the Windows you just installed — the one total-loss move available at this momentThe calm sequence — check mode, check boot entry, rebuild boot files, escalate only then — resolves the overwhelming majority of post-conversion no-boots without losing a single file.
clean again — it erases the entire disk, including the Windows installation you are trying to rescue. A no-boot after conversion is a boot-file problem. Treat it as one.The video covers the install-side fix end to end — watch it before attempting any repair here, so the Setup screens and DiskPart prompts in this page are already familiar.
▶️ Watch Full VideoAlmost never. It means the firmware found no boot files of the kind it is configured to use. Your Windows and files normally sit intact on the disk. Boot a live USB or the installer's repair environment and browse the disk — seeing your folders there confirms the problem is only the boot files.
Same family of fix. The tool changed the disk style but the PC still needs two things: firmware switched to UEFI mode, and UEFI boot files — a converted disk needs an EFI System Partition with the Windows Boot Manager, created with bcdboot as outlined here. This is also why planned migrations use Microsoft's mbr2gpt, which handles the boot files as part of the conversion.
Automatic Startup Repair often fails when the boot configuration fundamentally mismatches the firmware mode — it repairs within the mode it booted in. Boot the repair USB in the correct mode (UEFI for GPT), confirm the firmware is set to match, and the manual bcdboot route succeeds where the automatic one loops.