locked
CreateProcess() + "highestAvailable" = error 740 RRS feed

  • Question

  • On vista Beta 2, i have added a manifest to one of my executeables that specifies the "highestAvailable" application marking.

    If I am logged on as a member of the administrator group, with UAC at the default setting, and call CreateProcess() on this executable, it fails with GetLastError()==740.

    Wouldn't it be better if the process creation succeeded, but as a limited user?

    This makes things very difficult to code for - if my application is started directly by the user, via cmd.exe for example, I get the UAC dialog, but if it is started silently via CreateProcess(), it fails completely.

    How about if a service needs to impersonate a user, but with elevated privileges enabled? A code sample for this would be great.

    Tuesday, June 13, 2006 10:49 AM

All replies

  • According to the documentation on UAC (User Account Control) the CreateProcess command doesn't support elevation of privileges instead you should use (in managed code) something like:

    Process proc = new Process();

    proc.StartInfo = new ProcessStartInfo(@"<path to new application>");

    proc.StartInfo.UseShellExecute = true;

    proc.Start();

     

    Wednesday, June 14, 2006 12:56 PM
  • I´m doing this from regular unmanaged C++.

    I guess my gripe is that if CreateProcess() doesn't support elevation, then it shouldn't block process creation either. I would have expected it to create the process, but without elevation in this case.

     

    Thursday, June 15, 2006 6:38 AM
  • I stumbled accross the same problem, and I read in a other thread to use ShellExecute() instead of CreateProcess.ok.

    But, what the hell does ShellExecute() to provide CreateProcess() with the parameters, that it works properly, because by the end it must come down to CreateProcess(), because this is the function exported kernel32.dll to start processes.

    Well, there is one other way. It might use NtCreateProcess() from ntdll.dll, but in both scenarios it does something to satisfy xxCreateProcess to work properly, and this is done in usermode.

    So are there calls to deal with UAC, which are performed by ShellExecute(), and with the results CreateProcess is satisfied?

    Anyone from UAC team reading this?

        Ciao Hermann

    Saturday, June 17, 2006 1:30 PM
  • ShellExecute() doesn't have the fine control over process creation, like CreateProcess() does. For me, this makes it a less than ideal solution. I would be happy if there was a new manifest execution level that showed the UAC dialog when called with ShellExecute(), and allowed the process to be created non-elevated, if called by CreateProcess().

    On a related note, how does impersonation work with UAC? Is it possible to get the elevated token for impersonation purposes?

    Tuesday, June 20, 2006 7:28 AM
  • Chris,

    Remember this>

    http://groups.google.com/group/comp.os.ms-windows.misc/tree/browse_frm/thread/2e504f3435ab24d4/7baf6b6cad9cbab5?rnum=531&q=intel+x86+consortium&_done=%2Fgroup%2Fcomp.os.ms-windows.misc%2Fbrowse_frm%2Fthread%2F2e504f3435ab24d4%2F96cbe4eb2c34c5c9%3Flnk%3Dgst%26q%3Dintel%2Bx86%2Bconsortium%26rnum%3D1%26#doc_761ebda0a17cb4d8


    Saturday, February 17, 2007 4:11 PM
  • Hermann, ShellExecute indeed calls CreateProcess.
    When elevation is required, that CreateProcess fails (740 => ERROR_ELEVATION_REQUIRED).
    ShellExecute notices that error code and takes appropriate action to trigger the elevation.
    Ultimatly, it's the Application Information Service that starts the elevated process using CreateProcessAsUser.

    HighestAvailable is meant for applications that work well elevated or not (regedit.exe, mmc.exe), and should run elevated whenever possible.
    But when the logged on user is not strictly a standard user (i.e. his elevated token would be the same as his standard token), elevation is always triggered.

    Tuesday, February 20, 2007 12:00 AM
  • Yes, ShellExecute is really quite deficient compared to CreateProcess.  At least two problems I see are that (a) the child has to run in a separate window, which is lame if it's a console app called from the command line and (b) it doesn't appear that you can pipe stdin / stdout / stderr to the child.

    It looks to me like Microsoft has made a mess of the elevation problem in Vista.  This should not be a big deal.

    1.  You should be able to request elevation (and spawn the popup) from a running process.  There are just too many scenarios where most of the time, you can accomplish the task without elevation but won't discover the exception until you're underway.  Consider, e.g., a case where you're modifying ACLs on a bunch of files.  No problem on most but you hit one with an ACL you'll need elevation to deal with.  You should be able to ask for elevation right then.

    2. You should be able to spawn elevated children through CreateProcess with the system handling the popup.

    3. CreateProcessAsUser should still work.  (Anyone who's tried making it work under Vista already knows what I'm talking about.)  This is just plain busted right now.
    Tuesday, June 2, 2009 1:01 AM
  • There are a lot of answers to your questions and complaints in the Channel 9 video about UAC, as well as in the comments attached to the video.

    http://channel9.msdn.com/shows/Going+Deep/UAC-What-How-Why/
    Tuesday, June 2, 2009 9:34 PM