DDE conversation with other app running "As Administrator"

[stevengraff]

My Winbatch script functions, in part, by talking to a running instance of GoldMine Software via DDE. I recently found out that if GoldMine was launched using the right-click | As Administrator option, my script won't talk to it, unless I also run it As Administrator.

Question: Is there a way for my script to "interrogate" the currently running instance of GoldMine to find out whether it's running with elevated privileges? That way I could at least let the end-user know why it's failing; maybe avoid one more support call.

[ChuckC]

Many [but not all] applications end up with the text "Administrator" added to their title in the title bar of their main window when they have been run elevated as an administrator.  If the application that your script interacts with has this property, then it should be easy to determine its elevation state simply by examining the title text of the window.

If the application doesn't change its title bar text to signify when it is running elevated, then there may not be much of anything that can be done by your script if it runs restricted as a normal user.  All of the Win32 API functions that could allow you to determine if a particular process is running elevated require that you execute them while running elevated.

I'm not sure if anything could be done with a manifest to grant a restricted application the ability to communicate via DDE with an application that is running elevated, but Tony might be able to shed some light on that subject.

[td]

The brute force approach would be to attempt to have the restricted process do something to the elevated process that restricted processes are not normally permitted to do.  The FCL's  "System.Diagnostics.Process" class comes to mind as a strait forward way to do this but it does require having a version of WinBatch with CLR support.  If you do have a version with CLR support you could simple use the "Process" class to attempt to access the elevated process's "Handle" property. If your script is running as a restricted user and the targeted script is running as a full privileged admin, this will result in an COM/CLR exception error.  Trap that error then you can inform the user that that they need elevated admin privileges to proceed.

If you don't have CLR support, you may be able to do something similar with WMI or perhaps there is an even easier test.

[stevengraff]

Thanks...

For now, if my ddeInitiate command fails, I use an askYesNo to ask him whether GoldMine's actually running. If yes, I give him a brief explanation as to the probable cause, and a link that leads to a more-detailed explanation, with work-arounds.

Still, a simple WMI test would be mighty fine.

[td]

A very lightly tested rough example that may work as a starting point.

Code (winbatch) Select Expand

; COM version
strName = "cmd.exe"
objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
colProcesses = objWMIService.ExecQuery( "Select * from Win32_Process Where Name = '%strName%'")

ForEach objProcess in colProcesses
    strCommandLine = objProcess.CommandLine
    if  StrLen(strCommandLine) == 0 then Pause(strName, "Is elevated but this script is not")
next


[stevengraff]

Thanks!

I would have come up with that... never! :)

Can I donate $25 to your favorite charity?