OK, here\'s my problem: I\'m trying to launch a third-party application. This application is apparently configured to require elevation, presumably via an embedded manifest
This elevation is also required on some very simple programs that have UPDATE or SETUP or INSTALL in their names; nothing to do with a manifest. We write code in PICK BASIC that runs on Win2008 and if we write a HELLO WORLD program called UPDATE.TEST we can't run it without elevation. All we need to do is rename the program to fix... But annoying, and btws.
Another possible solution is to use use the Microsoft Application Compatibility Toolkit to create and install a custom compatibility database that applies the RunAsInvoker fix or the RunAsHighest fix to the application in question. Although the documentation does not say whether or not this works for applications that have requireAdministrator set in the manifest, I have tested this and it works for me.
You can install a compatibility database programmatically using the sdbinst command-line tool.
(In most scenarios, Norbert's answer will be considerably simpler to use, but there may be edge cases. In particular, using a compatibility fix may be preferable if your program is not directly responsible for launching the problematic executable.)
I'm afraid there's no way to workaround it.
If UAC is enabled and program manifests that it requires elevation, then the system tries to run this process as elevated. CreateProcess
would not start such a process if you're not elevated.
Use ShellExecute
or ShellExecuteEx
functions to start this third-party application. These functions will display UAC confirmation and start the process if user clicks Yes. Your UI element which starts this third-party application should have UAC-shield to notify users that UAC confirmation will be displayed.
Set the environment variable __compat_layer for your process to RunAsInvoker. If this environment variable is set, CreateProcess will succeed.
You can use the SetEnvironmentVariable function for this purpose.