2
votes

I have created a MSI project in Installshield and i added my installscript method as custom action for install some support driver items. I am using "LaunchAppAndWait" method for launch the executable file with parameters.

LaunchAppAndWait("C:\\Windows\\System32\\RUNDLL32.exe", szWBW, LAAW_OPTION_WAIT);

szWBW is my parameter string which i am passing to EXE file. When i executing this executable by command line as administrator it is working fine. Without admin priviledges, it will failed.

When i run my MSI setup, this line won't run properly and return the error like "Operation couldn't be completed 0x000007b" error message. So to resolve this problem, i want to run this as administrator. I couldn't find any solution to run this particular line as administrator till now.

I have tried another method also to run the EXE. Created the bat file with the following

cd C:\Windows\System32\
C:\Windows\System32\RUNDLL32.exe szWBW

Then i make this as EXE by converter tools. Call this EXE from Custom Action in my project. This method working fine in EXE setup. Because EXE setup run my EXE with admin priviledges. But MSI not doing this and failed to run properly.

(Note: I must need MSI setup not EXE setup.)

Please anyone give me the solution to solve this.

Thanks in advance.

1
The custom action might be immediate, so it won't run elevated. Make it deferred instead, that's somewhere to start, and basing the path on [WindowsFokder] property msdn.microsoft.com/en-us/library/aa372816(v=vs.85).aspx and you may have issues if this is a 32-bit setup on a 64-bit system.PhilDW

1 Answers

1
votes

Your are encouraged to run MSI-based setups with limited privileges. Part of this spills over into non-deferred actions always running in the user context that launched the MSI, and deferred actions having that option. So, as PhilDW commented, if you can set your custom action to run Deferred in System Context, that can give the action (and thus the exe it launches) the elevation it requires. You should further consider using UseDLL and related InstallScript APIs instead of calling into RunDll32, but that is merely a potential optimization.

In some cases, and this is much rarer, you need to elevate at a time that Windows Installer does not allow for. When this is the case you have two bad options. The first bad option is to change the manifest on your setup.exe to always run as administrator. This attempts to avoid the limited privilege context entirely, but this typically falls down during maintenance or if the setup.exe is not used to launch the installation.

The second bad option is to use LaunchApplication instead of LaunchAppAndWait, and include the option LAAW_OPTION_USE_SHELLEXECUTE. With ShellExecute, a UAC prompt can be shown to elevate the newly launched executable. Without ShellExecute (i.e. with CreateProcess), no UAC prompt is shown. This case is undesirable because it results in an extra UAC prompt for the user to accept.

(As an aside, setting LAAW_SHELLEXECUTEVERB to runas allows you to elevate an exe that doesn't require administrative privileges, on Windows Vista and later.)