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'.
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.
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:
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.
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_006097C4DE24,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 !
