| Previous | Next |
| VDS_E_INVALID_ENUMERATOR | VDS_E_VOLUME_INVALID_NAME |
VDS_E_DRIVER_INTERNAL_ERROR
VDS_E_DRIVER_INTERNAL_ERROR is the failure HRESULT 0x80042505 (signed decimal -2147212027, unsigned decimal 2147755269). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and the facility-specific code field is 0x2505.
The volume-management driver failed internally
This HRESULT places the fault at the volume-management driver boundary. VDS or its software provider reached the kernel-side management layer, and that driver reported an internal error instead of a normal disk, pack, volume, or parameter status.
Where the failure boundary lies
The result is narrower than VDS_E_INTERNAL_ERROR because it identifies the driver layer, and narrower than VDS_E_PROVIDER_INTERNAL_ERROR because a provider can fail before or after calling its driver. It is not the same as VDS_E_IO_ERROR: the public contract does not state that a media read or write failed.
Likely causes to separate
- The driver encountered inconsistent volume, pack, plex, or extent state that it could not represent normally.
- A kernel management operation reached an unexpected code path because cached provider state and driver state diverged.
- A driver defect, incompatible storage-stack component, or corrupted in-memory structure caused an internal failure.
- A preceding device or layout transition left the driver unable to complete the requested management command.
Evidence worth preserving
- Capture System log events from disk, volume manager, Plug and Play, storage controller, and VDS sources at the same timestamp.
- Record the affected disk signatures or GUIDs, volume IDs, pack ID, extent map, and current online or health state.
- Preserve any kernel bugcheck, live dump, WER report, or driver-specific diagnostic event produced near the failure.
- Note recent storage-driver, multipath, filter-driver, firmware, or operating-system updates.
Diagnostic sequence
- Confirm whether the failure follows one physical device, one dynamic-disk pack, or every management request on the host.
- Compare VDS properties with independent read-only tools before issuing repair or conversion operations.
- Re-enumerate only after device topology changes; use refresh for property synchronization, understanding that refresh does not force the driver to reread media.
- If the driver error is reproducible, reduce the operation to the smallest safe query or non-destructive management call before escalating with traces.
Retry and recovery
A service restart alone may not reset kernel driver state. Recovery can require the underlying device transition to finish, a driver or system restart, or correction of incompatible storage software. Before replaying the operation, verify that the target object remains the same and that no partial layout change occurred.
What this HRESULT does not establish
The HRESULT does not identify the exact driver routine, prove hardware failure, or imply filesystem corruption. It also does not mean the caller’s original API arguments were invalid; that separate contract is represented by VDS_E_DRIVER_INVALID_PARAM.
Practical example
A dynamic-volume operation reaches the volume manager after a recent disk-path change. The provider can still enumerate objects, but the kernel management driver detects inconsistent internal pack state and returns VDS_E_DRIVER_INTERNAL_ERROR. Service-level retries continue to fail until the driver state is reconstructed.
Guidance for software and telemetry
Separate driver-layer failures from provider and service failures in telemetry. Include storage stack versions and persistent disk identifiers so support engineers can recognize a host-wide driver defect versus one damaged object.
Official Microsoft references
- Microsoft: Virtual Disk Service common return codes
- Microsoft: MS-VDS protocol error codes
- Microsoft: Virtual Disk Service architecture and provider roles
- Microsoft: IVdsService::Refresh
- Microsoft: IVdsService::Reenumerate
Looking for a different code? Search another status or error code.