What does HRESULT 0x80040100 (DRAGDROP_E_NOTREGISTERED) mean?

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. The documented description is “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.

Operational meaning

OLE drag-and-drop registration is tied to an HWND, its UI thread, and a COM apartment. IsWindow checks can describe a moment in time, but lifecycle serialization is what prevents stale handles, duplicate registration, and reentrant drag sessions.

• Associate this result with one exact operation in RegisterDragDrop, RevokeDragDrop, DoDragDrop, window lifetime, and IDropTarget ownership.
• Confirm that this result came from unregistering a window during destruction, feature disablement, or target replacement, rather than from cleanup or a wrapper that ran afterward.

Cause model

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

Troubleshooting workflow

1. Identify the exact object, method, and lifecycle phase involved in unregistering a window during destruction, feature disablement, or target replacement.
2. Track a successful RegisterDragDrop result as state owned by the window instance.
3. Log WM_NCDESTROY and feature-toggle order around RevokeDragDrop.
4. Confirm that the call runs on the thread and apartment that owns the window.

What to log

A useful incident records the HWND value, creating thread, apartment type, registration state, IDropTarget identity, active drag sequence, mouse capture, and destruction or recreation events.

Correction strategy

Correction. make revocation conditional on recorded successful registration and clear that state exactly once. Retry condition. Do not retry blindly; either register the live window first or treat the duplicate teardown as an application-state defect. Before repeating the 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.

Difference from related HRESULTs

DRAGDROP_E_ALREADYREGISTERED is the opposite lifecycle mismatch: registration is attempted while an active target already exists.

Developer and administrator guidance

Own registration state on the HWND’s UI thread, tie it to the window generation, and guard DoDragDrop against reentrant starts. Regression coverage 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.

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.

References

• Microsoft: generic COM error codes
• Microsoft: HRESULT values
• Microsoft: RegisterDragDrop
• Microsoft: RevokeDragDrop
• Microsoft: DoDragDrop