VHDX File Documentation

Summary

A VHDX (Virtual Hard Disk v2) file stores an entire hard disk — partition table, filesystem, an installed operating system and every file — in one host file. It is Microsoft’s second-generation virtual-disk format, introduced with Windows 8 and Server 2012 as the successor to .vhd, supporting disks up to 64 TB and resisting corruption on power loss. Its MIME type is application/x-vhd. Attach a .vhdx in Disk Management to read it as a drive letter, or run it in Hyper-V; convert to .vhd with PowerShell’s Convert-VHD.

Technical details

FeatureValue
Full nameVirtual Hard Disk v2 (VHDX)
File extension.vhdx
MIME typeapplication/x-vhd
Format typeVirtual disk-image container (binary)
DeveloperMicrosoft
IntroducedWindows 8 / Windows Server 2012 (2012)
Specification[MS-VHDX], Microsoft Open Specification Promise
Open standardYes — published under the Open Specification Promise
Disk typesFixed, dynamically expanding, differencing (.avhdx)
Maximum size64 TB
Byte orderLittle-endian
Magic number (hex)76 68 64 78 66 69 6C 65 (vhdxfile)
Alignment1 MB structure alignment
Crash protectionMetadata log (journal) survives power loss
Logical sector size512 bytes or 4096 bytes (4K-native)
Block sizeConfigurable (1 MB–256 MB; 32 MB default)
Header copiesTwo, for resilience
Modern Windows useHyper-V, Disk Management attach, WSL2 ext4.vhdx, Dev Drive
PredecessorVHD (max 2 TB, conectix footer)
Related extensions.vhd, .avhdx, .vmdk, .vdi, .iso
Specification URLlearn.microsoft.com/openspecs/windows_protocols/ms-vhdx/
File signature (magic bytes)
76 68 64 78 66 69 6C 65

Offset 0, 8 bytes. In ASCII this reads vhdxfile and is followed by a UTF-16LE creator string. Unlike its predecessor VHD, whose conectix cookie lives in a footer at the end of the file, VHDX puts a clear identifier at byte 0. That 64 KB file-identifier region is followed by two independent header regions (head signatures) kept as redundant copies, so a torn write to one still leaves a valid header. All VHDX multi-byte integers are little-endian, the opposite of VHD’s big-endian footer.

What is a VHDX file?

VHDX stands for Virtual Hard Disk v2. Like its predecessor VHD, a .vhdx file stores a complete guest hard disk — its partition table, filesystem, installed operating system and files — inside a single host file. Microsoft introduced it with Windows 8 and Windows Server 2012 to fix the two limits that VHD could not shed: a 2 TB ceiling and a tendency to corrupt if power was lost mid-write. VHDX raises the maximum virtual disk to 64 TB and adds an internal log that journals metadata, so an image survives a crash. It is the native disk format of Hyper-V on modern Windows, and the format under WSL2’s ext4.vhdx and Windows Dev Drive.

The format is documented as [MS-VHDX] under Microsoft’s Open Specification Promise, which is why qemu-img and recent VirtualBox can also read and write it. Structurally, VHDX is a clean redesign rather than a patched VHD: everything is little-endian, aligned to 1 MB boundaries, and organised into a file-identifier region, two redundant headers, a region table, a log, a metadata region and a block allocation table. The sections below walk that layout field by field.

The header section: file identifier, two headers and the region table

The first 1 MB of a VHDX is the header section, a fixed set of aligned structures that let a parser find everything else and recover from a torn write.

VHDX header section (first 1 MB, little-endian)
offset        structure
0x00000       File Type Identifier   "vhdxfile" + UTF-16LE creator string
0x10000 (64K) Header 1               "head" signature, SequenceNumber, GUIDs
0x20000 (128K)Header 2               "head" signature (redundant copy)
0x30000 (192K)Region Table 1         "regi" signature, list of region entries
0x40000 (256K)Region Table 2         "regi" signature (redundant copy)
0x100000(1M)  start of regions (BAT, metadata, log ...)

The file type identifier at offset 0 carries the vhdxfile signature. The two headers at 64 KB and 128 KB are identical in purpose: each holds a SequenceNumber, a checksum, and GUIDs identifying the file and its current write state. A writer updates them alternately and bumps the sequence number, so if a crash corrupts the header being written, the other still holds the last consistent state and wins by having the highest valid sequence number. The two region tables (regi) are likewise redundant; each lists the regions that make up the rest of the file — principally the block allocation table (BAT), the metadata region, and the log — giving each region’s file offset, length and a GUID that names its type.

The block allocation table and payload/sector-bitmap blocks

The guest disk is divided into fixed-size blocks; the block size is configurable (commonly 32 MB, and it is recorded in the metadata). The block allocation table (BAT) is a flat array of 64-bit entries that maps each block to its location in the file. Each BAT entry packs a 3-bit state and a 44-bit file offset in MB.

VHDX BAT entry (64 bits)
bits  0..2    State  (PAYLOAD_BLOCK_NOT_PRESENT, ..._UNDEFINED,
                      ..._ZERO, ..._UNMAPPED, ..._FULLY_PRESENT,
                      ..._PARTIALLY_PRESENT)
bits  3..19   Reserved
bits 20..63   FileOffsetMB  (block location, in 1 MB units)

For dynamic and differencing disks the BAT interleaves two kinds of entry: payload block entries that point at the actual data blocks, and sector bitmap entries that point at the bitmap describing which sectors of nearby payload blocks are present. The state field is what makes VHDX space-efficient and TRIM-aware: a block marked ZERO reads as zeros without occupying any file space, and UNMAPPED lets the disk report unallocated regions back to the host so tools can reclaim them. Because offsets are stored in 1 MB units across 44 bits, the BAT can address the full 64 TB range while staying compact.

The metadata region: disk size, sector size and 4K-native support

A VHDX does not scatter disk parameters through the headers the way VHD packed geometry into its footer. Instead it collects them in a dedicated metadata region, a small table of GUID-keyed items split into file metadata (fixed by the format) and user metadata (custom, application-defined). The standard file-metadata items include:

ItemMeaning
Virtual Disk SizeTotal size of the guest disk in bytes (up to 64 TB)
Logical Sector Size512 or 4096 bytes — enables 4K-native disks
Physical Sector Size512 or 4096 bytes
Block SizePayload block size (1 MB–256 MB)
Virtual Disk IDGUID identifying this disk
Parent LocatorFor differencing disks: how to find the parent VHDX

The explicit logical sector size is a real functional gain over VHD: a VHDX can present a 4K-native disk (4096-byte sectors) to the guest, matching modern physical drives and avoiding the read-modify-write penalty of emulating 512-byte sectors on 4K hardware. The parent-locator item plays the same role VHD’s parent fields did, letting a differencing .avhdx child find the parent it stores changes against.

The log: how VHDX survives power loss

The feature that most distinguishes VHDX from VHD is the log. Before VHDX changes any of its own metadata — growing the file, updating the BAT, allocating a block — it writes a description of that change to a circular log region as a chain of log entries, each protected by a checksum and tagged with a sequence number. Only after the log entry is durably on disk does the actual metadata update proceed. If power is lost between the two, the next time the file is opened the parser replays the log: any change that was fully logged but not fully applied is completed, and any half-written metadata is corrected from the log record.

Crucially, the log covers the disk’s structural metadata, not the guest’s file data. It guarantees that the VHDX container itself stays internally consistent after a crash — the BAT still resolves, the headers still parse, the region table still points to valid regions — which is exactly the class of corruption that could render a VHD unopenable. The guest filesystem inside still relies on its own journaling (NTFS, ext4) for its data.

Attaching, mounting and converting a VHDX

On any modern Windows, Disk Management’s Action › Attach VHD mounts a .vhdx as a drive letter without Hyper-V (double-clicking in Explorer does the same), and PowerShell’s Mount-VHD, Get-VHD and Resize-VHD inspect and resize it. To run the disk as a machine you attach it to a VM in Hyper-V. On Linux, qemu-img reads VHDX directly and guestmount can mount the guest filesystem read-only.

Conversions stay within the family of hard-disk images. Convert-VHD -Path in.vhdx -DestinationPath out.vhd downgrades to the older VHD when a tool or an Azure scenario needs it; qemu-img convert targets VMDK (VMware) or VDI (VirtualBox). What is not possible is “VHDX to ISO”: an ISO is an optical-disc image built on ISO 9660/UDF, while a VHDX is a whole hard disk with its own partition table, so there is no sector-level equivalence. To get files out, attach the disk and copy them; to make a bootable ISO, author it from the operating system separately.

Frequently asked questions

How does VHDX identify itself compared with VHD?

VHDX writes the ASCII signature vhdxfile at offset 0, so it is recognisable from the first byte. VHD instead keeps its conectix cookie in a 512-byte footer at the end of the file (a fixed VHD has no signature at byte 0 at all). VHDX is also little-endian, whereas the VHD footer is big-endian.

Why does a dynamic VHDX grow over time, and how do I shrink it?

A dynamic VHDX allocates blocks as the guest writes and does not automatically return space when the guest deletes files, so the file grows toward its high-water mark. This is common with WSL2’s ext4.vhdx. Free space inside the guest first, then compact the file with PowerShell’s Optimize-VHD or diskpart’s compact vdisk, which rewrites the BAT and drops blocks now marked zero or unmapped.

Can I open a VHDX without Hyper-V?

Yes. Disk Management attaches VHDX on any modern Windows edition with no Hyper-V role installed, 7-Zip can extract files from it read-only, and qemu-img or guestmount read it on Linux. Hyper-V is only required to boot the disk as a running virtual machine.

References