Reading LOGs for MSI Troubleshooting - Advance

Application Packaging
What is LOG file!
A log file is a record of events taking place in the execution of a system and could be useful
to perform log analysis in system troubleshooting
Logs are essential to understand the activities of complex systems in the case of
applications with little user interaction.

VERBOSE LOGGING
Verbose means using more words than necessary.
Verbose logging is a computer logging mode that records more information than the usual
logging mode.

Logging can be enabled by adding keys and values to the registry.

After the entries have been added and enabled, we can retry the problem installation and
Windows Installer which will track the progress and post it to the Temp folder.
The new log's file name is random, but begins with the letters "Msi" and end with a .log
extension.

Command line to locate the Temp folder location as following

cd %temp%

NOTE:
In case of an Active Directory/GPO deployment, there will be no logged on user at the time
the installation occurs. In this case the log file will be created in the "Windows\Temp" folder.

To enable Windows Installer logging we should add the following registry in system

REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmup"

The letters in the value field can be in any order. Each letter turns on a different logging
mode and described as follows

/L [i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] Logfile & If no flags are specified, the default is

'iwearmo.'

v - Verbose output
o - Out-of-disk-space messages
i - Status messages
c - Initial UI parameters
e - All error messages
w - Non-fatal warnings
a - Startup of actions
r - Action-specific records
m - Out-of-memory or fatal exit information
u - User requests
p - Terminal properties
+ - Append to existing file
 x - Extra debugging information.

"*" - Wildcard, log all information except for the v and the x option. To include the v and the
x option, specify "/l*vx".

We can use Group Policy to enable logging:

Click Start->Run->gpedit.msc to start the Group Policy Editor.

Computer Configuration->Administrative Templates->Windows Components->Windows
Installer.
Double-click Logging, and then click Enabled.

Driver Installation LOG:

To enable add the following registry in system

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup
LogLevel (DWORD) = 4800FFFF (hexadecimal).

This will result some logs as follows in Temp folder

setupapi.log
setupapi.app.log
setupapi.dev.log

In case of command line installation on windows installer we can get the log using following
command,

Msiexec /i AppName.msi /l*vx %temp%\AppName.log

Using the "*vx" modifier gives the most detail possible

Verbose logs will contain at least the following information:

 Most errors that occurred during the install including all Windows Installer errors that
generate a user dialog.
 All standard actions executed as well as any custom actions that were executed
 Whether a reboot was requested and completed.
 Values of Installer Properties, including details of any changes.
 The source location of the installation media
 Whether the user cancelled the install.
 If the installation was completed or stopped.
 If the installation was rolled back, this will also be notated in the log
 Client and Server information

Reading Verbose log

Return Values

After each action the Installer will record the 'return value' in the log.
 This is an indicator of the success or otherwise of the action. Possible values are:

Value Meaning
0 Action was invoked, but did not run (not necessarily a bad thing,
maybe there was nothing for it to do)
1 Action was a success
2 Action was cancelled by user
3 An unrecoverable error has occurred
4 The installation was suspended awaiting a reboot

Simply searching for the phrase "Return Value 3" can be a quick way of pinpointing the
errors in a log.
This isn't guaranteed to lead to the source of a problem as some problems are quite subtle,
but its good first step.
It may also break down in localized setup scenarios.

Basic understanding of MSI log files

1. It is a good idea to read the file from the bottom up, as the error will have occurred
nearer the end of the file.

2. You will notice that an MSI log is split into two categories; 'Properties', which are
displayed at the end of the article and 'Actions'.
An Action looks like:
MSI (s) (0C:50) [04:01:06:723]: PROPERTY CHANGE: Adding PackagecodeChanging
property. Its value is '1'.
A Property looks like:
Property(S): IdentityCacheDir = C:\WINDOWS\Microsoft.NET\Framework64\

Focus on the Actions as opposed to Properties. Each action makes up a part of the
installation procedure.

3. To determine which action has failed during the installation, search for the error
generated during installation.
Ex: if error 1603 was displayed during the Application installation, search for 1603 in
Application Install Log.txt

4.When you have located the error, look at the Action that was performed just before the
error. A return value code is written in the log to show if the action completed successfully
or not. One of the following will be displayed:
Return Value 1 – The Action completed successfully
Return Value 2 – The user terminated the action
Return Value 3 – The Action failed (will cause the installation to terminate)

Make a note of which of the actions gives a return value of 3, and record any additional
error information in the log file that may not have been displayed in the on-screen error.

5. The name will reflect what the action is trying to perform.

Ex: The Action CreateUserGroups attempts to create the users used by Application.
 The Action CheckRegForNullDACLs will check registry keys required by Application to ensure they have
the correct access control.

Some scenarios discussed

Could not open Registry Key

The Installer logs a lot of useful information in the form of 'error' codes.
Sometimes these are genuine errors, but often they are simply for information purposes and
do not indicate a real problem.

Full details of all codes can be found in the MSDN Library or the Windows Installer SDK Link.

Ex: take the following entry from the annotated log below:
MSI (c) (C0:6C) [22:17:24:953]: Note: 1: 1402 2:
HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info 3: 2
The SDK defines the code 1402 as: Could not open key: [2]. System error [3].

Feature and component state

Useful item that is included in a verbose log file is the feature and component state values
that are used during the installation.
The following is an example entry in a verbose log file for a feature state, note the areas
highlighted in bold.

MSI (s) (34:A1): Feature: _MainFeature; Installed: Absent; Request: Local; Action:
Local

For a feature state entry in the log file, the entry will be prefaced with Feature: and the
feature name will follow.
In this case, the feature state being displayed is for the feature named _MainFeature.
The Installed entry represents the current state of the feature on the machine.

When the setup package is being in installed for the first time, this value following Installed:
will typically be absent meaning the feature is not currently installed on the machine.

Other values are possible such as Local, Null, Request, etc.

Particular file was or was not copied

This can be useful when trying to determine why a particular file is or is not copied to the
machine.
Ex: line in the log file may look like the following,

MSI (s) (34:A1): Executing op :

FileCopy(SourceName=Global_Vba_VBStockProp_f0.7EBEDD3E_AA66_11D2_B980_006097
C4DE24,DestName=msstkprp.dll,Attributes=0,FileSize=94208,Version=6.0.81.69,Language
=1033,InstallMode=58982400)

MSI (s) (34:A1): File: C:\WINNT\System32\msstkprp.dll; Won't Overwrite; Existing file

is of an equal version
When the setup package is being in installed listed file is already present on target build
with same version and hence installer is giving a warning about it.

Installation encounters an error, rolling back the installation.

We can find rollback information in the log file by searching for Rollback:

Rollback: Registering type libraries

In this example, we can see that the RegisterTypeLibraries standard action is rolling back
the previous work done earlier in the installation when the RegisterTypeLibraries action
executed.

Component state
For a component state entry in the log file, the entry will be prefaced with Component: and
the component name will follow.
MSI (s) (34:A1): Component: Global_Notepad; Installed: Local; Request: Null; Action:
Null

In this case, the component state being displayed is for the component named
Global_Notepad.
The Installed entry represents the current state of the feature on the machine.

When the setup package is being in installed for the first time, this value following Installed
will typically be Absent meaning the component is not currently installed on the machine.
Ex: Installed is set to Local meaning that the underlying component is already installed on
the machine.

There are other values are possible for Installed such as Local, Null, Request, etc.

Property
At the end of the verbose log file is a complete property dump of the property names and
values which can have either client or server properties listed, client only or server only
depending on what operating system the log was generated on and what the user interface
level was set to.

Ex: in a quiet mode installation on Windows NT, 2000 or XP, only the server process is
executed and only server process properties would be displayed at the end of the log file.
The following is an example line found in a verbose log file of a property and its value at the
end of the client part of the installation before switching to the server process.

Property(C): USERNAME = someuser

This line shows the value of the USERNAME property on the client side of the installation
before switching over to the server process was set to someuser.
You can tell this is a client property by noticing the C in the Property (C) notation.

The following is an example line found in a verbose log file of a property and its value at the
end of the server part of the installation just before the installation terminated.

Property(S): USERNAME = someuser

This line shows the value of the USERNAME property on the server side of the installation
was set to someuser.
You can tell this is a server property by noticing the S in the Property (S) notation.
Please note that the USERNAME property in this case has the same value on both the client
and server side, however this may not always be the case for all properties as some
properties may change on the server side due to custom actions changing the property.

The server process performs the actual installation functions such as copying files, writing to
the registry, etc. Most actions appear in two forms in a verbose log file.
The first form is to add it to the installation script that will be ran later on in the installation.

MSI (s) (24:24): Doing action: RegisterTypeLibraries

Action start 13:02:32: RegisterTypeLibraries.
GenerateScript: Registering type libraries
Action ended 13:02:32: RegisterTypeLibraries. Return value 1.

The second form is the actual execution of the action:

MSI (s) (24:24): Executing op:

ActionStart(Name=RegisterTypeLibraries,Description=Registering type
libraries,Template=LibID: )
Action 13:04:42: RegisterTypeLibraries. Registering type libraries

Bootstrapper Logs
Install Shield has a method for creating a log file for the Setup.exe and Update.exe
bootstrappers. You can simply use the /debuglog parameter from the command line when
you run Setup.exe. This command line parameter can be used with the Setup launcher for
Basic MSI, Install Script MSI, and Web projects.

Here it is:

Setup.exe /debuglog

You will notice that a file called InstallShield.log has been created in the same folder as
Setup.exe.

What you must remember here is that, this is only the log file for the Setup.exe
bootstrapper. At least that is what it seems. When you look at this log file, you see that it
doesn’t contain the detailed information available when compared to the log file created as a
result of placing the value in the registry, which was outlined in the previous movie.

There is one more thing to know about the /debuglog command line parameter. You can
also specify the full path to the log file, so it could be created in an entirely different location
from Setup.exe. This is useful if Setup.exe is on a CD-ROM, or any other unwrittable
location. Here is an example of that:

Setup.exe /debuglog”C:\SetupLogFile.txt”
EVENT LOGING
The event-logging service stores events from various sources in a single collection called an
event log.

The installer also writes entries into the event log. These record events such as following:
Success or failure of the installation.
Errors during product configuration.
Detection of corrupted configuration data.

Message ID=Error + 10,000.

Ex: Error number in the Error table for an installation completed successfully is 1707
The successful installation is logged in the Application Event Log with a message ID of
11707 (1707 + 10,000).
10005-The installer has encountered an unexpected error installing this package.
11707 - Installation operation completed successfully.
11708 - Installation operation failed

11728- Configuration completed successfully

Thank you for reading !