What does HRESULT 0x8004006A (DV_E_CLIPFORMAT) mean?

 
Previous Next
DV_E_TYMED DV_E_DVASPECT

DV_E_CLIPFORMAT

Invalid clipboard format

DV_E_CLIPFORMAT has hexadecimal value 0x8004006A (unsigned 2147745898, signed -2147221398). AllStat records “Invalid clipboard format”. The narrow interpretation is that the clipboard format identifier is invalid or unsupported in the current transfer contract. The failing stage is checking FORMATETC::cfFormat for clipboard, drag-and-drop, embedding, or rendering.

The high bit in 0x8004006A is set, so this is a failure rather than a success or informational result. Its facility field is 4 (FACILITY_ITF) and its low 16-bit code is 106 (0x006A). Those bit fields classify the value, but they do not identify the failing object by themselves; the native method, object identity, and first producer of DV_E_CLIPFORMAT remain essential.

API stage

Understanding DV_E_CLIPFORMAT requires this subsystem context: COM data-transfer structures are compound contracts: a field can be numerically well formed yet invalid for the provider, object generation, requested aspect, or ownership rules. For DV_E_CLIPFORMAT, diagnosis therefore has to preserve the complete descriptor and the exact method that consumed it.

  • Associate DV_E_CLIPFORMAT with one exact operation in IDataObject, FORMATETC/STGMEDIUM negotiation, data advisory enumeration, or OLE rendering.
  • Confirm that DV_E_CLIPFORMAT came from checking FORMATETC::cfFormat for clipboard, drag-and-drop, embedding, or rendering, rather than from cleanup or a wrapper that ran afterward.
  • Preserve any IErrorInfo, underlying Win32 result, provider message, or callback failure that preceded DV_E_CLIPFORMAT; the HRESULT alone should not erase a more specific cause.

Verification steps

  1. Capture DV_E_CLIPFORMAT at the first native return before a wrapper maps it to a generic exception.
  2. Identify the exact object, method, and lifecycle phase involved in checking FORMATETC::cfFormat for clipboard, drag-and-drop, embedding, or rendering.
  3. Translate registered IDs back to names with GetClipboardFormatName where possible.
  4. Compare the format with EnumFormatEtc output from the same IDataObject.
  5. Capture whether the ID came from RegisterClipboardFormat, a constant, persistence, or IPC.
  6. Reproduce DV_E_CLIPFORMAT with one controlled input or state change, and verify that the correction changes the decisive evidence rather than merely hiding the result.

Interpretation limits

  • DV_E_CLIPFORMAT can result when cfFormat is zero where a real format is required.
  • DV_E_CLIPFORMAT can result when a private registered format was not registered in this session or its numeric ID was persisted across boots.
  • DV_E_CLIPFORMAT can result when the caller requests text, bitmap, or object data under a format the source does not advertise.

Incident record

A useful DV_E_CLIPFORMAT incident records the IDataObject identity, method, clipboard format, aspect, lindex, tymed mask, target-device size, advisory cookie, and ownership of every returned interface or medium. For DV_E_CLIPFORMAT, also retain the application and component build, architecture, process and thread IDs, COM apartment, operation correlation ID, elapsed time, and the first state-changing event before the failure. When logging DV_E_CLIPFORMAT, redact content and credentials while preserving types, lengths, hashes, opaque identities, and lifecycle generations needed to reproduce its contract.

  • For DV_E_CLIPFORMAT, translate registered IDs back to names with GetClipboardFormatName where possible.
  • For DV_E_CLIPFORMAT, compare the format with EnumFormatEtc output from the same IDataObject.
  • For DV_E_CLIPFORMAT, capture whether the ID came from RegisterClipboardFormat, a constant, persistence, or IPC.

Recovery conditions

Correction. For DV_E_CLIPFORMAT, register or select the intended format at runtime and request it together with a compatible aspect and tymed. Retry boundary. Retry only after resolving the format identity; numeric reuse without the registered name is not evidence of equivalence. Before repeating the DV_E_CLIPFORMAT operation, release every returned STGMEDIUM according to pUnkForRelease, retain advisory cookies only after successful DAdvise, and discard enumerated formats after the data object is replaced.

Practical scenario

An application stores the numeric value of a custom clipboard format in a settings file; after reboot the value refers to a different registration, so using the format name at startup fixes the request. This isolates DV_E_CLIPFORMAT within COM data transfer and advisory connections and provides a regression test for the stated correction.

Difference from related HRESULTs

DV_E_FORMATETC rejects the descriptor as a whole, whereas DV_E_CLIPFORMAT isolates cfFormat as the decisive field. For DV_E_CLIPFORMAT, keep those outcomes separate in exception mappings, telemetry dimensions, user messages, and automated retry policy.

Developer and administrator guidance

For DV_E_CLIPFORMAT, copy complete FORMATETC and DVTARGETDEVICE structures, preserve signed lindex values, intersect tymed masks before requesting data, and encode STGMEDIUM ownership explicitly. Regression coverage for DV_E_CLIPFORMAT should include provider-advertised versus caller-invented formats, supported and unsupported DVASPECT/tymed combinations, sentinel lindex values, malformed target-device sizes, and replacement during advisory callbacks.

Operational repair for DV_E_CLIPFORMAT must target the evidence-backed owner: compare the data provider, consumer, and registered handler versions; repair a handler only when traces identify that provider as missing or incompatible. Retain before-and-after traces for DV_E_CLIPFORMAT so the change can be attributed and reversed.

References

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