In some badly-implemented software (in my case, iPhoneBrowser and MP3Gain, but there are others) after dragging a file/folder from explorer into the program, the explorer window will become unusable until the program finishes its operation. It cannot be resized, moved, or minimized, and none of the buttons or icons can be interacted with (the cursor is stuck on the "drop here" cursor). This lasts until the program finishes its operation It is possible to open another explorer window and navigate back there, but the original window is still frozen.

To be clear, this occurs with third-party software that responds to the drag-and-drop in the thread that created the event. Copying files in explorer does not trigger the issue.

Is there a way to prevent this behavior, so I can still interact with the explorer window while the program does its thing in its own thread/process/whatever? I have Windows 7 x64, but the behavior was present in XP32 as well, IIRC.

  • 2
    Don't use poorly-written software that doesn't handle drag/drop well? I think you've already identified the real problem. Any answer will be a workaround at best. – Velociraptors Aug 26 '10 at 0:58
  • Sadly, iPhoneBrowser is the best program that can do what it does. It's open-source and .NET, so I might just fix it myself. – Robert Fraser Aug 26 '10 at 1:46
  • 1
    And the problem is in Windows. Sure, the software could be better, but one fix to explorer could fix hundreds of buggy programs. – Robert Fraser Aug 26 '10 at 1:48

It IS fixable*, but you'll have to change your workflow slightly.

What you need is a helper application that implements both sides of drag-and-drop. When files are dropped to this helper, its IDropTarget will make a copy of the drop list and then free explorer to doing other things. Then you will drag-and-drop from the helper to iPhoneBrowser, which will lock only the copy of the drop list and not the original used by explorer.

By multi-threading the helper, it should also be possible to avoid having it frozen for the duration.

*Some assembly required. If you're not a programmer, make friends with one

  • Awesome; just what I was looking for. If I'm really bored someday, I'll make this. – Robert Fraser Sep 1 '10 at 16:57

I´m not sure, if I understand your problem correctly but have you considered opening a second explorer window?

  • Yes, this works, but I have to navigate back to where I was. – Robert Fraser Aug 24 '10 at 18:48
  • 1
    FYI, you can right-click (or shift+click) folders and the like from one explorer instance to create another, new, instance pointing at that location - which will save some navigation. – DMA57361 Aug 25 '10 at 11:59

I have written programs that handled drag and drop of files, and can say that this situation will only exist for badly written file-drop handling programs.

The lazy programmers kept the drop list open while processing the files, thus freezing Explorer, instead of just first getting out of it all dropped file names and then closing the list, so as to free Explorer BEFORE doing the processing.

  • Ah, the post wasn't very clear. The freeze lasts until the program finishes its operation, and does not occur when copying files. I think the problem is that Windows gives control of the thread to the application that finishes its task on that thread. – Robert Fraser Aug 26 '10 at 13:36

What about an application that takes over the entire copying process? e.g., SuperCopier 2


It may seem like a strange answer, but for large copying operations I tend to use xcopy. Yes, which I first learned how to use with DOS 6. It still works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.