Freigeben über


UAC in MSI Notes: How do I troubleshoot UAC in MSI via the log?

This is the twentieth in a series of notes about UAC in MSI. Per the earlier caveat, these are just my notes and not an official position from the Windows Installer team. The previous entries

  1. Introduce...
    1. ...the UAC in MSI Notes series
    2. ...my view of the root problem
    3. ...the conflicting per-user definition
    4. ...it'll be just like Managed Installs
    5. ...the jagged edge to user
    6. ...my relief providing framework
  2. Architecture Insights
    1. The "Saw Tooth" Diagram
    2. Credential Prompt and Permissions
  3. Common Package Mistakes
    1. The AdminUser Mistake
    2. Modify System with InstallUISequence Custom Action
    3. Modify System with InstallExecuteSequence Custom Action Outside of Script
    4. The NoImpersonate Bit Mistake
  4. More Architectural Insights
    1. My "Four Square" Diagram
    2. Challenges for a Beautiful Custom Action
    3. O Whitepaper, Where Art Thou?
    4. Read the Friendly Manual
  5. Conversations with Customers
    1. Should I write my installer as a Standard User install? If yes, how?
    2. When General Custom Action Mitigation Fails
    3. How do I get the shield on the advertised shortcut?

This entry continues a section specifically focused on Question and Answers that often come up in the UAC in MSI dialogs.  For this topic, the question is: how do I troubleshoot UAC in MSI via the log?

Troubleshooting Windows Installer Packages via Logs

Generating verbose logs for a Windows Installer package are often the best troubleshooting technique to determine what went wrong for an install.  With the UAC in MSI functionality, there are a lot of lines in the logs to help you understand what happened.  Here's a list....

How can I troubleshoot when the call to a custom action has failed due to lack of access to a machine?

Custom actions vary in their quality and proper handing of errors.  The underlying error the custom action will receive from their Windows API call is 0x80070005 (Access is Denied).  Assuming the custom action has not written errors to the log indicating Access is Denied, the best guess method is to

  • Determine the problem occurred in a custom action by searching for Return Value 3 in the verbose log and looking immediately before the error to see of a Custom Action as the source of the error.
  • Run the same install from an elevated command prompt and check to see if the same custom action was successful.

Generally this indicates the custom action was the problem. The body of the document contains the most frequent custom action errors under UAC and their mitigations.

How can I troubleshoot when a Custom Action attributes do not include the NoImpersonate bit?

The Windows Installer verbose log will contain the following fragment (in bold) when launching a custom action.  The number to the right (in bold italics) is the value from attribute table.  For this case, this number should have been

CustomActionSchedule(<snip>,ActionType=1025,<snip>)

What is the source of the log message “ MSI_LUA: Credential prompt functionality not available on this operating system ”?

This message will occur if the operating system is not Vista.

How can I troubleshoot whether the Windows Installer was run from an elevated context?

The Windows Installer verbose log will contain the following line when the caller to the Windows Installer is already elevated.

MSI_LUA: Credential prompt not required, user is an admin

How can I troubleshoot whether the Windows Installer was with the AlwaysInstallElevated policy set?

The Windows Installer verbose log will contain the following line when the AlwaysInstallElevated policy is set.

MSI_LUA: No credentials required as all installs will run elevated due to AlwaysInstallElevated policy setting

How can I troubleshoot whether the Windows Installer saw the LUAAware bit on a package?

The Windows Installer verbose log will contain the following line when the package contained the LUAAware bit.

MSI_LUA: Package is marked as LUA installation capable with no elevation required

How can I troubleshoot whether the Windows Installer opted out of prompting for credentials because the install was silent?

The Windows Installer verbose log will contain the following line when the package was run in silent mode and therefore could not prompt for credentials.

MSI_LUA: Installation UI level is silent, no credential elevation is possible

How can I troubleshoot whether the Windows Installer did not prompt for credentials because the install was already managed?

The Windows Installer verbose log will contain the following line when the package was already managed therefore did not require a credential prompt.

MSI_LUA: Credential prompt is not required at this point, product is managed

How can I troubleshoot the difference between the inability to access the UAC policy and that the UAC policy disabled the credential prompt?

The Windows Installer verbose log will contain the following line when the attempt to access the UAC policy failed.

MSI_LUA: Credential prompt unavailable, LUA policy detection failed with %d

The Windows Installer verbose log will contain the following line when UAC policy disallowed the credential prompt.

MSI_LUA: Credential prompt disabled due to LUA policy settings

How can I troubleshoot when the Windows Installer has received an Over The Shoulder elevation rather than an Admin Approval Mode elevation?

The Windows Installer verbose log will contain the following line for an Over The Shoulder elevation.

MSI_LUA: Detected that session token differs from user token, will use session token as effective token

How can I troubleshoot when the call from Windows Installer to the credential dialog service failed?

The Windows Installer verbose log will contain the following line when there was an error returned from the credential dialog service.

MSI_LUA: Failed to obtain credentials. Error = 0x%X

Does Windows Installer credential dialog when UAC has been turned off by policy?

No.  The Windows Installer respects the UAC policy and terminates the install due to inability to get credential prompt.  If the install is run with under verbose logging, the following log entry is added.

MSI_LUA: Credential prompt disabled due to LUA policy settings

How can I troubleshoot whether Windows Installer fakes the AdminUser property?

The Windows Installer verbose log will contain this line when AdminUser is faked.

MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation

Additionally the log will not have this line

Property(C): MSIREALADMINDETECTION = 1

How can I troubleshoot whether the Windows Installer package has enabled UAC patching?

The Windows Installer verbose log will contain this line when UAC patching is not available due to a missing MsiPatchCertificate table.

LUA patching is disabled: missing MsiPatchCertificate table

The Windows Installer verbose log will contain this line when UAC patching is not available due to the fact that the original package was installed per-user (ALLUSER is not defined)

LUA patching is disabled: not available for per-user installs

What does the LUASetting value from the log mean?

Example (in bold): Executing op: ProductInfo(<snip> LUASetting=0 <snip>)

LUASetting reports whether the Windows Installer considers the package is authorized for UAC (0 meaning not authorized and 1 meaning it was).

How can I troubleshoot whether the Windows Installer prompted for credentials?

The Windows Installer verbose log will contain the following line when prompting for credentials.

MSI_LUA: Elevation required to install product, will prompt for credentials

How can I troubleshoot what was returned to the Windows Installer from the successful credential prompt?

The Windows Installer verbose log will contain the following two line the prompt for credentials has been successful.

MSI_LUA: Credential Request return = 0x0

MSI_LUA: Elevated credential consent provided. Install will run elevated

Why does the Installer.InstallProduct call in my web page fail in Internet Explorer 7 on Windows Vista?

Internet Explorer 7 on Windows Vista has a new security feature called Low Rights Internet Explorer.   Through this feature, the sandbox that the browser operates from has had its rights lowered to the lowest level possible.  As Windows Installer service has the capacity to elevate all the way to Local System, the Windows Installer refuses to accept calls from Low Rights processes (as IE7 now is).

You can detect this case by searching for fragments in the verbose install log.  The first is the initial line in the log that tells you what the calling process is.  This line will contain the binary IExplore.exe and look something like the following (in bold):

=== Verbose logging started: <snip> Calling process: <snip> \iexplore.exe ===

The second is the line in the log that tells you the connection to the server failed.  This line will contain the error code 0x80070005 (Access is Denied) returned from the call:

Failed to connect to server. Error: 0x80070005

Comments