What does HRESULT 0x80040100 (DRAGDROP_E_NOTREGISTERED) mean?

 
Previous Next
DV_E_NOIVIEWOBJECT DRAGDROP_E_ALREADYREGISTERED

DRAGDROP_E_NOTREGISTERED

Trying to revoke a drop target that has not been registered

The native value 0x80040100 is DRAGDROP_E_NOTREGISTERED, unsigned 2147746048 and signed -2147221248. According to AllStat, it means “Trying to revoke a drop target that has not been registered”. Treat it as evidence that RevokeDragDrop was called for a window that is not currently registered as an OLE drop target; the operation in progress is unregistering a window during destruction, feature disablement, or target replacement.

The high bit in 0x80040100 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 256 (0x0100). 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 DRAGDROP_E_NOTREGISTERED remain essential.

Operational meaning

Understanding DRAGDROP_E_NOTREGISTERED requires this subsystem context: OLE drag-and-drop registration is tied to an HWND, its UI thread, and a COM apartment. For DRAGDROP_E_NOTREGISTERED, isWindow checks can describe a moment in time, but lifecycle serialization is what prevents stale handles, duplicate registration, and reentrant drag sessions.

  • Associate DRAGDROP_E_NOTREGISTERED with one exact operation in RegisterDragDrop, RevokeDragDrop, DoDragDrop, window lifetime, and IDropTarget ownership.
  • Confirm that DRAGDROP_E_NOTREGISTERED came from unregistering a window during destruction, feature disablement, or target replacement, rather than from cleanup or a wrapper that ran afterward.
  • Preserve any IErrorInfo, underlying Win32 result, provider message, or callback failure that preceded DRAGDROP_E_NOTREGISTERED; the HRESULT alone should not erase a more specific cause.

Cause model

  • DRAGDROP_E_NOTREGISTERED can result when cleanup runs twice for the same HWND.
  • DRAGDROP_E_NOTREGISTERED can result when registration failed earlier but teardown still assumes success.
  • DRAGDROP_E_NOTREGISTERED can result when the HWND was destroyed and recreated, so the new handle generation was never registered.

Troubleshooting workflow

  1. Capture DRAGDROP_E_NOTREGISTERED 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 unregistering a window during destruction, feature disablement, or target replacement.
  3. Track a successful RegisterDragDrop result as state owned by the window instance.
  4. Log WM_NCDESTROY and feature-toggle order around RevokeDragDrop.
  5. Confirm that the call runs on the thread and apartment that owns the window.
  6. Reproduce DRAGDROP_E_NOTREGISTERED with one controlled input or state change, and verify that the correction changes the decisive evidence rather than merely hiding the result.

What to log

A useful DRAGDROP_E_NOTREGISTERED incident records the HWND value, creating thread, apartment type, registration state, IDropTarget identity, active drag sequence, mouse capture, and destruction or recreation events. For DRAGDROP_E_NOTREGISTERED, 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 DRAGDROP_E_NOTREGISTERED, redact content and credentials while preserving types, lengths, hashes, opaque identities, and lifecycle generations needed to reproduce its contract.

  • For DRAGDROP_E_NOTREGISTERED, track a successful RegisterDragDrop result as state owned by the window instance.
  • For DRAGDROP_E_NOTREGISTERED, log WM_NCDESTROY and feature-toggle order around RevokeDragDrop.
  • For DRAGDROP_E_NOTREGISTERED, confirm that the call runs on the thread and apartment that owns the window.

Correction strategy

Correction. For DRAGDROP_E_NOTREGISTERED, make revocation conditional on recorded successful registration and clear that state exactly once. Retry boundary. Do not retry blindly; either register the live window first or treat the duplicate teardown as an application-state defect. Before repeating the DRAGDROP_E_NOTREGISTERED operation, finish or cancel any active drag, pair each successful registration with one revocation, and verify that the HWND still belongs to the same window generation.

Practical scenario

A view calls RevokeDragDrop from both its disable command and destructor; an atomic or UI-thread-owned registration flag prevents the second call. This isolates DRAGDROP_E_NOTREGISTERED within OLE drag-and-drop registration and modal tracking and provides a regression test for the stated correction.

Difference from related HRESULTs

DRAGDROP_E_ALREADYREGISTERED is the opposite lifecycle mismatch: registration is attempted while an active target already exists. For DRAGDROP_E_NOTREGISTERED, keep those outcomes separate in exception mappings, telemetry dimensions, user messages, and automated retry policy.

Developer and administrator guidance

For DRAGDROP_E_NOTREGISTERED, own registration state on the HWND’s UI thread, tie it to the window generation, and guard DoDragDrop against reentrant starts. Regression coverage for DRAGDROP_E_NOTREGISTERED should include duplicate enable and disable paths, HWND recreation, framework-owned drop targets, destruction during registration, and nested input dispatch while a drag is active.

Operational repair for DRAGDROP_E_NOTREGISTERED must target the evidence-backed owner: identify whether the application, UI framework, shell extension, or plugin owns the target before changing configuration; machine-wide COM repair is not justified by a per-window lifecycle defect. Retain before-and-after traces for DRAGDROP_E_NOTREGISTERED so the change can be attributed and reversed.

References

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