Dela via


Using logs to troubleshoot installation and configuration problems in the 2007 Office system

Applies To: Office Resource Kit

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this article:

  • Windows Application Event log

  • 2007 Office system Setup logging

  • TCO (GIMME) logging

  • Windows Installer logging

  • Office 2007 OSE logging

This article covers five different logging options that you can use to help troubleshoot problems with installing and configuring the 2007 Microsoft Office system.

Windows Application Event log

The Windows Installer writes entries into the Windows Application Event log to record events such as:

  • Success or failure of the installation, removal, or repair of a product.

  • Errors that occur during product configuration.

  • Detection of corrupted configuration data.

  • Information about which missing components cause a repair of an application.

Review the Application Event log

The Windows Application Event logs are found in the Event Viewer.

When the system automatically initiates a repair and fails, it normally records two events in the Windows Application Event log.

  • The MsiInstaller event 1001 will identify the Product Code, Feature, and Component Code of the keypath that was requested.

  • The MsiInstaller event 1004 will identify the Product Code, Feature, and Component Code of the keypath that was detected as broken.

The MSI of the specified product will be needed to identify the exact resource referenced as the broken keypath. You can find this by looking in either of the following locations:

  • Control Panel | Add/Remove Programs

  • The registry under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{90120000-####-####-0000-0000000FF1CE} hive. Locate the GUID that references the *<Product>*WW.msi.

For information about the numbering scheme for GUIDs, see Microsoft Knowledge Base article 928516: Description of the numbering scheme for product code GUIDs in 2007 Office suites and programs (https://go.microsoft.com/fwlink/?LinkId=128098).

2007 Office system Setup logging

When problems occur with an installation, upgrade, or update of the 2007 Office system, log files are the first place to look to troubleshoot the problem. A lot can be determined by creating a verbose log and then analyzing the Return Code in the log.

In previous versions of Office, you used Windows Installer properties to customize and control the Office installation. In the 2007 Office system, the Setup process is redesigned and logging is affected by:

  • The logging element in the Config.xml file (recommended method).

  • The logging property added by using the Office Customization Tool (OCT).

By default, the 2007 Office system Setup automatically creates log files in the %TEMP% folder. By default, Setup logs everything to memory; therefore, an error from a setup failure or cancellation causes Setup to switch to verbose logging at the point of the failure.

A separate log file is not created for each MSI belonging to the product that is installed. Also, the log file is only available in English with no localization. However, because Windows SharePoint Services is part of Windows and an option in the 2007 Office system installation, Windows Installer logging (which is independent of 2007 Office system Setup logging) continues to support the Windows MUI version of logging.

Configure logging attributes

Setup looks for a copy of Config.xml in the same folder as Setup.exe. If a copy is not found there, Setup uses the Config.xml file that resides in the core product folder for the product that you are installing. If there are multiple products available in the installation source, Setup waits until you specify which product to install before it looks for the copy of Config.xml. Because of this design, the Logging element is only used by Setup when the Config.xml file resides in the same folder as Setup.exe, or if you specify the Config.xml file by using the Setup /config command-line option. If Setup uses the Config.xml file in the product folder, the default standard logging options are used.

To configure the logging attributes for Setup, edit the Config.xml file that you will use for the installation. Use the Logging element in the Config.xml file to specify the type of logging that Setup performs. The following is the syntax used:

<Logging

   Type="Off" | "Standard"(default) | "Verbose" | "Debug"

   Path="path"

   Template="filename.txt"

/>

The following table provides the available Setup logging attributes.

Attribute Value Description

Type

Off

Setup does no logging.

Standard (default)

Setup logs all setup events (command-line properties passed, Config.xml properties passed, patches applied), local installation source (LIS), MSI logging (custom actions, feature states), which of these events succeeded or failed, errors, user choices and UI displayed.

Verbose

Setup writes all installation information to the log file.

Debug

Setup writes all verbose logging information plus additional debugging information. This is useful when identifying a failing piece of code.

Path

path

The fully qualified path to the folder used for the log file. You can use environment variables. The default is %TEMP%.

Template

filename.txt

The name of the log file. If you insert the string * anywhere in the file name, a unique log file is created for each installation performed by Setup. If * is not included and the file name specified already exists, log information is appended to the existing file. A file extension must be specified. The default template is SetupExe(*).log. Environment variables, for example, %COMPUTERNAME%, can be used to create easily identified, unique logs.

You can specify * anywhere in the Template value. Setup inserts a string in that location with the following format:

YYYYMMDDHHMMSSxxx

where:

  1. YYYY = Year

  2. MM = Month

  3. DD = Day

  4. HH = Hour

  5. MM = Minute

  6. SS = Seconds

  7. xxx = a unique string generated by Setup

The Setup.exe log file contains the command line specified for the installation and can, therefore, be used to confirm the proper syntax, spelling, paths, etc.

For more information about how to edit the Config.xml file, see Config.xml file in the 2007 Office system.

Review the Setup log

You will find the log files in C:\Windows\%TEMP% folder if Setup was run by the system. If Setup is run under a user’s account, it will be in the user's %TEMP% folder.

The second to last line of the Setup log will have a Return Code. Common Return Codes are 0 for successful installation, 3010 for reboot needed, 1642 for wrong patch versions, and 1603 for a fatal error. Additional Return Code values can be found in Microsoft Knowledge Base article 290158: List of error codes and error messages for Windows Installer processes in Office 2003 products and Office XP products (https://go.microsoft.com/fwlink/?LinkId=128248).

If you receive an error message during Setup, search for the error number in the log file. Follow these steps to diagnose the issue:

  1. Search the log file for the error number. If you received a 1603 error message, search for "return value 3" (localized) to help determine why the failure occurred.

  2. Read each line up from the line that has the error number. Typically you see a line that failed, with the ultimate result being a Setup error.

  3. If you do not receive an error number, you can also search on the word “Error.”

  4. When no obvious error is generated or logged, search for the string “Note.” A “Note” is an error that is frequently expected (for example, when checking for the existence of a file that was deleted, it would be expected to receive a “File not found” error). Sometimes, however, it is an indication of a true error.

Although a Return Code of 0 normally indicates no problems, occasionally there is no error generated, and yet the installation process does not complete as expected.

For more information about the error codes used by 2007 Office system installations when you enable verbose logging, see Error codes for 2007 Office system installations.

TCO (GIMME) logging

In the multi-MSI model for the 2007 Office system, features are spread across multiple MSIs and each MSI has its own Product Code. To handle this new multi-MSI model, the GIMME API uses Setup.exe (instead of the Windows Installer) to perform Install On Demand (IOD) and Repair On Demand (ROD) actions. Essentially, the GIMME API identifies that an IOD or ROD call is being made, determines which set of MSIs contain the requested option, and then initiates Setup.exe to install it. Logging of these actions is referred to as TCO logging.

The term “GIMME” is not an acronym; it is the term used to describe the API that handles installation request actions made by MSO.DLL. It serves as an extended “wrapper” around the Windows Installer runtime API. Gimme literally translates into "Give Me." In other words, as the application is loading, it is busily trying to pull all of its components together, and verifying that they have all been installed correctly.

Reasons to use a TCO log include the following:

  • Office performs repeated repair.

  • To see the activity before a reproducible crash.

  • Office is not using installed components.

The TCO logs are most useful when the triggering event is NOT in the Application Event log. It is also very helpful in diagnosing why a demand installation happens.

Enable TCO logging

To enable logging for the 2007 Office system, add the following registry settings:

REGEDIT4

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Debug]
"TCOTest"=dword:00000001
"TCODarwinTest"=dword:00000001
"TCOAssertInstalls"=dword:00000001
"TCOTrace"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmupx"
"Debug"=dword:00000007

The Installer does not write information entered on a command line into the log unless the Debug system policy is set. To write command lines to the log, set the Debug system policy to a value of 7.

The log file will be created in the %TEMP% folder as Office.log. The log name cannot be controlled and is overwritten when it becomes full.

Review the TCO log

When TCO logging is enabled, reproduce the issue and review the log file that Office.log created in the %TEMP% folder.

Look for GimmeFile() entries that indicate a file is missing, corrupt, or an incorrect version. Then check further in the log file for that file name to determine if it was successfully installed.

If the file is not successfully installed, check the source path provided for the file to ensure it is valid.

If the issue is related to a Repair On Demand or Install On Demand, look for the related GimmeFile() entries to identify the issue.

Disable TCO logging

To disable (remove) the TCO logging entries for the 2007 Office system, place the following registry settings into an .reg file and use the Regedit.exe –s command:

REGEDIT4

[-HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Debug]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"=-
"Debug"=-

Do not manually delete keypath resources (files or registry values) to trigger a repair. If you suspect that files have been corrupted, enable logging, rerun Office Setup in maintenance mode, and use the Repair Office option.

Windows Installer logging

With the advent of the 2007 Office system multi-MSI installation model, the inefficient Windows Installer logging is secondary to the 2007 Office system Setup logging. However, there are still occasions for which only Windows Installer logging provides the additional level of detail needed.

Because the size of the logs can be significant, you should only enable verbose Windows Installer logging when needed and immediately disable logging once the problem is resolved.

Although use of Windows Installer functions is limited in the 2007 Office system, Setup.exe ultimately relies on the Windows Installer to perform many processes. Because of this, some of the common things that go wrong with the Windows Installer itself might need to be rectified before determining if an actual 2007 Office system problem exists. Before you enable Windows Installer logging, you should check the following:

  • Verify the Windows Installer service is not disabled.

  • Check for system policy restrictions.

  • Clean up the temporary files.

  • Verify DCOM permissions.

Verify the Windows Installer service is not disabled

  1. Go to Start | Run, type services.msc, and press the Enter button.

  2. Double-click the service named Windows Installer.

  3. Check the value in the Startup type field. If it is currently set to Disabled, this is the problem. Change it to manual startup by selecting Manual from the drop-down box.

Check for system policy restrictions

  1. Go to Start | Run, type GPEdit.msc, and press the Enter button.

  2. Open the Computer Configuration | Administrative Templates | Windows Components | Windows Installer tree.

  3. Confirm if any policies that might affect the installation are enabled or disabled; for example, Disable Windows Installer.

Group Policy Object Editor

Group Policy editor

Clean up the temporary files

  1. You can create a simple script/batch file that contains the following lines to automatically empty all the temporary folders, and eliminate errors caused by attempting to delete temporary files that are in use:

    @Echo off
    cd %temp%
    del *.* /Q
    exit
    

    Alternatively, you can manually delete the temporary files by using the following steps.

  2. Empty the %SYSTEMDRIVE%\temp folder.

  3. Empty the %WINDIR%\Temp folder.

  4. Empty the %TEMP% folder.

Verify DCOM permissions

Enable Windows Installer logging

To enable Windows Installer logging, open the registry by using Regedit.exe and create the following path and keys:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Value: 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 for MSI version 1.1 is shown in the following table.

Value Description

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 on 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 for the v and the x option. To include the v and the x option, specify "/l*vx".

Windows Installer logging should be used only for troubleshooting purposes and should not be left on because it will have adverse effects on system performance and disk space. Each time you use Add/Remove Programs in Control Panel, a new Msi*.log file is created.

For more information about how to enable Windows Installer logging, see Microsoft Knowledge Base article 223300: How to enable Windows Installer logging (https://go.microsoft.com/fwlink/?LinkId=128265).

Review Windows Installer log by using the Windows Installer Verbose Log Analyzer

The Windows Installer Verbose Log Analyzer (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.

By default, non-critical errors are not displayed. Wilogutl.exe can be run in quiet mode or with a user interface (UI). The tool generates reports as text files in both the UI and quiet modes. It works best with verbose Windows Installer log files, but also works with non-verbose logs. For more information, see Logging (https://go.microsoft.com/fwlink/?LinkId=128276).

For more information about the Windows Installer Verbose Log Analyzer (Wilogutl.exe), see Wilogutl.exe (https://go.microsoft.com/fwlink/?LinkId=128277) and Microsoft Windows SDK Blog - Windows SDK Hidden Gems: Part 1 (https://go.microsoft.com/fwlink/?LinkId=128278).

To download the Windows Installer Verbose Log Analyzer (Wilogutl.exe), see Microsoft Windows Software Development Kit Update for Windows Vista (https://go.microsoft.com/fwlink/?LinkId=128279).

When run in UI mode, Wilogutl.exe displays the dialog boxes shown in the following table.

Name Description

Windows Installer Verbose Log Analyzer

The Windows Installer Verbose Log Analyzer dialog box enables users to select a log file for analysis:

  • The Open button opens the file in Notepad. The Preview area can be used to verify that the correct log file has been selected.

  • The Analyze button begins log file analysis and displays the Detailed Log File View dialog box.

Windows Installer Verbose Log Analyzer

Windows Installer Verbose Log Analyzer

Detailed Log File View

The Detailed Log File View dialog box displays logged error information. Use the Back and Next buttons to navigate through multiple errors.

To display non-critical errors, select the Show Ignored Debug Errors check box. The installer version on the computer used to run the logged installation is displayed. If the logged installation was run with elevated permissions, the Elevated install? check box is selected and information is provided in the Client Side Privilege Details and Server Side Privilege Details text boxes. The Detailed Log File View dialog box contains the following buttons:

  • States - Show the Feature and Component States dialog box.

  • Properties - Show the Properties dialog box.

  • Policies - Show the Policies dialog box.

  • HTML Log - Show log as annotated HTML file.

  • Save Results - Save report files to specified directory.

  • Error Help - Show installer error message help.

  • Help - Show help for Windows Installer Setup Log Analyzer.

  • How to Read a Log File - Show the log file help document.

Detailed Log File View

Detailed Log File View

Feature and Component States

The Feature and Component States dialog box displays the following states of feature and component columns:

  • The Feature column shows the name for the feature in the installation package.

  • The Component column shows the name of the component in the installation package.

  • The Installed column shows the feature or component's state at the end of the installation.

  • The Request column shows the user's selection during the installation for the feature or component's state.

  • The Action column shows the action taken by the installer for the feature or component.

For more information, see MsiGetComponentState Function (https://go.microsoft.com/fwlink/?LinkId=128284) and MsiGetFeatureState Function (https://go.microsoft.com/fwlink/?LinkId=128285).

Properties

The Properties dialog box shows Windows Installer properties and their values at the end of the installation. You can sort the properties by name or by value by using the following tabs:

  • The Client tab shows properties and values during the client-side portion of the installation.

  • The Server tab shows properties and values during the server-side portion of the installation.

  • The Nested tab shows the properties and values of any concurrent installations.

For more information, see Properties (https://go.microsoft.com/fwlink/?LinkId=128287) and Concurrent Installations (https://go.microsoft.com/fwlink/?LinkId=128288).

Policies

The Policies dialog box displays the system policy set after the installation:

  • A value of 0 (zero) set for the policy means the policy is not enabled.

  • A value of 1 (one) means the policy is enabled.

  • A value of ? (question mark) means the policy value is not recorded in the log.

If you need a policy value that is not in the log, try using Regedit.exe to check the registry keys on the computer from which the installation failed.

For more information about system policies, see System Policy (https://go.microsoft.com/fwlink/?LinkId=128292).

For more information about troubleshooting Windows Installer issues, see Microsoft Knowledge Base article 907749: Basic troubleshooting steps for Windows Installer (https://go.microsoft.com/fwlink/?LinkId=128294).

Office 2007 OSE logging

The Office Source Engine (OSE) logging will only be used when working with Microsoft Product Support and does not normally contain useful information for anyone except a Product Developer. As such, this reference is provided to provide the steps needed when asked to obtain OSE logging by Microsoft Product Support.

When you install the 2007 Office system, Setup uses a system service — the Office Source Engine (Ose.exe) — to create the required local installation source (LIS) by copying the required installation files from the installation point to a hidden location on your computer. Setup then uses this LIS as the source to install the 2007 Office system.

Because the Office Source Engine is a vital piece of installation and maintenance processes, there is a method for logging only those actions performed by the Office Source Engine itself.

The following two examples show errors generated by the Office Source Engine.

CLView error message

CLView error message

Microsoft Office Help Viewer error message

Microsoft Office Help Viewer error message

Enable OSE logging

To enable OSE logging, manually enter the following registry entries:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Delivery\SourceEngine\Settings]
"LogLevel"=dword:00000002
"TraceLevel"=dword:00000003
"TraceFiles"=dword:00000001

Review OSE log

OSE logs are initially created in the installing user’s %TEMP% directory because the Office Source Engine is not yet established as a system service.

Once the Office Source Engine has been successfully installed and registered, logging switches to the %WINDIR%\Temp directory.

When requested, provide this log to Microsoft Product Support for analysis.