Repair Windows Startup from Recovery Media: Startup Repair, bootrec and bcdboot in the Right Order — What Each One Changes and When to Stop

This guide covers one situation in depth: a Windows 10 or 11 machine that no longer reaches the desktop, which you are repairing from recovery media — either by booting official installation media and choosing “Repair your computer”, or by forcing the built-in recovery environment. It is decision-driven rather than command-driven: each section ends with what to do next based on what you observed, not with a fixed list of things to run. If your machine powers on, posts, and simply misbehaves after login (crashes, slow starts, update failures), this is the wrong guide — that territory is covered by the Windows troubleshooting library.

Why the decision-first approach matters: “Windows won’t boot” hides at least four different failure classes, and they have different correct first moves. A missing BCD store wants a different repair than a corrupted system file after an update, which wants a different one than a failing drive. The tools overlap (bcdboot can fix things Startup Repair missed), but the order is not interchangeable: diagnostics that only read are always safe to run first; operations that rewrite boot records or boot files should be applied once, against a target you have positively identified, and re-tested before anything else changes.

One more boundary worth stating up front: this guide never asks you to format partitions, delete files from an EFI system partition you do not understand, rebuild partition tables, or run destructive disk operations. Where a repair path requires choosing between “repair” and “preserve data first”, the preserve-data path wins whenever there is any sign of storage trouble.

Windows startup is a chain of hand-offs, and a “boot failure” is a break somewhere in that chain. On power-on, the firmware (UEFI or legacy BIOS) performs its own initialization, then hands control to the first boot code it can find: on a legacy MBR disk that is the master boot record, which locates the active partition’s boot sector; on a UEFI GPT system the firmware reads the partition table directly and loads \EFI\Microsoft\Boot\bootmgfw.efi from the EFI system partition. That first-stage code loads the Windows Boot Manager (bootmgr.exe on legacy systems, the bootmgfw component under UEFI), which in turn reads the BCD store — a small database of boot configuration entries — to learn which operating system loader to start and from which volume. Only then does winload load the kernel and Windows itself appears.

Every repair tool in this guide acts on a specific link of that chain, which is why “just run the boot commands” is not a strategy. Startup Repair attempts fixes across several links automatically and reports what it found. The bootrec switches act narrowly: /scanos only reads, /rebuildbcd rewrites entries in the BCD store, /fixmbr rewrites the master boot record (a legacy-architecture component), and /fixboot rewrites the boot sector of the system partition. bcdboot works at file level: it copies a fresh set of boot-environment files from your Windows installation to the system partition or EFI system partition and recreates the BCD store there. If you apply a tool to the wrong link — for example, rewriting an MBR that is not part of your boot path because the machine boots UEFI — you have changed something without fixing anything, and now two things are different from before.

The second prerequisite for safe repair is knowing which architecture you are on, because the chain looks different in the two cases. The table below lists the differences that actually change your repair procedure. You will verify your machine’s mode with read-only commands in section 5 — do not assume from the age of the computer; many machines from the UEFI era were deliberately configured to boot legacy, and a GPT disk with a protective MBR is not the same thing as an MBR disk.

Table D — What differs between UEFI/GPT and legacy BIOS/MBR

Two consequences follow. First, the correct repair procedure is a function of your architecture: the legacy column of that table is essentially inapplicable to a UEFI machine, and bcdboot’s default target differs completely between the two. Second, “the system partition” is not always C: — under UEFI it is usually an unlettered or differently-lettered FAT32 volume that File Explorer will not even show you by default. Section 5 exists to establish both facts with read-only commands before any write operation happens.

Back up before you change boot configuration

Boot repair is low-risk compared with disk surgery, but it is not risk-free: the operations in sections 7–9 rewrite boot records, boot files or the BCD store, and on a machine whose underlying problem is storage degradation rather than configuration damage, any additional write activity makes data recovery harder. If you can still reach the desktop, copy what matters to an external drive now and verify the copy opens — the Back up your PC guide covers the mechanics. If Windows will not start at all, you still have options: WinRE includes a File Explorer (section 4) that can copy files to an external drive, and a Linux live USB mounts NTFS volumes read-only by default, which is the gentlest way to pull data off a machine you suspect of failing.

The practical rule: if the data on the machine would be genuinely painful to lose, get it off first, even if that means an hour of copying before any repair attempt. If the data is regenerable or already backed up, proceed — but know which case you are in, because section 12’s stop conditions depend on exactly that distinction.

Find your BitLocker recovery key before you need it

If the system drive is BitLocker-encrypted — standard on Windows 10/11 Pro and common on Home with device encryption — every repair tool in this guide hits a wall until the volume is unlocked. WinRE cannot see inside an encrypted volume, so bcdedit may show no usable entries, bootrec /scanos finds nothing, and bcdboot cannot read the source installation. The 48-digit recovery key is what unlocks it from WinRE; check now where yours lives: your Microsoft account’s devices page (when the device was signed in), a printed copy or file you were shown at activation, or an Active Directory attribute if this is a work machine. If you cannot find it and the volume is encrypted, that fact changes the plan — section 12 explains why.

Use recovery media you can trust

There are two routes into WinRE, and they are not equivalent in reliability. The built-in recovery partition is convenient but lives on the same disk you are trying to repair — if that disk is failing, so is your access to recovery. Official Windows installation media (a USB created with Microsoft’s Media Creation Tool) boots independently of the internal disk and offers “Repair your computer”, which lands in the same WinRE command prompt. The Create a bootable USB guide walks through making one, including verifying the download before writing it. For this workflow, prefer installation media: it also gives you access to the full set of recovery options even when the local recovery partition is damaged or missing.

The Windows Recovery Environment is a minimal Windows that runs from memory or a recovery partition, with its own set of tools: Startup Repair, System Restore, an offline SFC/DISM, and — the workhorse for this guide — a command prompt. You need the command prompt even when you start with Startup Repair, because interpreting what happened (and what to do next) happens there. Three entry points, in order of preference:

1. Boot from installation media. Insert the USB, boot from it (your firmware’s boot menu — commonly F8, F11, F12 or Esc at power-on), and on the setup screen choose Repair your computer instead of Install. Then: Troubleshoot > Advanced options. This route works even when the internal disk’s recovery partition is damaged.
2. Force Automatic Repair. If you cannot get to a boot menu or media: at the “Starting Windows” spinner, hold the power button until the machine is off, and repeat this two more times. On the next start, Windows enters “Automatic Repair”, which leads to Troubleshoot > Advanced options. This uses the local recovery partition.
3. Advanced startup from Settings (only if you can still reach the desktop): Settings > System > Recovery > Advanced startup > Restart now. Then the same Troubleshoot path.

Two things to expect at this stage. First, if the drive is encrypted you will be asked for the BitLocker recovery key before or during these steps — that is normal, and it is why section 3 put finding the key first. Second, once inside WinRE the drive letters you remember from normal Windows are probably wrong: the recovery environment reserves C: for its own use, so your Windows installation is commonly D: or E:. Never type a drive letter from memory in this environment — section 5 identifies each one with evidence.

This section is all read-only: every command below only inspects. Write down (or photograph) three facts before any repair step — your firmware mode, the letter of your Windows volume in WinRE, and the identity of your system partition or EFI system partition. Every later decision in this guide branches on these facts, and they are exactly the things people get wrong when they type from memory.

Step 1 — Confirm the firmware mode

Open Command Prompt from Advanced options and run:

bcdedit /enum firmware

Cross-check with the disk layout, because firmware mode and partition style should agree: in diskpart, list disk followed by detail disk on your Windows disk reports the partition style — GPT or MBR. A UEFI-booted machine expects GPT; an MBR-style disk with a Windows installation is almost certainly legacy-booting (a GPT disk can be booted only through special hybrid setups that are rare on consumer PCs). If the two checks disagree, stop and re-examine before proceeding — that mismatch usually means you are looking at the wrong disk or a machine with an unusual configuration, and guessing from here is how dual-boot systems get broken.

Step 2 — Find your Windows volume’s real letter

The most reliable pointer is the BCD store itself: in its Windows Boot Loader section, the osdevice line names the volume that holds the operating system. If the BCD store is damaged (which may be part of your problem), fall back to listing each drive’s top-level folders — the Windows installation is the one with both a Windows and a Program Files directory.

bcdedit
dir D:\
dir E:\

Step 3 — Identify the system partition or EFI system partition

This is the partition that bcdboot will write to by default, so it deserves its own careful identification. In diskpart, list volume shows every volume with its file system, size and label. On a UEFI machine you are looking for the EFI system partition: FAT32, typically 100–500 MB, often labelled “System” or left unlabelled, type shown as “EFI System”. On a legacy machine it is a small NTFS volume marked Active. Note its volume number and letter (assign one with assign letter=S in diskpart if it has none — assigning a letter changes nothing on disk, it only gives you a handle for inspection).

diskpart
list volume
detail disk 0
exit

Step 4 — Check encryption state

Finally, check whether any volume you plan to touch is locked. If the Windows volume shows as locked, nothing downstream will work until it is unlocked with the recovery key from section 3.

manage-bde -status

manage-bde -unlock D: -RecoveryPassword 000000-000000-000000-000000-000000-000000-000000-000000

Startup Repair is the automated first attempt, and it deserves that slot for a specific reason: it is safe to run without knowing the diagnosis. From WinRE it is reached via Troubleshoot > Advanced options > Startup Repair > Restart. It scans the machine and attempts to fix common startup problems automatically — per Microsoft’s documentation, missing or damaged system files, corrupted boot configuration data (BCD), a damaged master boot record, incompatible drivers and registry errors. If your device is encrypted, it will ask for the BitLocker recovery key before it can work, which is one more reason section 3 put finding that key first.

The important habit is in how you read the outcome. A success message followed by a machine that actually reaches the desktop means you are done — verify over the next few reboots (section 10) and stop making changes. The far more common outcome on a genuinely broken system is “Startup Repair could not repair your PC”, and that message is not a verdict that nothing can be done: it is the tool telling you its automated passes did not cover your specific failure, and pointing you to the command prompt for manual options. That is precisely where this guide takes over. What you should not do is run Startup Repair again and again expecting a different result — without new information between attempts, it will do the same work and reach the same conclusion.

One nuance worth keeping: Startup Repair’s scope includes things you cannot see from the command prompt, and its failure report is stored on the Windows volume at \Windows\System32\Logfiles\STARTUP.REP. If you have already completed section 5, open that file after a failed run (it may be empty or absent on some builds — treat it as evidence when present, not as something that must exist). It can name the specific component the tool flagged, which sharpens your choice between the bootrec and bcdboot paths in the next sections.

From here the workflow branches on what section 5 established. If Startup Repair failed (or you chose to skip it because your symptoms already pointed at system files rather than boot configuration), go to the command prompt and start with the read-only diagnostics in section 7 before applying anything.

bootrec is WinRE’s repair tool for the boot environment, and its four switches are routinely misused as a single incantation. They are not one operation: two of them only read, and the other three write to different components with different scopes — and two of the writing switches are essentially meaningless on UEFI systems. The table below separates orientation (read vs modify) from effect, so you can see at a glance which commands are safe to run first and which commit a change.

Table B — bootrec command reference

The pattern to internalize: /scanos tells you what can be seen; /rebuildbcd, /fixmbr and /fixboot each change one specific component. A sound sequence on a legacy machine is scan → rebuild the entry if missing → fix the MBR or boot sector only if the evidence points there. On UEFI, the honest reading of that table is that /scanos is your diagnostic and bcdboot (next two sections) is usually your repair.

/scanos — the safe first step

bootrec /scanos

A successful result looks like “Windows found at [D:\]” (with your actual volume letter) or a count of one or more installations. That is useful confirmation that the BCD tooling can see your installation and know where it lives. A zero-result output does not prove Windows is gone — it proves this tool, in this state of the system, could not find it. The usual causes are an encrypted volume that is still locked, a filesystem that needs checking, or a BCD store so damaged that the scan has nothing to work against. Re-run section 5’s checks in that case (especially the BitLocker status), and run a filesystem check on the Windows volume before concluding the installation is missing.

/rebuildbcd — restore missing boot entries

bootrec /rebuildbcd

If it finds an installation, it will ask for confirmation to add it to the startup list — answer yes. A success message followed by a working boot means the missing entry was the problem and you are done (verify per section 10). If it reports that no Windows installations were found, do not keep retrying: that output is the same signal as /scanos’s zero result, and the correct response is to go back to section 5 (encryption state, volume letter, filesystem check) or, if the BCD store itself is absent or unreadable, to the bcdboot path in section 8, which recreates the store rather than adding entries to it.

/fixmbr — legacy MBR boot code only

bootrec /fixmbr

This is the standard fix when a legacy machine’s MBR boot code is damaged — for example after a partitioning tool or an old OS install overwrote it. It rewrites only the boot code, not the partition table, so your partitions and data are untouched by the operation itself. Two cautions: on a UEFI/GPT machine it has no useful job and should simply not be run; and on a legacy dual-boot machine whose Linux bootloader occupies the MBR (common with older GRUB installs), rewriting it will remove that first stage — which is exactly the scenario topic of a dedicated dual-boot recovery article, and a reason to validate your target carefully before writing.

/fixboot — the system partition’s boot sector

bootrec /fixboot

A clean success on a legacy machine with a damaged boot sector is one of the more satisfying fixes in this workflow. The well-known failure is “Access is denied”, which has two common causes: the volume is locked (BitLocker — unlock it per section 5 and retry) or, on UEFI systems, the command is aimed at a component that is not where your boot path actually runs. On UEFI machines the practical equivalent of this repair is bcdboot copying fresh boot files to the EFI system partition (section 9), so treat /fixboot’s failure there as a signal to switch tools rather than to fight permissions.

bcdboot is the file-level repair: it copies a complete, known-good set of boot-environment files from a Windows installation you specify to the system partition (legacy) or EFI system partition (UEFI), and creates the BCD store there using the BCD template inside that same installation. Microsoft documents it for exactly this kind of situation — a corrupted or missing system partition being rebuilt from new copies of the files on the Windows partition, and boot-menu repair on dual-boot machines. It is the strongest non-destructive repair in this guide, which is also why its source and target choices deserve a deliberate decision rather than a default.

Bcdboot is the right tool when the evidence points at the boot files or the BCD store itself: “Windows Boot Manager” errors on a UEFI machine whose EFI system partition contents are missing, damaged or inconsistent; a legacy machine where /fixmbr and /fixboot have not resolved the failure; or a rebuilt/reinstalled Windows that simply never got its boot environment set up. It is not the right tool when the problem is elsewhere in the chain — a corrupted system file after an update (section 10’s offline SFC/DISM), a failing disk (section 12), or a missing installation entirely. Running bcdboot against a healthy-but-unrelated configuration to “see if it helps” rewrites boot files and, on UEFI, the firmware’s NVRAM entry, so you have changed the system without addressing the cause.

Choosing the source

The source is the Windows directory of the installation you want to boot — D:\Windows in the examples below, where D: is whatever your verified Windows volume letter actually is (section 5). Bcdboot reads its boot files and BCD template from that installation, so a wrong source means a wrong repair: pointing it at an old Windows folder on a second disk rebuilds the boot environment for an installation you may not even want. If section 5 left any ambiguity about which volume is the one you intend, resolve it before this step.

Choosing the target — and why the defaults are usually right

By default, bcdboot writes to the system partition identified by the firmware: on UEFI that is the EFI system partition (it copies the files under \Efi\Microsoft\Boot, creates the BCD store there, and adds or updates the Windows entry in the firmware’s NVRAM boot list, placing it first by default), and on legacy systems the active partition (creating \Boot). For a single-Windows machine whose firmware mode you confirmed in section 5, that default is exactly what you want — no extra switches needed. The explicit options exist for situations that are not yours unless they match:

• /s <volume> overrides the target partition. Microsoft’s reference is blunt that this option “should not be used in typical deployment scenarios” — it is for configuring a drive that will boot on another computer, or a deliberately chosen secondary system partition. If you use it, the volume must be one you positively identified in section 5; pointing it at another disk’s EFI partition (a second OS, an old drive) rewrites that system’s boot environment. Note also that with /s on UEFI, no NVRAM firmware entry is created — the firmware is left to find the files by its default search path.
• /f <UEFI|BIOS|ALL> forces the firmware type of the files written. It requires /s, and using a value that does not match the machine’s actual boot architecture produces a configuration that cannot boot. If you are confident about the firmware mode (section 5), the default already matches it — forcing is for building media, not for repairing the machine in front of you.
• /p preserves the existing position of the Windows Boot Manager entry in the UEFI boot order instead of moving it to first. On a dual-boot machine where another OS must stay first (or where you want the firmware menu unchanged), this is the switch that keeps bcdboot from reordering your boot list.
• /v enables verbose output — worth adding on first runs, because it names each file being written and makes failures easier to place.

One more behaviour matters for multi-installation machines: when bcdboot creates the new BCD store, an existing boot entry for the same Windows partition is replaced by default (its values are not carried over unless you pass /m), while entries for other installations are preserved on current Windows versions. That is generally the behaviour you want — your intended installation gets a clean entry, the others survive — but it means the operation is still a change to a shared configuration, and the pre-flight validation in section 9 is what keeps that change scoped to the right target.

This section is the write step, so it begins with a gate: do not run bcdboot until each item below is true for your machine. The commands are short; the validation is what makes them safe.

1. Source validated. You know the Windows volume letter (section 5, step 2) and it contains the installation you intend to boot — confirmed by dir, not assumed.
2. Target identified. You know which partition is the system partition (legacy) or EFI system partition (UEFI) from diskpart’s file system, size and label (section 5, step 3) — and on multi-disk machines you are certain it belongs to this installation’s disk.
3. Firmware mode confirmed (section 5, step 1), so the default target behaviour matches your machine. If you intend to pass /s, you have a specific reason and the volume is positively identified.
4. Encryption resolved. The Windows volume is unlocked (section 5, step 4); a locked source cannot be read by bcdboot.
5. Backup decision made (section 3): important data is copied off, or you have consciously accepted the risk for regenerable data.

All five true? Run the rebuild. Replace D: with your verified Windows volume letter; add /v for verbose output on a first run:

bcdboot D:\Windows /v

Read the output before rebooting. A clean result lists the boot manager location (something like X:\EFI\Microsoft\Boot\bootmgfw.efi on UEFI or X:\bootmgr on legacy) and confirms the files were created. If it reports an error instead — access denied, a missing item, a volume problem — stop and interpret it with section 13 rather than retrying blindly; most bcdboot failures point back at one of the five gate items (locked volume, wrong letter, target partition issue).

bcdedit /enum all
dir S:\EFI\Microsoft\Boot

The only real test is a reboot — and the first practical detail is to remove the installation media before restarting, or the machine will simply boot from the USB again and you will have tested nothing. A successful repair looks like this: the firmware finds the Windows Boot Manager (UEFI) or MBR chain (legacy), the OS loader starts, and you reach the desktop without returning to Automatic Repair. Give it a few reboots and a normal day of use before declaring victory — some corruption (a half-written file, a bad driver) only reveals itself under load.

If the machine still fails to start, the failure itself is now more informative than it was an hour ago, because you know which components are structurally sound. Work through the evidence in order: first, re-run bcdedit /enum all and confirm the store still lists your installation with a sensible osdevice — if the entry vanished or changed after a write operation, that operation did not land where you expected. Second, check the boot files exist where section 2 says your architecture expects them (the verification block in section 9). Third, look at the Startup Repair report (\Windows\System32\Logfiles\STARTUP.REP on the Windows volume) if the machine passed through Automatic Repair — it may name the specific component that is failing. Only when the boot configuration checks out and the machine still cannot start should you conclude the problem sits deeper, in the operating system files themselves.

That deeper case has its own standard repair: offline system-file checks against the Windows volume. These are modifying operations (they replace corrupted system files from the component store), but they are scoped to the OS installation and do not touch boot configuration:

sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
DISM /Image:D:\ /Cleanup-Image /RestoreHealth

If the machine boots now, finish with section 15’s checklist and stop making changes. If it still does not boot after a clean boot-configuration verification plus system-file repair, you have exhausted the safe command-line path: the remaining explanations are storage failure, hardware, or a configuration problem that needs more information than this environment provides. That is section 12’s territory — and reaching it with evidence in hand (what you checked, what passed, what failed) is exactly the state you want to be in before escalating.

Everything so far is also available as a single symptom-to-action map. Use it when you are mid-repair and want to confirm you are on the right branch, or when a new error appears and you need to re-orient. The “when to stop” column is part of the decision, not an afterthought: each row names the condition under which further command-line repair should give way to data preservation.

Table C — Symptom-to-next-action matrix

Notice what the matrix does not contain: no row says “run all four bootrec commands and bcdboot until one works.” Each symptom has one or two sensible next moves, and every row knows when to stop. If your situation does not match any row, the honest answer is that you need more information than a symptom table can provide — gather the read-only evidence from section 5, and treat that as your diagnostic record.

Every repair command in this guide is a write to a machine that is already not working. That is acceptable while the evidence says the problem is configuration — writes are how you fix configuration. It stops being acceptable the moment there is any sign that the storage itself, or your ability to identify the right target, is in question, because then each additional write attempt raises the cost of a recovery you may still need. The stop conditions are explicit so the decision does not depend on nerve:

• Signs of storage failure. Clicking or grinding from a drive, a disk that disappears between firmware and diskpart, volumes reporting wrong sizes or 0 MB, or chkdsk reporting errors it cannot repair. These point at hardware or filesystem collapse, where the correct next step is preservation, not repair.
• Two full diagnostic-and-repair loops without new evidence. If you have identified everything (section 5), applied the targeted repair the diagnosis indicated, verified (sections 9–10), rebooted, and are back at the same failure with nothing newly observed, repeating the loop is not a strategy. More information (logs, manufacturer diagnostics, another environment) is the next requirement.
• An encrypted volume without its recovery key. You cannot inspect or repair what you cannot read, and guessing does not exist — BitLocker’s whole design makes the key the gate. The correct moves are retrieving the key (Microsoft account, printed copy, IT department) or, if it is truly unrecoverable, treating the data as lost and planning around that.
• A multi-OS or multi-installation machine where you cannot positively identify the intended target. Repairing the wrong configuration can break a system that was working. Until section 5’s evidence leaves no ambiguity, the safe action is to stop writing.

When a stop condition applies, the workflow changes from repair to preservation, in this order: first, get an image of the affected disk if you can (disk-imaging tools run from another bootable environment, or by connecting the drive to a working machine — an image is your safety net for everything that follows); second, copy the specific files that matter via WinRE’s File Explorer or a Linux live USB mounted read-only; third, only then decide between a clean reinstall (the Install Windows 11 from a USB drive guide covers it) and professional data-recovery service, which is worth the cost for data that cannot be replaced. A working system you rebuilt is replaceable; the only truly irreplaceable thing on a failing machine is the data on it.

Escalation is not failure. If you stop here with a clean diagnostic record — firmware mode, volume letters, partition layout, what each repair attempt changed, and what the machine still does wrong — you have done the maximum that safe command-line work allows, and you hand the next person (a friend with more hardware knowledge, a repair shop, Microsoft support) exactly the information they would otherwise spend an hour re-deriving.

Error text is the machine telling you where it thinks the break is. The table below maps the messages you are most likely to meet in this workflow to what they usually mean and the safe next move — as a lookup, so you can re-orient without re-reading whole sections.

If your message is not in this table, resist the temptation to pattern-match it to the closest row. The reliable move is the same one everywhere in this guide: gather the read-only evidence (firmware mode, volume letters, BCD contents, boot-file locations), identify which link of the chain from section 2 the failure sits at, and apply only the operation scoped to that link.

Work through this list before and after your repair. Your progress is saved on this device.

Before you change anything

• Important data is copied to another drive (or its loss is an accepted risk)
• BitLocker recovery key located and written down, if the drive is encrypted
• Recovery media boots into WinRE on this machine
• Firmware mode confirmed with bcdedit /enum firmware and diskpart (UEFI or legacy)
• Windows volume letter verified in WinRE (bcdedit osdevice + dir), not assumed
• System partition / EFI system partition identified by file system, size and label

After the repair

• Boot files present where the firmware mode expects them (dir check, section 9)
• BCD store lists the intended installation (bcdedit /enum all)
• Machine reaches the desktop with the recovery media removed
• Still boots normally after a few reboots and normal use
• Other operating systems’ boot entries still present (dual-boot machines only)
• No new disk-health warnings (SMART) since the repair

Related guides on this site

Each of these covers an adjacent step of the same territory: making the media, protecting the data, the broader startup picture, and the last-resort clean install.

Technical references

The Microsoft documentation used to verify the command behaviour described in this guide. Read them when you want the primary source behind a specific claim.

• Microsoft Support — Startup Repair: what the tool checks, how to reach it, and its BitLocker key requirement.
• Microsoft Learn — BCDBoot Command-Line Options: bcdboot’s file behaviour, NVRAM handling, and the /s, /f, /p, /v, /m, /d, /c parameters.
• Microsoft Learn — bcdboot (Windows Commands): syntax and the default system-partition behaviour.
• Microsoft Learn — Use WinRE to troubleshoot common startup issues (KB 4026030): entering WinRE from installation media, finding the system volume with bcdedit, and offline chkdsk/SFC/DISM.
• Microsoft Learn — Windows startup issues troubleshooting: the scanos → rebuildbcd sequence and restoring from a BCD backup.
• Microsoft Learn — MBR2GPT: the MBR/GPT and UEFI/BIOS partitioning context behind Table D.
• Microsoft Learn — diskpart: the volume and disk inspection commands used in section 5.
• Microsoft Learn — manage-bde: BitLocker status and unlock from the command line.