Show the windows installer log что это

Enable Windows Installer logging

Windows includes a registry-activated logging service to help diagnose Windows Installer issues. This article describes how to enable this logging service.

Original product version: В Windows 10 — all editions, Windows Server 2012 R2
Original KB number: В 223300

The registry entry in this article is valid for all Windows operating systems.

Windows Installer logging

Windows Installer can use logging to help assist in troubleshooting issues with installing software packages. This logging is enabled by adding keys and values to the registry. After the entries have been added and enabled, you can retry the problem installation and Windows Installer will track the progress and post it to the Temp folder. The new log’s file name is random. However, the first letters are Msi and the file name has a .log extension. To locate the Temp folder, type the following line at a command prompt:

To enable Windows Installer logging manually, see the following section.

Enable Windows Installer logging manually

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

To enable Windows Installer logging yourself,В openВ the registry by using Regedit.exe, and then create the following subkey and keys:

• Path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
• Type: Reg_SZ
• Value: Logging
• Data: voicewarmupx

The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter’s actual function is as follows for MSI version 1.1:

• 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 — Start up of actions
• r — Action-specific records
• m — Out-of-memory or fatal exit information
• u — User requests
• p — Terminal properties
• + — Append to existing file
• ! — Flush each line to the log
• x — Extra debugging information. The x flag is available only in Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
• * — Wildcard. Log all information except the v and the x option. To include the v and the x option, specify /l*vx.

This change should be used only for troubleshooting and should not be left on because it will have adverse effects on system performance and disk space. Each time that you use the Add or Remove Programs item in Control Panel, a new Msi*.log file is created. To disable the logging, remove the Logging registry value.

Enable Windows Installer logging with Group Policies

You can enable logging with Group Policies by editing the appropriate OU or Directory Group Policy. Under Group Policy, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then select Windows Installer.

Double-click Logging, and then click Enabled. In the Logging box, enter the options you want to log. The log file, Msi.log, appears in the Temp folder of the system volume.

For more information about MSI logging, see Windows Help. To do this, search by using the phrase msi logging, and then select Managing options for computers through Group Policy.

The addition of the x flag is available natively in Windows Server 2003 and later operating systems, on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.

Источник

How Do I Read a Windows Installer Verbose Log File?

Understanding Microsoft Installer Logs

This article explains the main concepts of how to debug a verbose log file created by the Windows Installer.

1. Summary test

During the installation, you may get errors that provide insufficient information about what has occurred. In this case, it is very useful to create the MSI installer log to gather more information about the installation process. This may allow you to resolve the problem yourself or provide vital information to Advanced Installer Technical Support.

By default, logs will contain things such as:

• Errors that occur during the installation including internal Windows Installer errors
• All standard actions executed as well as any custom actions that were executed and their return codes
• Values of Windows Installer Properties, including details of any changes
• The source location of the setup
• If the installation was completed
• If the installation was rolled back
• Whether the user canceled the install

2. Launch the package in debug mode from Advanced Installer

Check the Show run Log option and press the [ Run ] button to run the installer in debug mode. The resulting Windows Installer log will be shown in the “Run Log” Panel.

In the bottom of your Advanced Installer project, the Run and Log panel will be displayed. Useful information can be found as they are displayed in the installation process.

After the installation process is complete you can navigate through the log file using the left tree from the Summary panel.
Easily navigate through:

When testing on other machines, for creating a verbose installation log, you can use a command line which looks like this for MSI packages:

and the following for .EXE packages:

Using the above command line option, the statement will be passed by the bootstrapper to the MSI and the log will be created.

3. Analyzing the log file

The installation of an MSI file is a series of actions. These can be standard actions or custom actions. Each action that is performed has an associated Return Value. The possible return values are:

Looking at the table above, you can see that a return value of 3 is useful. In Notepad, use the Find command and search for value 3. There may be multiple instances of return value 3 in the log file, so how do you determine which caused the installation to abort? When return value 3 is found in the file, start reading upwards from the error in the log file and see what actually cause this.

If a fatal error occurs and the installation aborts, the MSI package initiates a rollback procedure. If the installation is unsuccessful, the installer automatically performs a rollback installation that returns the system to its original state.

By manually searching through the log file, you may encounter a bunch of continuous lines with FileRemove or ComponentUnregister.
The rollback is important because the fatal error that caused the install to fail typically occurs right before the rollback process begins. Also, you can simply search through the log for Rollback.

So, for each standard action or custom action executed, its return value is displayed in the log (e.g. Action ended 16:34:29: InstallFiles. Return value 1.).

In the example above, we see that the return value for the InstallFiles standard action was 1 meaning the action completed successfully. If this action failed and caused an error, a return value of 3 would have been returned and would have caused the rest of the installation to stop and the rollback process would begin which would return the system back to the same state before the installation began.

When the language identifier for the current user is different than 1033 (non-English — United States), you would see its corresponding translation (e.g. Aktion beendet um 16:23:32: InstallFiles. Rückgabewert 1. for UserLanguageID = 1031).

4. Checking the Installation Status of Features and Components

Having the log file you may need to verify that a particular feature, component or file has been installed.

The verbose log includes an entry for each feature and component the installation package may install. The log tells what the state of that feature or component was prior to the installation, what state was requested by the installation, and in what state the installer left the feature or component.
Features and components entries appear in the log as in the following example:

In the verbose log it can be seen that:

• The installation state of the feature and component was absent before running the package
• The installation package requested a local installation of these
• The feature and component were both installed locally

The following table summarizes the possible component or feature states that can appear in the log:

Absent Component or feature is currently installed to run locally.

Component or feature is currently installed to run from source.

Feature is currently advertised. Only features can be advertised, components cannot be.

Component or feature is not currently installed.

Current No request.

Installation requests component or feature be uninstalled.

Installation requests component or feature be installed to run locally.

Installation requests that component or feature be installed to run from source.

Installation requests feature be installed as an advertised feature.

Installation requests feature be reinstalled. Components do not use reinstall state.

Installation requests feature be installed in the default authored install state.

FileAbsent No action is done.

The installer actually uninstalls component or feature.

The installer installs component or feature to run locally.

The installer installs the component or feature to run from source.

The installer installs the feature as an advertised feature.

The installer reinstalls feature.

The installer installs the feature in the default authored install state.

The installer uninstalls component’s files and leaves all other resources of the component installed.