Windows 10 логи установки программ

Windows upgrades used to be something you only had to worry about every few years. But in the Windows 10 era, each twice-yearly feature update is essentially a full upgrade.

When an upgrade or feature update fails, Windows Setup typically doesn’t provide any obvious indication of the underlying problem. But it does keep detailed records of every activity as it works, and if you know how to read setup log files, you can often pinpoint the issue.

These log files are typically saved in a compressed folder called Panther. (The exact location of the Panther folder when an upgrade fails depends on what stage Setup was in when the failure occurred.) If Setup fails and rolls back to the previous Windows version, the log files are stored in a folder called $windows.~bt\Sources\Rollback.

Reading raw log files requires expert skills and specialized tools. A much simpler option is to use a new diagnostic utility, SetupDiag.exe, which is designed specifically to read log files and generate a report identifying the most likely problems.

You’ll find full instructions for using SetupDiag at this page, which also includes a download link.

Copy SetupDiag.exe to its own folder and double-click to identify setup problems on the current PC. The program is smart enough to look in locations where log files are commonly saved, so you don’t need to specify any command-line switches for the tool.

If you’re diagnosing a problem on a different PC, copy the folders containing the log files to a local folder. Then run SetupDiag using the /Mode:Offline switch and the /LogsPath:<folder> parameter, replacing <folder> with the name of the location where you copied the log files.

The output for SetupDiag is a plain text file that is saved in the same folder as the program file. You can open the results file in any text editor, including Notepad, to examine its output and figure out what to do next.

PREVIOUS AND RELATED CONTENT

Need more details about the right way to do a clean Windows 10 install? See these previous articles:

Windows 10 tip: Create a recovery drive

If your Windows 10 PC is operating perfectly right now, great. Take advantage of the opportunity to create a recovery drive so you have a way to perform repairs if something ever goes wrong.

After Windows 10 upgrade, do these seven things immediately

You’ve just upgraded to the most recent version of Windows 10. Before you get back to work, use this checklist to ensure that your privacy and security settings are correct and that you’ve cut annoyances to a bare minimum.

How to install, reinstall, upgrade and activate Windows 10

Here’s everything you need to know before you repair, reinstall, or upgrade Windows 10, including details about activation and product keys.

Windows 10 tip: Repair your Windows 10 installation

Performing a clean install or a reset means you have to reinstall apps and desktop programs and start over with settings and preferences. If you suspect Windows has become damaged, there’s a less drastic solution: Run Setup to repair Windows. Here’s how.

Understanding Microsoft Installer Logs

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

• 1. Summary test
• 2. Launch the package in debug mode from Advanced Installer
• 3. Analyzing the Windows Installer log file
• 4. Checking the Installation Status of Features and Components
• 5. Tips for the Windows Installer log reading
• 6. Check why an upgrade is not performed
  • 6.1 Different UpgradesCode
  • 6.2 Different Installation Type
• 7. Debugging tools

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.

Картинка с сайта: www.advancedinstaller.com

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

• Policies
  • Per-User
  • Per-Machine
• Resources States
  • Feature
  • Component
  • File
• Properties
  • Added
  • Modified
  • Deleted

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

        msiexec /i "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"
      

and the following for .EXE packages:

        mySetup.exe /L*V "C:\log\example.log"
      

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 Windows Installer 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:

    MSI (s) (C8:0C):   Feature:   myFeature; Installed: Absent;   Request: Local;   Action: Local
    MSI (s) (C8:0C): Component: myComponent; Installed: Absent;   Request: Local;   Action: Local
      

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:

In order to check for the features and components states, please search for the
InstallValidate standard action. After the standard action is marked as the
current action which is being executed, on the following lines in the log, the features and
components state is displayed.

5. Tips for the Windows Installer log reading

The verbose log can give you useful information about the installation process and
some explanation about this. For example:

Disallowing uninstallation of component: GUID's component since another client exists

Basically, this can happen if the same components are shared between multiple
packages installed on the same machine. Windows Installer keeps a refcount for the
components and does not allow removing them until all the applications that use them are
removed.

Also, this may happen if you duplicate the project file (saved under a different
name or used the «copy-paste» method). It is strongly recommended not to do this because the
created project will have the same GUIDs (Upgrade Code, Product Code, components ID) as the
source/original project. To avoid this, you must use the Save as template option.

If during an upgrade operation there are files missing from the installation
folder, then search through the log for the following message:

Disallowing installation of component: GUID's component since the same component with higher versioned keyfile exists

If you found it, then this is the reason why your file is not copied on the target
machine.
The upgrade process performs the following actions:

• Detect and completely remove older products. During this operation, the file
  will be removed from the machine.
• Install the new product. The file from the upgraded version will not be
  installed since its component was not marked for installation.

To overcome this behavior, you can enable the Always overwrite existing
file option from the File Operations Tab
of the File Properties.

MSI (s): File: C:\MyApp\MyExe.exe;  Won't Overwrite;  Existing file is of an equal version

This indicates that the installation package will not overwrite the existing file
since is the same version as the one being installed.

6. Check why an upgrade is not performed

When performing an upgrade, you may encounter the case where the old installation
package is left behind and the new package is listed side by side with the old one in the
Programs and Features list.
This may happen if the previous version
of the installation package is not detected.

FindRelatedProducts: Found application: {54737F41-13B0-4B98-9C70-F6C07F471E39}
MSI (c) (E0:4C) [17:14:09:576]: PROPERTY CHANGE: Adding OLDPRODUCTS property. Its value is '{54737F41-13B0-4B98-9C70-F6C07F471E39}'.
MSI (c) (E0:4C) [17:14:09:576]: PROPERTY CHANGE: Adding MIGRATE property. Its value is '{54737F41-13B0-4B98-9C70-F6C07F471E39}'.
 

Action start 17:14:13: RemoveExistingProducts.
RemoveExistingProducts: Application: {54737F41-13B0-4B98-9C70-F6C07F471E39}, Command line: UPGRADINGPRODUCTCODE={C64CA371-69F2-473C-83C1-82B8B313C846}  CLIENTUILEVEL=0 REMOVE=ALL
      

Property(S): OLDPRODUCTS = {54737F41-13B0-4B98-9C70-F6C07F471E39}
      

Action start 16:24:46: FindRelatedProducts.
MSI (c) (10:FC) [16:24:46:131]: FindRelatedProducts: current install is per-user.  Related install for product '{8E38592C-391E-4212-BC31-376A37BB6968}' is per-machine.  Skipping...
          

7. Debugging tools

• Using the Advanced Installer environment
• Utilities as Wilogutl

The Run and Log option from Advanced Installer can help you create a
verbose log and offer you the possibility of a dynamical walkthrough. However, when testing
on different machines, like test machines you get a log file. In this case, you can use the
Wilogutl.exe which can help you read the log.

Wilogutl.exe assists the analysis of log files from a Windows
Installer installation, and it displays suggested solutions to errors that are found in a
log file.
This tool is only available in the Windows SDK Components for Windows Installer Developers.