In this article:
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 (http://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:
YYYYMMDDHHMMSS xxx
where:
-
YYYY = Year
-
MM = Month
-
DD = Day
-
HH = Hour
-
MM = Minute
-
SS = Seconds
-
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 (http://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:
-
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.
-
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.
-
If you do not receive an error number, you can also search on the word "Error."
-
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
 Copy Code |
|
|---|---|
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Debug] "TCOTest"=dword:00000001 "TCODarwinTest"=dword:00000001 "TCOAssertInstalls"=dword:00000001 "TCOTrace"=dword:00000001 |
|
| Copy Code |
|
|---|---|
[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
| Copy Code |
|
|---|---|
[-HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Debug] |
|
| Copy Code |
|
|---|---|
[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
-
Go to Start | Run, type services.msc, and press the Enter button.
-
Double-click the service named Windows Installer.
-
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
-
Go to Start | Run, type GPEdit.msc, and press the Enter button.
-
Open the Computer Configuration | Administrative Templates | Windows Components | Windows Installer tree.
-
Confirm if any policies that might affect the installation are enabled or disabled; for example, Disable Windows Installer.
Clean up the temporary files
-
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:
Copy Code@Echo off cd %temp% del *.* /Q exit
Alternatively, you can manually delete the temporary files by using the following steps.
-
Empty the %SYSTEMDRIVE%\temp folder.
-
Empty the %WINDIR%\Temp folder.
-
Empty the %TEMP% folder.
Verify DCOM permissions
-
Check for correct DCOM and system permissions. Sometimes the permissions are not sufficient for Windows Installer to run.
-
For a good description of the issues and the steps to resolve them, see Microsoft Knowledge Base article 319624: "Windows Installer Service could not be accessed" error message when installing application (http://go.microsoft.com/fwlink/?LinkId=128258).
Enable Windows Installer logging
To enable Windows Installer logging, open the registry by using Regedit.exe and create the following path and keys:
| Copy Code |
|
|---|---|
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 (http://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 (http://go.microsoft.com/fwlink/?LinkId=128276).
For more information about the Windows Installer Verbose Log Analyzer (Wilogutl.exe), see Wilogutl.exe (http://go.microsoft.com/fwlink/?LinkId=128277) and Microsoft Windows SDK Blog - Windows SDK Hidden Gems: Part 1 (http://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 (http://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:
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:
Detailed Log File View
|
|
|
Feature and Component States |
The Feature and Component States dialog box displays the following states of feature and component columns:
For more information, see MsiGetComponentState Function (http://go.microsoft.com/fwlink/?LinkId=128284) and MsiGetFeatureState Function (http://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:
For more information, see Properties (http://go.microsoft.com/fwlink/?LinkId=128287) and Concurrent Installations (http://go.microsoft.com/fwlink/?LinkId=128288). |
|
|
Policies |
The Policies dialog box displays the system policy set after the installation:
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 (http://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 (http://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.
Enable OSE logging
To enable OSE logging, manually enter the following registry entries:
REGEDIT4
| Copy Code |
|
|---|---|
[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.
