I was contacted a few days ago by a long time user with a weird problem with Control Runner. Apparently drag and drop from the Desktop or Explorer had stopped running.

Unable to think of a cause for this problem, I scheduled a remote assistance session with the user. After seeing by myself that drag and drop was not working, I noticed that he was launching Control Runner as an administrator, using a shortcut on the desktop with the little UAC icon.

I asked him to modify the shortcut to Control Runner, to launch it normally and, presto! Control Runner was happily accepting files from the desktop again.

I quickly created a test version that logged all drag and drop related activity [I seem to be doing this very often lately] and was surprised to see that Control Runner was not receiving any message related to drag and drop when running in elevated (as an administrator) mode.

Time to Google “drag and drop not working elevated UAC” and the cause of this strange behavior was immediately made evident. The best explanation of the issue is contained in this blog post:

Why Doesn’t Drag-and-Drop work when my Application is Running Elevated? – A: Mandatory Integrity Control and UIPI

It seems to be possible to tweak the system to permit an elevated process to receive messages from unelevated processes, but I don’t see the need to run Control Runner as an administrator (if fact, I think it makes sense not to run Control Runner as an administrator for security reasons) and therefore, I consider this issue as solved.

If I had not seen the shortcut icon on the desktop of the client and noticed the little shield UAC icon, solving the problem would have been nearly impossible. This is why I try to do remote assistance support whenever I can.