| Previous | Next |
| DRAGDROP_E_NOTREGISTERED | DRAGDROP_E_INVALIDHWND |
DRAGDROP_E_ALREADYREGISTERED
This window has already been registered as a drop target
DRAGDROP_E_ALREADYREGISTERED has hexadecimal value 0x80040101 (unsigned 2147746049, signed -2147221247). Windows reports “This window has already been registered as a drop target”. The narrow interpretation is that RegisterDragDrop was called for an HWND that already has an OLE drop target. The failing stage is enabling drag-and-drop or replacing an IDropTarget on a live window.
API stage
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 enabling drag-and-drop or replacing an IDropTarget on a live window, rather than from cleanup or a wrapper that ran afterward.
Verification steps
- Identify the exact object, method, and lifecycle phase involved in enabling drag-and-drop or replacing an IDropTarget on a live window.
- Identify the component that performed the first successful registration.
- Record the IDropTarget identity and feature owner in window state.
- Check subclassing, docking, and framework startup paths for duplicate enablement.
Interpretation limits
- It can result when initialization is invoked twice without paired revocation.
- It can result when a framework registered its own drop target before application code.
- It can result when the window handle is reused while stale application bookkeeping says it is a new instance.
Incident record
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.
Recovery conditions
Correction. reuse the existing target, coordinate ownership with the framework, or revoke once before registering the replacement on the owning thread. Retry condition. Retry is safe only after successful RevokeDragDrop and after preventing active drags from observing a half-swapped target. 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 UI toolkit enables OLE drops automatically, then a plugin registers another target on the same HWND; the plugin integrates with the toolkit target instead of overwriting it.
Difference from related HRESULTs
DRAGDROP_E_NOTREGISTERED reports an extra revoke; it reports an extra register.
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
Looking for a different code? Search another status or error code.