What does HRESULT 0x80040102 (DRAGDROP_E_INVALIDHWND) mean?

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

The window handle supplied to OLE drag-and-drop registration is not a valid live HWND.

Previous	Next
DRAGDROP_E_ALREADYREGISTERED	DRAGDROP_E_CONCURRENT_DRAG_ATTEMPTED

DRAGDROP_E_INVALIDHWND

Invalid window handle

When Windows returns DRAGDROP_E_INVALIDHWND—HRESULT 2147746050, 0x80040102, signed -2147221246—AllStat describes the condition as “Invalid window handle”. The actionable meaning is The window handle supplied to OLE drag-and-drop registration is not a valid live HWND. The surrounding operation is registering or revoking a drop target while windows are created, destroyed, or marshaled across threads.

The high bit in 0x80040102 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 258 (0x0102). 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 this result remain essential.

Precise failure point

Understanding this result requires this subsystem context: 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 registering or revoking a drop target while windows are created, destroyed, or marshaled across threads, rather than from cleanup or a wrapper that ran afterward.
Preserve any IErrorInfo, underlying Win32 result, provider message, or callback failure that preceded it; the HRESULT alone should not erase a more specific cause.

Diagnostic evidence

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. 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 it, redact content and credentials while preserving types, lengths, hashes, opaque identities, and lifecycle generations needed to reproduce its contract.

validate IsWindow only as a diagnostic snapshot, not as a synchronization guarantee.
log the window class, owning process/thread, and creation generation.
serialize register/revoke operations with window lifetime on the UI thread.

Resolution path

Capture it at the first native return before a wrapper maps it to a generic exception.
Identify the exact object, method, and lifecycle phase involved in registering or revoking a drop target while windows are created, destroyed, or marshaled across threads.
Reproduce it with one controlled input or state change, and verify that the correction changes the decisive evidence rather than merely hiding the result.

Distinct causes

It can result when the handle is null or has already passed WM_NCDESTROY.
It can result when an integer truncation or stale cache corrupts the HWND value.
It can result when registration races with asynchronous window recreation or runs against a child window that no longer exists.

Retry policy

Correction. for it, perform registration after the HWND is created and revoke before final destruction, keeping the handle scoped to that window generation. Retry boundary. Retry only after obtaining the current live HWND; the stale numeric value must never be reused. 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 panel is recreated after a DPI-mode change, but background initialization retains the old HWND; posting registration to the new window thread fixes the race. This isolates it within OLE drag-and-drop registration and modal tracking and provides a regression test for the stated correction.

Difference from related HRESULTs

E_HANDLE is a broad invalid-handle result; it names the OLE drop-target registration contract. Keep those outcomes separate in exception mappings, telemetry dimensions, user messages, and automated retry policy.

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 for it 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 it 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 it so the change can be attributed and reversed.

References

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