| Previous | Next |
| VDS_E_DISK_DYNAMIC | VDS_E_PARTITION_NOT_CYLINDER_ALIGNED |
VDS_E_DRIVER_OBJECT_NOT_FOUND
VDS_E_DRIVER_OBJECT_NOT_FOUND is the failure HRESULT 0x8004253D (signed decimal -2147211971, unsigned decimal 2147755325). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and the facility-specific code field is 0x253D.
The target object no longer exists in the driver cache
The volume-management driver could not find the object referenced by the operation in its cache. This is a cache-identity and lifetime result: VDS or a provider referred to a disk, pack, volume, plex, or related object that the driver no longer recognizes.
Where the failure boundary lies
This code differs from the general VDS_E_OBJECT_NOT_FOUND, which does not identify the driver cache, and from VDS_E_OBJECT_DELETED, which states that the public object no longer exists. Here the mismatch is explicitly between the operation and the driver’s cached object set.
Likely causes to separate
- The device or volume was removed, deleted, re-created, imported, or otherwise assigned a new internal identity.
- VDS/provider caches have not yet processed a driver-side topology change.
- A long-lived COM object or application cache refers to an object from an earlier enumeration generation.
- Competing management software changed the storage layout between object discovery and command execution.
Evidence worth preserving
- Record the persistent VDS object ID, device path, disk signature or GPT GUID, pack ID, and provider identity used by the failed call.
- Capture arrival, removal, modification, and provider notifications around the object’s last successful use.
- Compare the current object inventory before and after
IVdsService::ReenumerateandIVdsService::Refresh; the two operations answer different questions. - Log the age of the cached interface pointer and any application-side mapping from list index to object ID.
Diagnostic sequence
- Stop using the failed object reference and enumerate the relevant provider, pack, or subsystem again.
- Resolve the target by stable identity rather than display name, drive letter, or enumeration position.
- Use reenumeration when disks arrived or disappeared; use refresh when an existing object’s properties or ownership appear stale.
- If the object repeatedly vanishes from the driver cache, investigate unstable paths, controller resets, provider cache errors, and device-removal events.
Retry and recovery
Retry only after the caller proves that the intended object still exists and reacquires a current interface to it. If a replacement object has a different identity, treat it as a new target and re-run all safety checks. A refresh that merely changes the visible list is not authorization to apply the old operation to the item now occupying the same ordinal.
What this HRESULT does not establish
The result does not necessarily mean the physical disk is absent. The object can be present in hardware yet missing from one management cache. It also does not prove cache corruption; normal deletion or topology change can produce the same lookup failure.
Practical example
A tool stores a volume interface, then another administrator deletes and recreates the volume. The display name and drive letter are reused, but the driver cache contains a new object identity. The old call fails with VDS_E_DRIVER_OBJECT_NOT_FOUND; the correct recovery is to rediscover and revalidate the new volume.
Guidance for software and telemetry
Attach an enumeration generation to cached objects and invalidate them on relevant VDS notifications. Logging only the friendly name makes this error nearly impossible to distinguish from a transient drive-letter change.
Official Microsoft references
- Microsoft: Virtual Disk Service common return codes
- Microsoft: MS-VDS protocol error codes
- Microsoft: reenumerating and refreshing VDS objects
- Microsoft: IVdsService::Reenumerate
- Microsoft: IVdsService::GetObject
Looking for a different code? Search another status or error code.