Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
What the BCD store is and where it lives, how to read it with bcdedit /enum, the bcdedit commands technicians use with their undo lines, the hypervisor and BitLocker side effects, and when bcdboot is the better tool.
A machine that boots into Safe Mode every time, a VM host that suddenly runs every guest at half speed, or a laptop that asks for its BitLocker key after a tech "just changed one setting" all lead back to the same small database. BCDEdit is the built-in tool for reading and editing it, and a handful of its commands handle the common boot tickets. This guide covers where the store lives, how to read it, the bcdedit commands technicians use most, and the habits that keep a one-line change from turning into a recovery job.
The Boot Configuration Data store is a small registry-format database that tells Windows Boot Manager what it can start and how. Every boot entry, the default choice, the menu timeout, and per-entry switches such as Safe Mode or the hypervisor all live in it. Microsoft's bcdedit reference describes the store as the replacement for the old Boot.ini file, and BCDEdit as the command-line tool for managing it.
Where the file sits depends on the firmware mode. On a UEFI machine it is \EFI\Microsoft\Boot\BCD on the EFI System Partition, a small FAT32 partition with no drive letter. On a legacy BIOS machine it is \Boot\BCD on the active partition, usually the hidden System Reserved partition. Neither location is visible in File Explorer by default, which is why you edit the store through BCDEdit rather than by hand. If you are not sure which mode a machine boots in, our MBR vs GPT guide shows how to check the partition style that goes with each.
Every BCDEdit change needs an elevated prompt. Microsoft's command-line reference adds a detail that catches people out: after modifying the store, a normal shutdown and restart is needed so the change is flushed to disk. A forced power-off right after an edit can leave the old value in place.
Run bcdedit with no arguments and you get the same output as bcdedit /enum active: the boot manager entry plus every Windows entry on the menu. bcdedit /enum all adds the hidden entries, such as the memory diagnostic, the recovery environment and the resume-from-hibernate loader. bcdedit /v prints every identifier as a full GUID instead of its friendly name, which you need when two entries look the same.
The friendly names are the part worth learning. {bootmgr} is Windows Boot Manager itself, and settings like the timeout and display order sit on it. {current} is the entry the machine booted from right now. {default} is the entry Boot Manager picks when the timeout runs out. On a single-boot machine {current} and {default} are the same entry, so either works in a command, but on a machine booted from WinRE or install media {current} points at the recovery environment, not the installed Windows. That is why repair commands run from WinRE use {default}.
Read before you write, every time. The output tells you which entry you are about to change, what device and path it boots, and which switches are already set. A command run against the wrong entry, or the wrong store, is the mistake that reading first prevents.
The common boot tickets need fewer than ten commands, and every one that changes something has a matching command that undoes it. The table pairs them.
| Job | Command | Undo |
|---|---|---|
| Back up the store | bcdedit /export C:\BCD-backup | bcdedit /import C:\BCD-backup |
| Next boot into Safe Mode | bcdedit /set {default} safeboot minimal | bcdedit /deletevalue {default} safeboot |
| Safe Mode with networking | bcdedit /set {default} safeboot network | bcdedit /deletevalue {default} safeboot |
| Bring back the F8 menu | bcdedit /set {default} bootmenupolicy legacy | bcdedit /set {default} bootmenupolicy standard |
| Stop automatic WinRE on failed boots | bcdedit /set {default} recoveryenabled no | bcdedit /set {default} recoveryenabled yes |
| Free VT-x for VirtualBox or VMware | bcdedit /set hypervisorlaunchtype off | bcdedit /set hypervisorlaunchtype auto |
| Load a test-signed driver (diagnostic) | bcdedit /set testsigning on | bcdedit /set testsigning off |
| Kernel debugging | bcdedit /debug on | bcdedit /debug off |
The import line deserves a warning before anything else. Microsoft's reference says /import deletes every existing entry in the system store before it restores the backup, so it is a full rollback, not a merge. Export first, every time, and keep the file somewhere other than the disk you are about to change.
The safeboot switch is the most useful command on the list and the one most often left behind. Set it, restart, and the machine comes up in Safe Mode on every boot until someone deletes the value. msconfig's "Safe boot" checkbox writes the same switch, which is how users end up in a loop they cannot explain.
It is also the trick behind a classic storage-controller change. Switching a controller mode in firmware, such as Intel VMD or RAID to AHCI, leaves Windows without the driver it needs at boot. Setting safeboot first forces Windows to load a minimal driver set, find the new controller and install the right driver, and the next normal boot works. The r/ASUS thread below is a clean example from October 2025: safe mode on, VMD off in UEFI, one boot into Safe Mode, then back to normal, with no reinstall.
The poster's own caveat applies to anyone copying it: check first that the disk is not part of a RAID array, because the trick moves a single disk between drivers and does nothing for an array. For the other ways into Safe Mode, and what each one loads, see our Safe Mode guide.
bcdedit /set hypervisorlaunchtype off is the command forums give for VirtualBox or VMware running slowly on Windows 11. It stops the Windows hypervisor from loading at boot, which frees the processor's virtualization extensions for the third-party product. Microsoft's own troubleshooting article, updated March 2026, explains why: only one software component at a time can use the hardware extensions, so when Hyper-V is running, other products "might fall back to a slower, emulated mode".
The same article names the cost. Memory Integrity and Credential Guard both run on the Windows hypervisor, so turning it off turns them off too. On a managed laptop that is a security change, not a performance tweak, and it should go through the same approval as disabling any other protection. WSL 2 and Windows Sandbox stop working as well, because they also run on the hypervisor.
The October 2026 r/virtualization thread below shows the diagnosis in practice. A Windows 11 guest stuttered in VirtualBox but ran smoothly in VMware on the same host, with Hyper-V features already off. The replies pointed out that Memory Integrity on the host can still load the hypervisor, suggested the bcdedit command, and noted VirtualBox's turtle icon as the tell that it has fallen back to running on Hyper-V.
Run msinfo32 and look for "A hypervisor has been detected" to confirm whether it loaded, before and after the change. For how the two kinds of hypervisor differ, our virtualization explainer covers type 1 and type 2 in plain words.
Two switches loosen driver signature rules, and both belong in a lab, not on a user's laptop. testsigning on lets Windows load kernel drivers signed with any certificate, and Microsoft's test-signing page notes that Windows puts a "Test Mode" watermark on the desktop as a reminder. nointegritychecks on disables integrity checks altogether. Microsoft's reference says the second cannot be set while Secure Boot is on, and the first returns "The value is protected by Secure Boot policy" on most current machines for the same reason.
That protection is the point. If a forum fix asks you to turn off Secure Boot so a driver will load, the driver is the problem. Use the switches to prove a theory on a test machine, then turn them off and get a signed driver from the vendor.
BitLocker measures the boot configuration, so a change to the BCD can look like tampering at the next start. Microsoft's options reference says it directly: before setting BCDEdit options you might need to disable or suspend BitLocker and Secure Boot. Suspend protection for one restart with manage-bde -protectors -disable C: -RebootCount 1, make the change, and let it resume on its own. Have the recovery key ready anyway, as covered in our BitLocker guide.
When Windows will not start at all, run BCDEdit from the recovery environment. Without a drive letter for the EFI partition the command often fails with "The boot configuration data store could not be opened", so point it at the store explicitly. Give the EFI partition a letter in diskpart, then use /store:
codebcdedit /store S:\EFI\Microsoft\Boot\BCD /enum bcdedit /store S:\EFI\Microsoft\Boot\BCD /deletevalue {default} safeboot
Getting into the recovery console in the first place is covered in our WinRE guide.
BCDEdit edits entries one value at a time. When the store itself is missing, damaged, or pointing at a partition that no longer exists, rebuilding beats editing. Microsoft's BCDBoot reference lists repairing a corrupted system partition among its jobs: it recreates the boot files and a fresh store from the copies in the Windows folder. bcdboot C:\Windows /s S: /f UEFI is the usual line on a UEFI machine, run from WinRE after lettering the EFI partition.
The split is simple. A wrong switch on a working store is a BCDEdit job. A store that cannot be read, or a boot entry pointing at the wrong disk after a clone or disk swap, is a BCDBoot job, which is the fix our winload.efi guide walks through for the 0xc0000225 family of errors.
Across a client's fleet, the useful check is which machines still carry a switch someone forgot. A script that runs bcdedit /enum {current} and flags safeboot, testsigning or hypervisorlaunchtype off finds them in one pass, and on OpenFrame that is a script run across a client's devices with the output collected in one place.
The BCD store decides what Boot Manager starts and how, and BCDEdit is the one tool that reads and edits it. Read with /enum before every change, export a backup first, suspend BitLocker for the restart, and undo every diagnostic switch when the test is done. When the store itself is broken, stop editing and rebuild it with BCDBoot.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.