WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WinBatch
Vista

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

UAC & OLE Drag-n-Drop 

 Keywords: UAC Vista Elevated
This isn't a problem specific to WinBatch, but it could certainly affect WinBatch scripts of very specific type. With the end-user community here having a growing awareness of the weirdness & complications that UAC introduces when enabled in Vista, this is one more tid-bit of information to tuck away in your mind and keep handy for a later date.

When UAC is enabled, you can have "2nd class citizens" in terms of applications that are running. This is due to the fact that UAC creates a restricted access-token that has all admin rights & privileges removed from it, and all processes that a user creates run under this access-token unless the "Run as Administrator" functionality is used to create them. When you do run a program elevated as an administrator, UAC does some things to make sure that the program cannot be surrepticiously misused or abused by other non-privileged processes. There are DACLs applied to the windows owned by the elevated process such that unprivileged applications cannot manipulate the windows or send messages to them. This feature can be directly observed with the Control Manager extender, where an unelevated script cannot control the windows of an application that is running elevated.

The little gotcha I ran across recently has to do with OLE & Drag-n-Drop. DnD is limited in the same way that window security is used to restrict access to an elevated process' resources. In a nutshell, unelevated processes cannot successfully use a window of an elevated process as a drop target. Windows & the OLE environment won't permit this. You can drag something out of a window owned by an elevated process, and drop it on any other valid drop target, though.

How does this apply to WinBatch? Well, IIRC, there was a discussion on here in the past regarding WIL dialogs, OLE events and the using COM components as controls in a WIL dialog. One of the points of the discussion was relating to using a control that functions as a drop target, thus enabling a WIL dialog to become a drop target that can process files that are dropped on it via Drag-n-Drop. Scripts using such a technique will be affected by UAC as described above.

And, to add just a bit more complexity to the issue, the Windows Explorer desktop shell always runs with the restricted access token when UAC is enabled. So, if you're in the habit of dragging files & folders from an Explorer window and dropping them into an application, this UAC enforced restriction of OLE Drag-n-Drop functionality will apply if the application serving as the drop target is running elevated.

Here is a short sequence of steps to demonstrate the "problem" 

1) Configure Vista to have UAC enabled & reboot.

2) Logon as a user that has administrative rights & privileges granted to them on the local system.

3) Open an Explorer window and browse to some location that has a text file.

4) Launch one instance of Notepad as the normal user [e.g. with the restricted access-token]. Launch a 2nd instance of Notepad, but use the "Run as Administrator" feature to run it. Be sure to keep track of which instance is which.

5) Drag the text file out of Explorer and drop it on the normal user instance of Notepad. Please note that Notepad opens the file and you see its contents in Notepad.

6) Drag the same text file out of Explorer and drop it on the elevated instance of Notepad. Please note that nothing happens when you do the drop. File is not opened, and its contents is not displayed in that instance of Notepad.
There seems to be some variation in how the drop operation is prevented from occurring. In some cases, all indications are "normal" in that the mouse pointer changes and signals that drag-n-drop should be OK to perform over the specified drop target, even if the target is elevated and the source is not. In other cases, you get the "circle & slash" mouse pointer indicating that the mouse is not over a valid drop target. 
Article ID:   W17493

File Created: 2008:04:10:15:11:32
Last Updated: 2008:04:10:15:11:32