Technical Anshu
Tutorials Blog
💽 Native Boot Guide

Native Boot Windows from a VHDX Dual Boot Without Repartitioning

A second Windows on your PC, living inside one file. No partitions were harmed, no virtual machine is involved - the hardware runs it directly, at near full speed. Native boot is the VHD trick at its most powerful, and it comes with fine print this guide refuses to skip.

✍️ Technical Anshu🪟 Windows 10 / 11⏱️ 8 minute read
🎥 Watch the video to master VHD create and attach first - native boot is built from those same files

Native boot (also called VHD boot) means the Windows Boot Manager starts a Windows installation whose system disk is a VHD or VHDX file sitting on your existing drive. There is no hypervisor: your real CPU, GPU and ports serve that Windows directly. It is the cleanest way to keep a test Windows, an Insider build, or a work Windows beside your main one - and removal is deleting a file and a boot entry. But it is a professional feature with professional conditions: editions, licences and three limitations that marketing summaries love to omit.

What the boot menu sees (example setup)
Windows 11 - your main install, on the physical diskUntouched
Windows 11 Test - lives in D:\VHD\TestWin.vhdxOne file
Partitions created or resized: noneThe point
Remove the test system = remove its boot entry, delete its fileClean exit

👆 Two Windows installations, one disk layout. The second system is a file you can back up, copy or delete like any other.

1

What Native Boot Is and Is Not

  1. It is a full Windows running on bare metal. Games, drivers, USB hardware - everything sees the real machine, because it is the real machine
  2. It is not a virtual machine. No Hyper-V needs to be installed or running; the boot loader itself mounts the VHDX before Windows starts
  3. Performance is near-native. The only cost is disk access passing through a file, which on an SSD most users will never measure, let alone feel
  4. The whole installation - system, apps, files - lives in the one VHDX file, which is why backing up or removing that Windows is a file operation
2

The Requirements Nobody Should Skip

  1. Edition: the Windows inside the VHD must be Pro, Enterprise or Education. Windows Home cannot boot from a VHD - this is a hard product limit, not a setting
  2. Licence: the VHD Windows needs its own valid licence, exactly like a normal installation. A file that copies easily is not a licence that multiplies - one licence does not honestly cover your main Windows and a second booted Windows just because one of them is a file
  3. Host: the PC's existing boot environment must be Windows 7 or later (any modern Windows 10 or 11 host qualifies), and the VHDX must sit on a local, fixed disk - not a USB drive, not a network share, not inside another VHD
  4. Format: use a fixed or dynamically expanding VHDX. Differencing disks are not supported for native boot
3

The Build in Outline

The full procedure is a project of its own; this is the honest shape of it, with the key commands exactly as they are run:

  1. Create and mount a VHDX (60 GB or more for a Windows you will actually use): New-VHD -Path "D:\VHD\TestWin.vhdx" -SizeBytes 80GB -Dynamic then Mount-VHD -Path "D:\VHD\TestWin.vhdx", initialize it as GPT, format NTFS, letter V:
  2. Apply the Windows image from an ISO's install.wim or install.esd: dism /Apply-Image /ImageFile:"E:\sources\install.wim" /Index:1 /ApplyDir:V:\ - check the index first with dism /Get-WimInfo, editions differ per index
  3. Create the boot entry: bcdboot V:\Windows - this adds the VHD Windows to your existing boot menu without touching your main installation
  4. Restart and choose the new entry. First boot runs setup (the out-of-box experience), asks for an account, and needs that licence from the previous section to activate
4

The Caveats, Stated Plainly

  1. No hibernation. A VHD-booted Windows cannot hibernate - sleep works, hibernate is disabled. Laptop users who live on hibernate will feel this
  2. No BitLocker on the booted volume. You cannot encrypt the Windows volume inside the VHD with BitLocker. If drive encryption is a requirement, native boot is the wrong tool
  3. Expansion headroom: with a dynamically expanding VHDX, the host volume must always have room for the file to grow to its full declared size. Let the host fill up and the VHD Windows can fail to start - it checks before it boots
  4. Upgrades deserve care: in the early VHD boot era, in-place version upgrades were blocked outright. Current Windows handles updates far better, but the pragmatic habit stands - treat a native boot system as rebuildable, keep your data synced out of it, and do not plan a five-year upgrade chain on it
  5. The boot files live on the host. The VHDX holds Windows, but the menu entry and boot files sit on your main disk. Delete or rebuild the host carelessly and the VHD Windows has no way to start, even though its file is intact
5

Removing It - The Clean Exit

  1. Boot into your main Windows
  2. Run msconfig → Boot tab, select the VHD Windows entry and delete it - or use bcdedit to list entries and bcdedit /delete {GUID} for the VHD one
  3. Delete the .vhdx file
  4. Done. Your main Windows, its partitions and its boot configuration are exactly as they were before the experiment - this reversibility is the feature's finest quality, and the reason IT professionals use it for testing Insider builds and risky configurations
🔴 Native boot is not a licence loophole and not a backup. The Windows inside the file needs its own licence like any installation, and the file sits on the same physical disk as your main system - if that disk dies, both Windows installations die together. Powerful tool, ordinary physics.

🎥 Watch the Complete Process in the Video

The video builds the VHD foundations step by step - once creating and attaching files feels easy, this native boot outline becomes a weekend project instead of a mystery.

▶️ Watch Full Video
❓ Frequently Asked Questions

Is native boot as fast as a normal Windows installation?

Very close. The CPU, RAM, graphics and devices are the real hardware with nothing in between, so general performance feels identical. Disk operations pass through the VHDX file layer, which costs a small amount - noticeable in benchmarks, rarely in real use on an SSD. It is dramatically faster than the same system inside a virtual machine.

Can I also run the same native boot VHDX inside Hyper-V?

Not by simply attaching it. A native boot VHDX normally has no EFI system partition of its own - it borrows the host's boot files - so a Hyper-V Generation 2 VM finds nothing to boot from. Making one file serve both jobs needs extra partition work. Treat native boot and VM use as two separate disks, even if they start from the same image.

What happens if the host drive runs out of space?

With a dynamically expanding VHDX, trouble: at boot, Windows checks that the host volume can accommodate the VHDX expanding to its full size, and can refuse to start the VHD system if space is short. This is why experienced users either use a fixed VHDX for native boot or keep generous free space on the host - the check is protecting the running system from a disk that vanishes mid-write.

This guide is based on the Technical Anshu Windows VHD video • Stuck on any step? Ask in the video comments — you will get a reply there 🙏