| Previous | Next |
| VDS_E_PARTITION_STYLE_MISMATCH | VDS_E_SHRINK_SIZE_LESS_THAN_MIN |
VDS_E_PROVIDER_INTERNAL_ERROR
VDS_E_PROVIDER_INTERNAL_ERROR is the failure HRESULT 0x80042572 (signed decimal -2147211918, unsigned decimal 2147755378). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and the facility-specific code field is 0x2572.
The selected VDS provider failed inside its own implementation
This HRESULT identifies an internal error in the provider that owns or manages the target storage object. VDS coordinates software and hardware providers, so the relevant implementation can be a Microsoft software provider or a vendor component for an external subsystem.
Where the failure boundary lies
The code is provider-scoped but not necessarily service-fatal. It differs from VDS_E_PROVIDER_FAILURE, which broadly says the provider failed to complete an operation, and from VDS_E_UNRECOVERABLE_PROVIDER_ERROR, which requires service shutdown to regain full functionality. It also does not place the fault specifically in the kernel driver.
Likely causes to separate
- The provider encountered an unexpected internal state while translating, validating, or completing a request.
- Provider cache contents conflict with the subsystem or driver view.
- A vendor provider defect, firmware incompatibility, or communication failure is mapped to the provider’s generic internal result.
- An object changed or disappeared during a multi-stage provider operation and the provider lacked a more specific public code.
Evidence worth preserving
- Identify the provider through the owning VDS object and record its GUID, name, type, version, and vendor.
- Collect provider-specific logs, array or subsystem events, firmware details, and VDS event-log entries.
- For asynchronous work, capture the final HRESULT and operation-specific output returned by
IVdsAsync::Wait. - Query the target after failure to determine whether the provider applied a partial change before returning the error.
Diagnostic sequence
- Determine whether operations through other providers succeed; that separates a provider-local defect from a service-wide problem.
- Check provider cache synchronization and use vendor-supported reenumeration or refresh only when the object view is stale.
- Reproduce with a read-only query when possible before repeating a configuration change.
- Correlate the first provider error with subsystem controller, path, LUN, and firmware events rather than focusing on later cascading failures.
Retry and recovery
A provider restart, service restart, cache rebuild, or firmware/provider update may be required, depending on the evidence. Repeating the original operation is safe only after current object state is verified and any partial result is understood. On shared storage, coordinate with the subsystem owner before resetting provider or controller state.
What this HRESULT does not establish
This value does not name the provider automatically, prove a hardware defect, or guarantee that VDS itself remains unaffected. It also does not mean every provider on the host is unusable.
Practical example
A hardware provider accepts a LUN configuration request but encounters an unexpected firmware response while updating its internal model. It returns VDS_E_PROVIDER_INTERNAL_ERROR. Other software-provider disk operations continue to work, indicating a provider-local investigation rather than a global VDS shutdown.
Guidance for software and telemetry
Always log provider identity before releasing the target object. A generic support message that omits the provider turns a useful layer-specific HRESULT into an untraceable “storage failed” report.
Official Microsoft references
- Microsoft: Virtual Disk Service common return codes
- Microsoft: MS-VDS protocol error codes
- Microsoft: VDS provider object
- Microsoft: Virtual Disk Service architecture and provider roles
- Microsoft: IVdsHwProvider::Refresh
Looking for a different code? Search another status or error code.