Windows Installer custom actions, UAC and elevation

We had a problem this week where a merge module from a third party was causing our installer to fail under UAC.

The installation was being elevated, but the custom actions (which were doing things such as file system and registry operations) were still failing due to security exceptions.

The root cause was that the merge module contained custom actions that were still not being run under the elevated account.

The reason behind this is a common one when scheduling deferred actions; the custom action must have the Impersonate flag set to false.

You can do this in WiX code by setting Impersonate to No:

<CustomAction Id="RegisterAspNet4" BinaryKey="WixCA" DllEntry="CAQuietExec"

Execute="deferred" Return="check" Impersonate="no"/>

The documentation in WiX on the Impersonate attribute reads (emphasis mine):

This attribute specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. Typically the value should be ‘yes’, except when the custom action needs elevated privileges to apply changes to the machine.

Being a third party merge module, we had to fix this ourselves by opening up Orca and setting this flag manually.

You can do this by looking at the CustomAction table, finding your custom action in the list, and checking the Type field.

The Type field is a field full of flags, and will show up as a decimal number e.g. 1025.

If you open up Windows Calculator, switch to Programmer (View > Programmer or Alt+3), choose Decimal and enter the number, you can check the bit fields:


The first bit is set to signify it as an In-Script Execution custom action (type 1).

The 11th bit is set to signify Deferred execution (i.e. instead of running immediately, we schedule when the installer should run our custom action).

The 12th bit (the one I’ve highlighted) is the one that turns off impersonation; this is the bit we need to flip on to disable impersonation for this custom action, so that it runs with elevated privileges.

Being the twelfth bit, that is a value of 2048, so we can just add that to our value, giving us 3073:


You can see the No Impersonate bit is now flipped.

You can now update the value in Orca and save the merge module (or create a transform).


UAC in MSI Notes: The NoImpersonate Bit Mistake 

Custom Action In-Script Execution Options (Windows)

HOW TO: Detect if the Visual C++ 2010 redistributable package is installed with WiX

As noted by Aaron Stebner, there is now a registry key you can search for to detect if the Visual C++ 2010 redistributable package is installed a machine, when installing your application.

There are 3 different (but very similar) registry keys for each of the 3 platform packages. Each key has a DWORD value called “Installed” with a value of 1.

  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistx86
  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistx64
  • HKLMSOFTWAREMicrosoftVisualStudio10.0VCVCRedistia64

Here’s an example of using this in WiX, detecting the presence of the x86 version of the redistributable:

<?xml version="1.0" encoding="utf-8"?>
        <!-- Visual C++ 2010 x86 -->
        <Property Id="HASVCPP2010">
        <RegistrySearch Id="HasVCPP2010Search" Root="HKLM" Key="SOFTWAREMicrosoftVisualStudio10.0VCVCRedistx86" Name="Installed" Type="raw" />
    <Condition Message="This application requires Microsoft Visual C++ 2010 Redistributable Package (x86).">Installed OR (HASVCPP2010)</Condition>

When someone runs your installer and they don’t have this package installed, they will get something like this message box when the installer initializes:


It’s a good idea to have a setup bootstrapper that automatically installs this package if it’s missing, but this WiX snippet is a good safe-guard for if someone directly runs your MSI.


HOW TO: Debug a Windows Installer custom action


  • Determine the name of the custom action you want to debug
  • Ensure you have the source code and debug symbols for your custom action


  1. Set the MsiBreak environment variable (user or system) to the name of the custom action. For example:

    Setx MsiBreak MyCustomActionName

  2. Run your installer
  3. At the point where your custom action is about to run, you should get this message box prompt:

  4. Now you can use Visual Studio or another debugger such as WinDBG to attach to the specified process.
  5. Click OK on the message box
  6. This should break into your debugger. This is a good time to set your breakpoints in your custom action code.
  7. When ready, run/continue the debug session.
  8. Your custom action should run and your breakpoint(s) will be hit.


Debugging Custom Actions @