Normal logging (MSI Windows Installer Logging)

The installer records errors and events in its own error log. The type of logging that is performed by the installer is determined by the setting of the logging mode. Logging is enabled and the mode can be set by using the following methods:

• The logging mode of an installation launched from the command line can be specified by using the /L option of the Command Line Options. If the logging mode is not specified by using the /L command-line option, the default logging mode will be used.
• The logging mode of an installation process can be specified programmatically by using the MsiEnableLog function or the EnableLog method. If the logging mode is not specified by using the MsiEnableLog function or the EnableLog method, the default logging mode will be used.
• The default logging mode of a particular installation package can be specified by setting the MsiLogging property in the Property table of the package. This property is available starting with Windows Installer version 4.0.
• If the MsiLogging property is present in the Property table, the default logging mode of the package can be modified by changing the value by using a database transform. The default logging mode cannot be changed by using Patch Packages (a .msp file.)
• If the MsiLogging property has not been set, the default logging mode for all users of the computer can be specified by using the Logging policy.
• If the MsiLogging property has been set, the default logging mode for all users of the computer can be specified by setting both the DisableLoggingFromPackage policy and Logging policy.
• If the logging mode has not been specified by the /L option, MsiEnableLog, EnableLog, MsiLogging property, or the Logging policy, then the default logging mode for the package is the same mode that is obtained as setting the MsiLogging property to ?iwearmo?.

Event Logging

Event logging in Windows NT/Windows 2000 provides a standard, centralized way for applications (and the operating system) to record important software and hardware events. The event-logging service stores events from various sources in a single collection called an event log. Windows NT/Windows 2000 also supplies Event Viewer for viewing the logs, and a programming interface for examining the logs.

The installer also writes entries into the Event Log. These record events such as following:

• Success or failure of the installation; removal or repair of a product.
• Errors that occur during product configuration.
• Detection of corrupted configuration data.

If a large amount of information is written, the Event Log file can become full and the installer displays the message, “The Application log file is full.”

Note there is no built-in Event Log on Windows 95 or Windows 98. On these systems, the installer logs the same event information into a file in the %temp% folder called Msievent.log.

The installer may write the following entries in the event log. Starting with Windows Installer version 2.0, all event log messages have a unique event ID. All general errors authored in the Error table that are returned for an installation that fails are logged in the Application Event Log with a message ID equal to the Error + 10,000.

Preventing confidential information from being written in a Log File

On Windows Installer 2.0 and later, one can prevent confidential information, for example passwords, from being entered into the log file and made visible.

• The Installer never writes the information in the Password column of the ServiceInstall table into the log.
• One can prevent the Installer from writing the property that is associated with an Edit Control into the log by setting the Password Control Attribute. The property associated with an Edit Control that has the Password Control Attribute is hidden even if the Debug policy is set to a value of 7.
• One can prevent the Installer from writing a private property into the log by including the property in the MsiHiddenProperties property.

Note   This method can make confidential information entered on a command line visible in the log. When the Debug policy is set to a value of 7, the installer will write information entered on a command line into the log. This makes the property entered on a command line visible even if the property is included in the MsiHiddenProperties property.

One can prevent the information in the Target column of the CustomAction Table from being written into the log by including the HideTarget bit flag in the Type field of the CustomAction table. The value of this flag is 8192 (0x2000).

Logging of Action returns Values (MSI Windows Installer Logging)

The Installer writes the following values into the log when an action returns these error codes.

Logging of Reboot Requests (MSI Windows Installer Logging)

If the InstallValidate action detects the installation of a file in use it displays the FilesInUse Dialog and logs the following information.

Info 1603: The file E:\testdb\Test\CustAct1.dll is being held in use by the following process: Name: test, Id: 137, Window Title: 'Test'.

If the installer detects that it is about to overwrite a file that is in use, it logs the following information.

Info 1603: The file E:\testdb\Test\CustAct2.dll is being held in use.

Info 1903: Scheduling reboot operation: Deleting file [filename]. Must  reboot to complete operation.

The [filename] token may actually contain a path to a file with an .rbf extension. In this case the .rbf file is actually the original file logged by the 1603 message which has been renamed to the .rbf file. The file that’s in use is first renamed with an .rbf extension and then deleted.

To obtain more information about why the installer is attempting to overwrite this particular file, one can use the verbose logging option. Use the INSTALLLOGMODE_VERBOSE value in a call to MsiEnableLog or use the verbose output option of the Command Line Options. This logs the following information.

MSI (s) (D0:F0): File: E:\testdb\Test\CustAct2.dll; Overwrite; REINSTALLMODE specifies all files to be overwritten

The log will include a message such as “Existing file is a lower version” or “Existing file is corrupt (invalid checksum)”