DRAGDROP_E_INVALIDHWND (0X80040102) Fix – Invalid Window Handle

You're dragging a file from Explorer into an app, and instead of dropping it you get 0X80040102 – DRAGDROP_E_INVALIDHWND. The error means the window handle (HWND) your app is trying to use for the drag-and-drop operation no longer exists or was never valid. I've seen this happen in Outlook, Visual Studio, and random third-party file managers.

The culprit here is almost always a stale window handle. Either the app crashed and restarted its UI without telling the drag-drop system, or you closed a dialog that was the intended drop target. Let's fix it.

Cause #1: Window Handle Became Stale After Restart or Dialog Close

This is the most common. You open a file dialog, drag a file into it, but you already closed that dialog. Or the app crashed and rebuilt its window, but the drag-drop context still points to the old HWND.

Fix: Restart the target application. That's it. The stale handle is cleared when the app re-registers its windows with the COM drag-drop manager.

If restarting doesn't help, kill all instances of the app. You can use Task Manager to make sure no background processes are holding the old handle. For example, if Outlook gives you this error, run:

taskkill /f /im outlook.exe

Then restart Outlook. 9 times out of 10 this fixes it.

Cause #2: Corrupted Clipboard or Drag-Drop Queue

The Windows clipboard and drag-drop manager share internal state. If a previous drag operation didn't complete cleanly — say you cancelled it mid-drag — the clipboard data may contain a dangling handle reference. This is especially nasty in Windows 10 2004 and 20H2 builds.

Fix: Clear the clipboard queue. Open a command prompt as admin and run:

echo off | clip

This pipes nothing into the clipboard, effectively flushing its contents. Then try your drag-drop again.

If that doesn't work, restart the Windows clipboard service. In an admin PowerShell:

Restart-Service -Name cbdhsvc* -Force

That kills all clipboard history daemons. They'll restart automatically when you next copy something.

Cause #3: COM Initialization Failure in the Target App

Less common, but I've seen it in custom apps that don't call OleInitialize() or CoInitializeEx() properly before setting up drag-drop targets. If the app doesn't initialize COM in the right apartment (STA vs MTA), the drag-drop manager can't resolve the HWND and returns 0X80040102.

Fix: This is a developer fix, but if you're an end user, check for updates to the app. Developers: ensure you call OleInitialize(NULL) before calling RegisterDragDrop(). Also verify the window you're passing to RegisterDragDrop was created with the WS_EX_ACCEPTFILES extended style. A common rookie mistake is registering a dialog that hasn't been fully created yet.

For end users: update the app to the latest version. If the devs patched it, the fix will be in the changelog as "fixed drag-drop crash when window handle is invalid."

Quick-Reference Summary

Skip trying to manually re-register OLE32.DLL or running SFC /SCANNOW — those rarely fix a stale handle issue. You're wasting time. Stick to restarting the app and clearing the clipboard. If that fails, blame the app vendor.