VHDX repair: identify the problem and preserve recoverable data

Choose a safe next action for your VHD/VHDX problem

Before attempting to repair or fix a corrupt VHDX, identify what is affected. Host storage, the container file on it, the guest partitions and files inside that container, and the virtual machine are separate objects. Each needs a different response. Failed attachment or startup alone does not tell you which one is damaged.

Choose the result you need

A VHD or VHDX that will not attach or open tells you that an access operation failed. A virtual machine that will not start tells you that startup failed. Neither observation identifies the damaged layer or establishes whether data can be recovered.

Opening a healthy existing disk, assessing a damaged disk, changing its original container, and restoring VM bootability are different tasks. This guide helps you assess recoverable data from a stable, damaged source.

Data recovery, repair of the original in place, and restoration of a bootable virtual machine are separate outcomes. Recovering readable data does not prove either of the other two.

An inspectable virtual result, exported guest files, a recovered host container, and a bootable VM are different outcomes. This guide assesses guest files inside an existing damaged container; recovering a missing host container is a separate ordinary-file task.

Hardware instability overrides every route below. Clicking, repeated disconnects, overheating, inconsistent detection, or severe read instability mean you must stop software scans and seek hardware-safe specialist help. This applies to access checks, backup use, inspection, and export. Do not copy or image a failing drive.

An independently validated, usable backup is an alternative when the source is stable. Check what the backup contains before choosing that route; restoring it is a separate task.

An accessible container can still contain a deleted guest partition or missing files. Attachment does not prove that the guest data is intact, and missing guest files do not mean the host container has disappeared.

A disk that depends on a parent or differencing chain can fail because of that dependency. That requires a different investigation from a standalone damaged container. Chain repair is outside this guide.

Preserve the source and know when to stop software attempts

Complete this preflight checklist before diagnosis or assessment. Keep preservation of the original, installation storage, and export storage separate.

Prepare installation and export storage

• Leave the original unchanged. Do not format, initialize, delete and recreate partitions, repartition, or apply a write-capable repair to the damaged file or its storage. Formatting or initializing does not recover the original data.
• Use a separate working copy only when one is safely available. Do not make one from a drive showing any of the stop cues.
• Keep installations, downloads, and saved output off the affected host storage. New writes can overwrite recoverable data.
• Install the software on healthy storage. A healthy USB installation location can be used when needed. Administrator access is conditional on raw physical-drive access.
• Plan export storage separately. It must be healthy, physically separate from the affected device, and large enough for the selected output. A different folder or partition on that device is insufficient.
• Do not expand or resize a corrupted VHDX. This changes the source and is not a recovery step.

When specialist help is safer

• Watch for changing or inconsistent reads. Host disk, RAID, or cache faults can present inconsistent data that looks like container corruption. If this occurs, stop and seek specialist handling rather than trying to diagnose or rebuild the underlying storage.
• Seek specialist handling for business-critical, encrypted, clustered, or SAN-backed storage. These cases need assessment beyond the stable-source workflow here.

Record the failure before diagnosing VHDX corruption

To check suspected VHDX corruption, first record what happened. You can prepare an incident record without changing the source. Include:

• File name, full path, .vhd or .vhdx extension, and the storage holding it. Establish whether it is the actual container or a separate image of that container. Confirm that a download is a disk file rather than an archive or package with similar error wording.
• The failed operation: attachment, file access, guest-file reading, or VM startup. Keep these distinct because each can fail for different reasons.
• The complete error message and any code, copied exactly as reported.
• Windows version, application or hypervisor, and the permissions of the account involved.
• When the problem first appeared and when the operation last worked. Retain available logs with their timestamps.

Incident history to record

• Incident history: interrupted writes or copies, abrupt shutdown, low host free space, disconnects, storage or software changes, and any earlier partial recovery or truncation. Record these without ranking them as causes.

The container has metadata describing the disk, a payload holding its contents, and a guest file system inside it. These layers help explain why a failure report does not identify the damaged object. A problem at one layer does not establish damage at the others. Editing metadata or payload is outside the recovery assessment described here.

Startup, boot configuration, MBR, boot-sector, and Windows repair-mode problems are boot-side symptoms. They do not independently show that the container is damaged and need a separate boot investigation. Any sign of storage instability returns you to the stop callout.

Common VHDX errors and what they do not prove

Interpret a message together with the operation that produced it. Preserve the wording; it is evidence for investigation, not a diagnosis.

• During attachment or file access, you may see "the file or directory is corrupted and unreadable," "the disk image file is corrupted," "the disc image file is corrupted," or "this structure is corrupted or unreadable." Record whether the file is VHD or VHDX. These reports do not identify the damaged layer or establish whether the cause lies in the file, storage, or access conditions.
• Attachment reports can include "the parameter is incorrect" with 0x80070057 or "access is denied" with 0x80070005. Keep the message and code together. Neither is universal proof of corruption or a diagnosis by itself; rights and file state also matter to access.
• A structural report such as "VHDX region entry corrupt" names an internal structure. Record it verbatim and protect the source before assessment. It does not tell you to edit blocks or metadata.
• If the container attaches but a guest volume is RAW, a partition is missing, or expected files are inaccessible, record that guest-data observation. MBR or GPT partition-table questions concern the disk inside the container. They do not prove container damage or establish a partition-table repair method.
• If the virtual machine will not start, record the failed startup and its message. Startup failure alone does not identify a damaged layer.
• Preserve suffixes naming Windows, a block, VHDTool, VirtualBox, or another application as part of the report. They describe the operation's context, without establishing a utility or block-level remedy.

Short reports such as "VHDX corrupted or unreadable," "VHDX file is corrupted and unreadable," or "VHDX file corrupt" need the same operation and object context. Their wording does not change the preservation-first approach.

Apply the same preservation principles to a damaged VHD

A VHD that no longer opens or reads needs the same first steps as a damaged VHDX: preserve the source, record the failure, and then assess readable data. A request to repair a VHD file, disk, or image does not by itself identify the damaged layer or justify a repair in place.

VHD and VHDX are related virtual-disk container formats with different extensions. A fixed VHD allocates its full size on the host at creation; a dynamically expanding VHD grows as data is written. These terms help describe the source. RAW is a guest-volume observation that Windows does not recognize its file system, not permission to format it.

Record VirtualBox or Virtual PC origin, Windows 7 use, USB storage, and any host crash during a VM session as environment and incident details. Linux or Mac origin belongs in that record too. The application that created the file and the system used for recovery are separate facts. Check the current DiskInternals VHDX Recovery scope before assuming support for a particular recovery environment.

What native Windows diagnostics can and cannot establish

Microsoft documents attachment, usability checks, file-system checks, compaction, and storage-provider repair. These operations target different objects. The referenced documentation does not establish a universal Microsoft VHD or VHDX repair tool that fixes a damaged container from its file path.

The following descriptions explain those limits without providing repair commands.

Attachment, detachment, and read-only access

Disk Management's Action > Attach VHD selects an existing .vhd or .vhdx. Documented prerequisites include Backup Operators or Administrators membership. Detach VHD makes the virtual disk unavailable without deleting its file or data. Ordinary attachment is not inherently read-only: Mount-VHD has an explicit ReadOnly option, and Mount-DiskImage documents access modes with a read/write default for VHD. Successful attachment shows that Windows presented the disk; it does not prove intact guest data. Failed attachment does not identify a damaged layer. Microsoft's documented environments do not establish DiskInternals product support.

Test-VHD

This checks usability of a virtual disk or its chain and returns True or False. Its target is the container and any relevant chain. It does not repair the disk or establish complete guest files, successful export, or VM bootability. Protect the original when considering diagnostics; a usability result alone is not an assurance that access to the source is read-only.

CHKDSK

This examines a volume and its file system rather than the container file. Without repair arguments it reports status. The /f switch performs fixes, and several other switches also include repair behavior. Those uses write to the volume. A clean or fixed guest file system does not prove that its container is sound; applying repair switches to a recovery source changes that source.

Optimize-VHD

This compacts a virtual-disk file by reclaiming unused blocks and rearranging blocks. Compaction changes the container, including when the documented prerequisites call for an unattached or read-only disk. It is not corruption repair. Conversion, resizing, and migration to a new disk are separate tasks and are not recovery steps for the damaged source here.

Repair-VirtualDisk

This targets virtual-disk objects managed through Windows Storage Management, with behavior that depends on the storage provider. It is a repair operation on that object, not a universal .vhdx file-path fix. The command's name does not establish that it applies to an ordinary container file or that its result recovers the guest files you need.

Unverified named recipes

DISM, VHDTool, diskpart, vhd-util, and "Repair-VHD" appear in repair suggestions, including Hyper-V and PowerShell discussions. A repeated name does not establish a valid method or its write behavior. Microsoft's referenced Hyper-V cmdlet inventory lists Repair-VM and does not list Repair-VHD. A "not recognized" message concerns command availability or naming in that environment; it is not evidence of disk corruption. The Disk Management attachment and detachment operations described above provide access, not container repair.

Header or footer repair, hex editing, and log replay concern internal structures and can change the source. Leave them to specialist handling. Scripted, remote, or scheduled repair, PowerShell execution-policy changes, and disabling antivirus are not steps in this recovery assessment.

Assess recoverable data from a stable, damaged VHDX

When the source is stable and none of the five stop cues applies, assess what remains readable. Forcing attachment is a different goal. DiskInternals VHDX Recovery reads the source without changing it and reconstructs an inspectable result virtually. It can recover when recoverable source data remains readable and has not been overwritten.

The screenshots illustrate source selection and folder browsing in an existing mounted disk. They show the application interface, without establishing recovery from corruption or the completeness of exported files.

The pictured disk uses Ubuntu and shows a Linux Ext Recovery label. That is an example, not a support matrix or a damaged-disk success test.

Confirm the source and recovery goal

Confirm the existing source and the guest files you need. Record whether your input is the actual container or a separate image of it. Those are different source objects; do not assume an imaging step. If the host container is missing, use Deleted VHDX recovery options for that separate ordinary-file task.

Prepare healthy installation and export storage

Prepare healthy installation storage and a healthy, physically separate export destination with enough capacity for your selection, as described in the preservation checklist.

Open the existing source

Open the source and use the options the software presents for that source and its available partitions. If the source or an option's purpose is unclear, preserve the incident record and seek help before proceeding.

Example: the Mount Image dialog with an existing VHDX selected.

Inspect the reconstructed result

Inspect the reconstructed result using the inspection checklist. What appears in the software is a virtual view, not saved output.

Example: folders displayed inside an existing mounted VHDX.

Decide whether the selected files are ready for export

Decide whether the relevant files are ready for export. If expected files are absent, mismatched, or unreadable, preserve the source and record for reassessment or specialist help. Repeating the same scan indefinitely does not resolve those gaps.

The free evaluation allows scanning and inspection. Saving or exporting requires a paid license; the product is not freeware. Review DiskInternals VHDX Recovery for current scope, evaluation, and licensing, including whether it addresses your guest file system.

Native Windows operations have the purposes and limits described in the previous section. That documentation does not supply a free universal damaged-container repair. Free product inspection also does not include free export.

When choosing VHD or VHDX repair software, decide whether your goal is to change the original or recover readable data from it. DiskInternals VHDX Recovery provides source-preserving assessment and recovery. Hyper-V or VirtualBox origin and USB storage are source details to record, not reasons to assume a special repair procedure or integration.

Recovery of data from a corrupt VHD follows the same conditional approach. For either format, the result depends on the source remaining stable and recoverable data remaining readable and not overwritten.

Inspect the intended result before exporting

Inspection shows what the reconstructed view contains. Assess relevance, readability, completeness, and exportability separately. Seeing an item in a tree does not prove that its exported copy will be complete or usable.

• Compare names, paths, folder structure, approximate sizes, dates, and content with what you independently know. Known partition or source sizes can help you interpret the result.
• Check file identity. A matching name or an unrelated hit does not prove that an item is the file you need.
• Browse the available tree and files, then select the guest files you intend to keep. Where an item can be viewed, check its readable content. Inspection of selected files does not find every corrupt file in the container.
• Keep missing, mismatched, or unreadable results unresolved. Reassess them against your incident record or seek help; do not assume that another scan option will fix them.

Checks requiring saved copies belong after export, as described below.

Export to separate storage and verify the intended outcome

Before exporting selected guest files:

• Confirm that the destination is healthy and physically separate from the affected device. A different folder or partition on that device is insufficient.
• Check that the destination has enough capacity for your selection.
• Confirm that no clicking, repeated disconnects, overheating, inconsistent detection, or severe read instability has appeared. Any of these means stop software attempts and seek hardware-safe specialist help.
• Check licensing. Saving requires a paid license; current details are on DiskInternals VHDX Recovery.
• Choose Export for the guest files selected during inspection.

After export:

• Open the saved files with the applications that normally use them.
• Compare names, counts, sizes, and content with available expectations. This checks the intended output without establishing universal completeness.
• If the output is incomplete or unusable, preserve the original and incident record and return to assessment.

An inspectable virtual result, exported guest files, a recovered whole container, and a bootable VM are four different outcomes. This assessment concerns guest data in an existing damaged container. It does not establish export of that container as an intact repaired disk.

Recovering a missing host container means recovering the ordinary .vhd or .vhdx file itself, a separate task covered by Deleted VHDX recovery options. Even a recognized, usable container does not prove that the VM will boot.

Reduce future risk

For future protection, keep independent backups that you have validated, shut down virtual machines in a controlled way, and monitor the health of their storage. These practices do not guarantee prevention.