What does HRESULT 0x80042701 (VDS_E_NAME_NOT_UNIQUE) mean?

 
Previous Next
VDS_E_SHRINK_DIRTY_VOLUME VDS_E_ADDRESSES_INCOMPLETELY_SET

VDS_E_NAME_NOT_UNIQUE

VDS_E_NAME_NOT_UNIQUE is the failure HRESULT 0x80042701 (signed decimal -2147211519, unsigned decimal 2147755777). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and the facility-specific code field is 0x2701.

The requested VDS name collides with an existing object

This HRESULT states that the specified name is not unique. A documented concrete example is IVdsSubSystemIscsi::CreateTarget, which returns the code when the pwszIscsiName argument duplicates a name already used in the subsystem’s required namespace.

Where the failure boundary lies

The failure is about uniqueness, not syntax or length. It differs from an invalid-name HRESULT and from VDS_S_NAME_TRUNCATED, where a name is accepted but shortened. It also differs from VDS_S_ALREADY_EXISTS, which can report an already-existing object rather than rejection of a conflicting requested name.

Likely causes to separate

  • The caller submits an iSCSI target or other provider-managed name that already exists in the relevant subsystem scope.
  • Case normalization, whitespace rules, Unicode normalization, or provider-specific canonicalization makes two visually different strings equivalent.
  • A previous asynchronous create operation succeeded or partially completed, but the client did not refresh its object list.
  • Another administrator or management application created the same name between the caller’s uniqueness check and create request.

Evidence worth preserving

  • Log the exact Unicode input, its length, the owning subsystem or provider ID, and the API method that received it.
  • Enumerate existing targets or objects from the same provider and preserve both display names and persistent IDs.
  • Capture asynchronous completion status from the preceding create attempt to determine whether the apparent collision is the caller’s own object.
  • Record normalization performed by the application before submission and avoid logging secrets that may be embedded in unrelated iSCSI security settings.

Diagnostic sequence

  • Compare names using the provider’s documented semantics rather than only a case-sensitive application comparison.
  • Reenumerate the subsystem if another tool or failed create may have changed the object set.
  • Resolve whether the existing object should be reused, updated, renamed, or deleted; do not automatically delete it based only on a matching label.
  • When generating names, include a stable business identifier or verified suffix and re-check after a collision because uniqueness tests are inherently racy.

Retry and recovery

Choose a genuinely unique name or intentionally bind to the existing object after verifying its identity and configuration. Retry with a different generated name is safe only when creating an additional object is the intended outcome. If the existing object came from a timed-out request, reconcile it before creating duplicates.

What this HRESULT does not establish

This HRESULT does not prove that the existing object is equivalent to the requested one, and it does not reveal the collision scope by itself. The invoked interface and provider determine whether uniqueness is host-wide, subsystem-wide, or specific to an object class.

Practical example

Two management nodes concurrently create an iSCSI target using the same policy-derived name. One succeeds; the other receives VDS_E_NAME_NOT_UNIQUE. The losing node must enumerate the target, compare persistent identity and settings, and then decide whether to reuse it or generate a different name.

Guidance for software and telemetry

Do not implement uniqueness as “check, then create” without handling the create-time collision. Return the conflicting scope and proposed alternatives to the user, while keeping persistent IDs separate from mutable display names.

Official Microsoft references

Looking for a different code? Search another status or error code.