What causes the UNMOUNTABLE_BOOT_VOLUME (0x000000ED) error in VMware?

This BSOD is most commonly caused by a disk controller mismatch between the source and target VM environment. When a VM is exported from vSphere using OVF format and imported into VMware Player or Workstation, the SCSI controller drivers expected by the guest OS may not match the virtual hardware presented. Corrupted boot configuration (boot.ini or BCD) and file system errors can also trigger it.

How do I fix the 0x000000ED error when importing a VM from vSphere?

Convert the VM from OVF back to VMware Workstation format using OVFTool, boot into Safe Mode and uninstall VMware-specific SCSI controllers and drivers, then reboot to let Windows re-detect hardware. If that fails, use a Windows installation disc to run chkdsk /r from the Recovery Console.

Why does Safe Mode stop at CLASSPNP.sys?

CLASSPNP.sys is the SCSI Class System driver. When Safe Mode hangs at this file, it indicates the storage controller driver cannot communicate with the virtual disk. This typically means the VM's virtual SCSI controller is incompatible with the drivers installed in the guest OS.

VMware Player getting error unmountable boot volume (unmountable_boot_volue 0x000000ED)

Understanding the UNMOUNTABLE_BOOT_VOLUME Error in VMware

The UNMOUNTABLE_BOOT_VOLUME blue screen of death (BSOD) with stop code 0x000000ED is one of the most frustrating errors you can encounter when working with VMware virtual machines. This error occurs when Windows cannot mount the boot partition, preventing the operating system from loading entirely.

This issue is especially common when migrating virtual machines between different VMware products, such as importing a VM from vSphere into VMware Player or Workstation.

What Causes This Error

The 0x000000ED stop error in VMware environments is typically caused by one or more of the following:

1. SCSI vs IDE Controller Mismatch

The most common cause is a disk controller incompatibility. When a VM is created in vSphere, it typically uses a LSI Logic SAS or VMware Paravirtual SCSI controller. When that VM is exported and imported into VMware Player or Workstation, the virtual hardware may change, and the guest operating system does not have the correct drivers to access the boot disk.

2. OVF Format Conversion Issues

The Open Virtualization Format (OVF) is intended to be a universal format for VM portability. However, subtle differences in how VMware products interpret OVF metadata can lead to controller type changes or missing driver mappings during import.

3. Corrupted Boot Configuration

The boot.ini file (Windows XP/Server 2003) or the Boot Configuration Data (BCD) store (Windows Vista and later) may reference a disk partition path that no longer matches the virtual hardware layout.

4. File System Corruption

If the VM was not shut down cleanly before export, the NTFS file system on the boot volume may have corruption that prevents mounting.

Symptoms

When this error occurs, you will see one or more of the following:

A blue screen displaying UNMOUNTABLE_BOOT_VOLUME with stop code 0x000000ED
Safe Mode attempts hanging at CLASSPNP.sys (the SCSI Class System driver)
The VM repeatedly rebooting into the BSOD
Récupération Console or Startup Repair failing to detect the installed OS

Étape-by-Étape Fix: OVF Conversion Method

If your VM was exported from vSphere using OVF, this is the recommended approach.

Étape 1: Convert OVF Back to VMware Workstation Format

Download and install the OVFTool from VMware. Then run the conversion:

ovftool "source-vm.ovf" "destination-vm.vmx"

This converts the OVF package back into a native VMware Workstation .vmx configuration file with proper virtual hardware mappings.

Étape 2: Boot Into Safe Mode

After conversion, start the VM and press F8 repeatedly during boot to access the Advanced Boot Options menu. Select Safe Mode.

If Safe Mode loads successfully and prompts you to select the installed OS, log in and proceed to Étape 3.

Étape 3: Uninstall Incompatible Drivers

Once in Safe Mode:

Open Device Manager (devmgmt.msc)
Expand SCSI and RAID controllers and uninstall any VMware-specific SCSI controllers
Expand IDE ATA/ATAPI controllers and remove any that appear with errors
Expand Storage controllers and remove VMware-specific bus controllers
Uninstall any VMware-specific network adapters
Reboot the VM in Safe Mode again to let Windows re-detect and install generic drivers

Étape 4: Boot With Driver Signature Enforcement Disabled

On the next boot, press F8 and select Disable Driver Signature Enforcement. This allows Windows to load unsigned or mismatched drivers during the initial hardware re-detection phase.

Alternative Fix: Repair Using Windows Installation Media

If Safe Mode hangs at CLASSPNP.sys and you cannot log in, use Windows installation media.

For Windows XP / Server 2003

Boot from the Windows installation CD
Press R to enter the Récupération Console
Select your Windows installation and enter the administrator password
Run the following commands:

chkdsk C: /r
fixboot C:
fixmbr

If boot.ini is corrupted, rebuild it:

bootcfg /rebuild

Type exit and reboot

For Windows 7 / Server 2008 and Later

Boot from the Windows installation ISO attached to the VM
Select Repair your computer
Choose Command Prompt from the System Récupération Options
Run disk repair:

chkdsk C: /r /f

If the BCD store is corrupted, rebuild it:

bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

Close the command prompt and restart

Alternative Fix: Changing the Virtual Disk Controller

If the above methods do not work, you can try modifying the VM configuration file directly.

Edit the .vmx File

Shut down the VM completely
Open the .vmx file in a text editor
Look for lines referencing the SCSI controller:

scsi0.virtualDev = "lsisas1068"

Change it to use the BusLogic or LSI Logic Parallel controller:

scsi0.virtualDev = "buslogic"

Or switch to an IDE controller entirely by changing the disk attachment:

ide0:0.fileName = "disk.vmdk"
ide0:0.present = "TRUE"

Save the file and start the VM

Add the LSI Logic Driver Before Migration

If you are planning a migration, install the correct SCSI driver inside the guest OS before exporting:

In the running VM, open Device Manager
Add a secondary SCSI controller matching the target environment
Let Windows install the driver
Shut down and then perform the export

Running chkdsk When Everything Else Fails

The chkdsk /r command is essential but can be tricky to execute when the OS will not boot. Here are your options:

Method	When to Use
Récupération Console from Windows CD	Safe Mode completely fails
Windows PE boot disc	No original installation media available
Attach VMDK to another VM	Mount the problem disk as a secondary drive in a working VM
VMware Workstation shared folders	Access the disk via another OS on the same host

To attach the disk to another working VM:

In the working VM settings, click Add > Hard Disk > Use an existing virtual disk
Browse to the problem VM’s .vmdk file
Boot the working VM and run:

chkdsk E: /r /f

(Replace E: with the drive letter assigned to the attached disk)

Preventing the Issue

To avoid encountering this error in future VM migrations:

Install VMware Tools in the guest OS before exporting — this ensures the correct paravirtual drivers are present
Use VMware Converter instead of OVF export for cross-product migrations
Shut down the VM cleanly before export to prevent file system corruption
Verify the disk controller type matches between source and target environments
Take a snapshot before making any hardware changes to allow easy rollback

Résumé

The UNMOUNTABLE_BOOT_VOLUME (0x000000ED) error in VMware is almost always caused by a disk controller mismatch when migrating VMs between VMware products. The most reliable fix is to convert the VM back from OVF to native VMware format using OVFTool, boot into Safe Mode, remove incompatible SCSI drivers, and let Windows re-detect the hardware. When Safe Mode is inaccessible, use Windows installation media to run chkdsk /r and repair the boot configuration from the Récupération Console.