When creating a Windows Forms application in Visual Studio and implementing drag-and-drop you may encounter this exception during debugging if you drag outside your own application, even though the drag and drop operations complete successfully inside your application.
This may not be a bug, or even an error! Things to try:
- Run the application executable directly from the debug folder, not in Visual Studio debug mode.
- Run in VS debug mode with your application directly over a window that can accept its drag content type. Perform the drag directly from your application to the valid drop zone on the other application, passing over no other applications (including the desktop) or invalid drop zones. For example, if you are using DataObject.SetText, place your application directly over the text area of a text editor that accepts dragging, e.g. WordPad.
In those two conditions, you probably won’t see the exception thrown and the drag-and-drop will succeed.
I think what’s happening here is that Visual Studio is being a little too aggressive in watching the Windows event messaging system. Because of the way dragging works, these “first chance” COM exceptions will occur as the dragging mouse passes over targets that cannot accept the content stored in the DataObject. If they have any drag-drop awareness, they will attempt a COM native “get” operation on the FORMATETC structure created when you initiated the drag in your application (you used the DataObject wrapper and injected it with DoDragDrop, but this is what you did in effect). If the format doesn’t match any of the formats the dragged-over applications (including Windows Explorer, a.k.a. the desktop) accept, this exception is thrown. It is then, typically, handled either by that application or Windows itself, for example by switching to the “um, not so much” cursor (circle with line through it). Running outside of debug mode, or between two application that agree on format, it “just works” (dropping successfully in places it can, blocking the drop in places it can’t). In debug mode, VS is telling you, “hey, look, an exception, you could handle this if you wanted to,” but in most cases you’ll just let the OS or other applications handle it.
Bottom line: don’t sweat this one too much if your application runs okay outside the debugger and in the controlled debugging conditions described above.
Here’s an article that is the closest thing I could find to an official explanation.