| Previous | Next |
| VDS_E_PARTITION_LIMIT_REACHED | VDS_E_PARTITION_NOT_EMPTY |
VSS_E_ASRERROR_RDISK0_TOOSMALL
VSS_E_ASRERROR_RDISK0_TOOSMALL is the failure HRESULT 0x80042407 (signed decimal -2147212281, unsigned decimal 2147755015). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and the facility-specific code is 0x2407.
The selected system recovery disk is too small. ASR has selected the firmware-active target for the original system disk, but the target capacity cannot hold the required system-disk layout from the backup.
AllStat records the official condition as: “The disk that is set as active in BIOS is too small to recover the original system disk. Replace the disk with a larger one and retry the restore operation.” This wording should be interpreted at the VSS/ASR stage described below, not as a generic disk or COM failure.
Where VSS_E_ASRERROR_RDISK0_TOOSMALL appears
This is a capacity validation at system-disk mapping time. The disk is visible and has a plausible recovery role, yet its exact usable size is below the source requirement.
Likely causes
- A nominally equal replacement disk exposes fewer addressable bytes than the original.
- The wrong physical or virtual disk is first in firmware order.
- The target was provisioned with a smaller maximum size than intended.
- Storage translation, reserved areas or device geometry reduce usable capacity below the backed-up disk size.
Evidence to capture before changing storage
- Record exact source and target byte sizes, not only labels such as 500 GB or 512 GB.
- Capture the target serial number, bus and firmware position.
- Verify the backup metadata identifies the original system disk and its required extents.
- Document whether a larger candidate exists but was excluded or ordered later.
Diagnostic sequence
- Calculate the size deficit and determine whether it is a small model-to-model difference or a clearly wrong disk.
- Inspect hypervisor or storage provisioning limits for virtual and thin-provisioned targets.
- Check firmware ordering before replacing hardware.
- Do not assume that shrinking restored files changes the ASR disk-layout requirement.
Recovery and retry
Use a target at least as large as the original system disk in exact bytes, or select the correct larger candidate. Retry after the target inventory or ordering changes; repeated attempts against the same undersized disk are deterministic failures.
What this HRESULT does not prove
This HRESULT does not report free space inside existing partitions and does not say that the backup data itself exceeds the target. It compares disk-level recovery requirements.
Difference from nearby VSS results
VSS_E_ASRERROR_CRITICAL_DISKS_TOO_SMALL covers the complete critical-disk set. This value isolates the primary recovery disk chosen for the system disk.
Practical example
A 500 GB source disk has slightly more sectors than a replacement sold under the same capacity label. The restore target looks equivalent in the UI, but exact-byte comparison fails and ASR returns this value.
Guidance for backup software and telemetry
Display both exact capacities and the required minimum. Rounding them to decimal gigabytes can make a correct ASR rejection look inexplicable.
A useful support record includes the operation phase, backup set or restore session identifier, recovery-environment version, firmware mode, exact disk identities, source and target capacities, online/exclusion state, and the first related VSS or storage event. Preserve identifiers needed to distinguish the affected devices while applying the organization’s normal redaction rules to customer-specific labels and paths.
Official Microsoft references
- Microsoft: VSS Automated System Recovery for disaster recovery
- Microsoft: DiskPart list command
- Microsoft: Windows Recovery Environment
- Microsoft: DiskPart command interpreter
Looking for a different code? Search another status or error code.