[RESOLVED] WinExec API blocked by Windows 7 (when used with asInvoker)-VBForums
Results 1 to 5 of 5

Thread: [RESOLVED] WinExec API blocked by Windows 7 (when used with asInvoker)

  1. #1

    Thread Starter
    Frenzied Member some1uk03's Avatar
    Join Date
    Jun 2006
    Location
    London, UK
    Posts
    1,244

    Resolved [RESOLVED] WinExec API blocked by Windows 7 (when used with asInvoker)

    I just happened to realise that the WinExec API does not function under
    Windows 7 (haven't tried under Vista yet, but will do soon) when the application has a manifest requestedExecutionLevel asInvoker.
    with requireAdministrator however it works ofcourse.

    Is there a way around this?

    As a replacement I'm currently using the ShellExecute API to execute .exe's, but the problem with this API is that it requests command line arguments separately, so I have to personally code & detect and pass them on, where as on the WinExec API it does it for you.

    Any solutions?
    _____________________________________________________________________

    ----If this post has helped you. Please take time to Rate it.
    ----If you've solved your problem, then please mark it as RESOLVED from Thread Tools.



  2. #2
    PowerPoster
    Join Date
    Feb 2006
    Posts
    11,205

    Re: WinExec API blocked by Windows 7 (when used with asInvoker)

    Seems like a long way around just to do what the Shell() function in VB6 already does. Is there something else you feel this is buying you?

    WinExec is old. 16-bit Windows old.
    WinExec Function

    Runs the specified application.

    Note This function is provided only for compatibility with 16-bit Windows. Applications should use the CreateProcess function.

  3. #3
    PowerPoster isnoend07's Avatar
    Join Date
    Feb 2007
    Posts
    3,123

    Re: WinExec API blocked by Windows 7 (when used with asInvoker)

    I also have a app that is ran as invoker and uses ShellExecute to open online webpages (buy button, online help) and it works fine as a standard user on vista. Don't know about windows 7 from what i have heard if it works on vista it will work on windows 7. been waiting to see a difference. Are the exe's you are calling yours? If yes then maybe a manifest run as invoker with the exe's ?

    I have a program updater that requires admin and if a standard user tries to do a update they are told to open as admin to do program updates using
    Private Declare Function IsUserAnAdmin Lib "shell32" () As Long to see if they are admin.
    Waiting for a full featured smart phone with out marrying a provider
    Go Android
    Go raiders

  4. #4

    Thread Starter
    Frenzied Member some1uk03's Avatar
    Join Date
    Jun 2006
    Location
    London, UK
    Posts
    1,244

    Re: WinExec API blocked by Windows 7 (when used with asInvoker)

    The good thing about WinExec is the fact that it separates command line arguments for you!
    Whereas with ShellExecute, you must pass them separately.

    i.e WinExec is fine with winExec (MsiExec.exe /I{205C6BDD-7})

    Whereas Shellexecute you need to separate
    MsiExec.exe
    /I
    {205C6BDD-7}
    and pass them..

    Are the exe's you are calling yours? If yes then maybe a manifest run as invoker with the exe's ?
    Yes the exe is mine ,and It's already running asInvoker which is where the problem is.

    requireAdministrator works fine.
    _____________________________________________________________________

    ----If this post has helped you. Please take time to Rate it.
    ----If you've solved your problem, then please mark it as RESOLVED from Thread Tools.



  5. #5
    PowerPoster
    Join Date
    Feb 2006
    Posts
    11,205

    Re: WinExec API blocked by Windows 7 (when used with asInvoker)

    It seems that your real question is whether you can enter an entire "command line" in one piece using ShellExecute(). The answer seems to be a definite "no" based on the documentation.


    WinExec(), like VB's Shell() function, is a fairly thin wrapper on the CreateProcess() function. CreateProcess() can be called in an insecure manner that allows this "all at once" command line:
    Security Remarks

    The first parameter, lpApplicationName, can be NULL, in which case the executable name must be in the white space–delimited string pointed to by lpCommandLine. If the executable or path name has a space in it, there is a risk that a different executable could be run because of the way the function parses spaces.

    :

    If a malicious user were to create an application called "Program.exe" on a system, any program that incorrectly calls CreateProcess using the Program Files directory will run this application instead of the intended application.

    To avoid this problem, do not pass NULL for lpApplicationName. If you do pass NULL for lpApplicationName, use quotation marks around the executable path in lpCommandLine, as shown in the example below.

    LPTSTR szCmdline[] = _tcsdup(TEXT("\"C:\\Program Files\\MyApp\" -L -S"));
    CreateProcess(NULL, szCmdline, /*...*/);
    I actually got burned by this very exploit once, and always try to be careful to quote the program path now.


    ShellExecute() is a much heavier-weight wrapper on CreateProcess() because it is a request asking the Windows Shell to carry out a verb upon a file. If the verb is null and the file is a program, then it acts like you used the "open" verb.

    The reason it seems to act differently in Vista and later versions of Windows is that ShellExecute() now takes an even longer path. The Vista developer documents cover this in some detail. An excerpt:
    Standard User Launch Path

    The Windows Vista standard user launch path is similar to the Windows XP launch path, but includes some modifications.
    1. ShellExecute() calls CreateProcess().
    2. CreateProcess() calls AppCompat, Fusion, and Installer Detection to assess if the application requires elevation. The executable is then inspected to determine its requestedExecutionLevel, which is stored in the executable's application manifest. The AppCompat database stores information for an application's application compatibility fix entries. Installer Detection detects setup executables.
    3. CreateProcess() returns a Win32 error code stating ERROR_ELEVATION_REQUIRED.
    4. ShellExecute() looks specifically for this new error and, upon receiving it, calls across to the Application Information Service (AIS) to attempt the elevated launch.

    Elevated Launch Path

    The Windows Vista elevated launch path is a new Windows launch path.
    1. AIS receives the call from ShellExecute() and reevaluates the requested execution level and Group Policy settings to determine if the elevation is allowed and to subsequently define the elevation user experience.
    2. If the requested execution level requires elevation, AIS launches the elevation prompt on the caller’s interactive desktop (based on Group Policy), using the HWND passed in from ShellExecute().
    3. Once the user has given consent or valid administrator credentials, AIS will retrieve the corresponding access token associated with the appropriate user, if necessary. For example, an application requesting a requestedExecutionLevel of highestAvailable will retrieve different access tokens for a user that is only a member of the Backup Operators group than for a member of the local Administrators group.
    4. AIS reissues a CreateProcessAsUser() call, supplying the administrator access token and specifying the caller’s interactive desktop.
    You might also consider:
    Elevation and process creation APIs

    In Vista, process creation APIs behave very differently with respect to UAC. If you call CreateProcess() on an executable which is manifested as “RequireAdministrator” or is flagged as an installer by Vista, you will get back an ERROR_ELEVATION_REQUIRED (740) error.
    When you call WinExec() trying to run msiexec.exe the CreateProcess() call fails if the first program is not already running elevated. This is because msiexec.exe is an installer and marked as such by Vista (or Windows 7).

    Using ShellExecute() avoids this by letting CreateProcess() first fail, detecting the failure, and then sending the request on to AIS to handle presenting an elevation request if actually required. One thing is special about msiexec.exe: AIS will start it and query its state, and if msiexec.exe reports that it is doing a per-user install then AIS will silently let the install run unelevated. Qualifying for a true per-user install requires that several requirements be met however. Unless your program to be installed was written and packaged for it you do not want a per-user install anyway.


    To make a long story short you'll need to use ShellExecute() if you have to spawn a process that requires elevation.
    Last edited by dilettante; Oct 9th, 2009 at 08:15 PM.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.