Is there a known bug in Visual Studio 2008 for using drop target in C++ when running Visual Studio as administrator?

Question

We have an application that allows a user to drag a picture to a window and that window is a drop target (using OLE). When this code is run in the debugger and the Visual Studio instance is run as administrator (right click from desktop) then the target drop is not allowed.

If the exe is run on its own it works fine.

If the visual studio instance is run NOT as an admin the functionality works fine in the debugger. (Same solution/project files/etc)

Win7 OS. Visual Studio 2008. Unmanaged C++

I find it very odd. Not sure why it is happening. In fact I would have guessed the OPPOSITE regarding running VS as an admin.

Has anyone seen this or does anyone have links to workarounds or explanations?

Answer 1

This is most likely happening due to UIPI (User Interface Privilage Isolation).

In the case where you've launched your processes as Admin (due to the parent process (Visual Studio) being run as admin), UIPI isn't going to let non-elevated (admin) processes send any messages to your app. Drag and Drop between applications is implemented using Windows messages.

To work around this, you can use the ChangeWindowMessageFilterEx() API to opt into the appropriate drag and drop messages.

Answer 2

Unfortunately this looks like a flaw in the OS:

http://blogs.msdn.com/b/patricka/archive/2010/01/28/q-why-doesn-t-drag-and-drop-work-when-my-application-is-running-elevated-a-mandatory-integrity-control-and-uipi.aspx

Oh well.

I find this whole issue appalling. MS has screwed up on this IMO. Essentially we can't debug an app correctly if I want to run MSVC in elevated mode (for example when I build the solution it registers COM servers).

http://social.msdn.microsoft.com/forums/en-US/windowsuidevelopment/thread/2fa935cf-be57-4bcc-9b96-7ee5a6b2b7a5/

Answer 3

If you want to really and truly fix it, then you would need to

1. Detect when your process is running elevated
2. Spawn a non-elevated helper process which registers as the drop target
3. Pass the dropped data through IPC to the elevated process, using a method that's safe to use across privilege boundaries (i.e. no active objects which carry code)

This is a LOT of extra work when the workaround could be as simple as dropping from another elevated app (to get an elevated Explorer, just call up the File->Open dialog of any elevated app), but has the advantage that drag-and-drop will work properly if any of your customers ever run the app elevated.