| Previous | Next |
| VDS_E_FAILED_TO_OFFLINE_DISK | VDS_E_SHRINK_USER_CANCELLED |
VDS_E_BAD_REVISION_NUMBER
VDS_E_BAD_REVISION_NUMBER is the failure HRESULT 0x80042598 (signed decimal -2147211880, unsigned decimal 2147755416). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and the facility-specific code field is 0x2598.
The requested VDS revision is unsupported
This HRESULT means that a revision number supplied for the operation is not supported. It is a compatibility or capability mismatch, not a generic parsing failure and not evidence that the target volume is corrupt.
Where the failure boundary lies
The public common-code list does not assign the value to only one method, so diagnosis must begin with the actual call site and the revision-bearing parameter. One concrete VDS contract is IVdsVolumeMF2::FormatEx and its newer FormatEx2 form, which accept usFileSystemRevision. The caller should not assume every occurrence refers to formatting, but these methods illustrate why the exact requested revision must be logged.
Likely causes to separate
- The caller requests a filesystem or operation revision newer than the installed VDS, filesystem, or provider implementation supports.
- A hard-coded revision is valid on one Windows release or provider but not on the current target.
- The filesystem name and revision number are individually valid but not supported as a pair.
- A provider interprets a revision field differently because client and provider components are from incompatible versions.
Evidence worth preserving
- Log the exact API method, revision value in decimal and hexadecimal, related filesystem or object type, flags, and provider identity.
- Capture operating-system build, VDS/provider version, and whether the same request succeeds with the implementation’s default revision.
- Record capability-query results or documented supported revisions instead of inferring support from another machine.
- Preserve the full argument set because a revision may be rejected only in combination with particular options.
Diagnostic sequence
- Locate the revision-bearing field in the invoked API; do not search only by the symbolic HRESULT.
- Compare the requested value with the exact documentation for the installed target platform and provider.
- Test omission or documented default selection only when the API permits it and the resulting format or behavior is acceptable.
- Check for mixed-version binaries when a revision that previously worked becomes unsupported after servicing or deployment.
Retry and recovery
Select a revision explicitly supported by the target implementation, or update the component that lacks support. A retry with the identical revision is not useful. When formatting is involved, changing the revision can alter on-disk behavior, so the application should expose the negotiated choice and revalidate all requested filesystem options before proceeding.
What this HRESULT does not establish
The code does not identify which revision field was rejected and does not by itself mean that the API version, COM interface version, or disk partition-table revision is wrong. The call context decides that meaning.
Practical example
A provisioning tool always requests a filesystem revision observed on a newer system. On an older VDS/provider stack, FormatEx rejects that value with VDS_E_BAD_REVISION_NUMBER. The fix is capability-aware selection, not repeated formatting attempts or disk repair.
Guidance for software and telemetry
Avoid embedding unexplained numeric revisions in policy. Log and display both the requested and supported or selected revision, and keep fallback behavior explicit so deployment differences do not silently change the resulting filesystem.
Official Microsoft references
- Microsoft: Virtual Disk Service common return codes
- Microsoft: MS-VDS protocol error codes
- Microsoft: IVdsVolumeMF2::FormatEx
- Microsoft: IVdsVolumeMF3::FormatEx2
- Microsoft: using Virtual Disk Service
Looking for a different code? Search another status or error code.