*
Quick Links|Home|Worldwide
Microsoft TechNet*
Search Microsoft.com for:
Microsoft Windows Server 2003 TechCenter 

The Package Installer (Formerly Called Update.exe) for Microsoft Windows Operating Systems and Windows Components

Updated: March 30, 2005

The Package Installer for Windows and Windows Components

*
On This Page
IntroductionIntroduction
Package Installer OverviewPackage Installer Overview
Installation OverviewInstallation Overview
Advanced Features of the Package InstallerAdvanced Features of the Package Installer
Contents of the Software Update PackageContents of the Software Update Package
File Structure of the Software Update PackageFile Structure of the Software Update Package
Deploying Your Software UpdatesDeploying Your Software Updates
Removing Software UpdatesRemoving Software Updates
Understanding Package Installer Log Files and Error MessagesUnderstanding Package Installer Log Files and Error Messages
Appendix A – Package Installer Versioning and FeaturesAppendix A – Package Installer Versioning and Features
Appendix B – The Update.inf FileAppendix B – The Update.inf File
Appendix C – Detailed Package Installer Process FlowAppendix C – Detailed Package Installer Process Flow
Appendix D – Sample Package Installer LogsAppendix D – Sample Package Installer Logs
Appendix E – Extended Return Codes and Setup API Error CodesAppendix E – Extended Return Codes and Setup API Error Codes
Appendix F – Relevant Knowledge Base ArticlesAppendix F – Relevant Knowledge Base Articles

Introduction

The installation of software updates is typically an automated process that requires little input from you. If you are an information technology (IT) administrator, however, it might be necessary for you to understand the package installer (which was formerly referred to as Update.exe) and the installation process so that you can make informed deployment decisions for your organization.

This paper provides in-depth information about the following:

The files that make up the package installer.

The processes involved in installing software updates.

How a software update package is structured.

Methods you can use to deploy software updates.

How to remove software updates.

How to troubleshoot problems you might encounter while installing software updates.

The information in this paper is current as of March 2005. For updated information about topics covered in this paper, see the Microsoft Web site.

Package Installer Overview

The package installer is used to install software updates for Microsoft® Windows® operating systems and other Microsoft products.

In the past, the package installer was called Update.exe. However, this was not quite accurate because although the package installer does contain a file called Update.exe, it includes other files as well.

Therefore, for the purposes of this document, the term “package installer” refers to the product that includes Update.exe and its supporting files. See Contents of the Software Update Package for more detailed information about the files the software update package contains, including the package installer.

The actual file name of the package is determined by the operating system and the Microsoft Knowledge Base article number that identifies the issues being addressed by the software update.

Software updates for Microsoft Windows 2000 Service Pack 3 (SP3) and later, Windows XP, and Windows Server™ 2003 operating systems include the package installer detailed in this document, which includes the file Update.exe. However, all Windows NT 4.0 and Windows 2000 Service Pack 2 (SP2) and earlier software updates include Hotfix.exe, the predecessor of Update.exe. Other Microsoft products such as Microsoft SQL Server™ and Exchange Server also package some software updates with Update.exe.

Installers for Microsoft products are limited to the package installer and Microsoft Windows Installer (also known as the MSI Installer). For more information about Windows Installer, see the Platform SDK on the Microsoft Developers Network (MSDN).

Installation Overview

Microsoft releases software updates in a software package that is a single, self-extracting, executable file. This file includes Update.exe, the supporting files, and the “payload,” which consists of newer versions of files currently on the system. The package installer updates the files that are currently on the system with these newer versions. The package installer can add new files; delete or replace existing files; add, remove, or update registry keys; and back up files and registry entries that will change before installation.

The following figure provides an overview of the process the package installer uses to install software updates.

Figure 1 - Installation overview

Figure 1 - Installation overview

For a more detailed diagram of the process the package installer uses to install software updates see Appendix C –Package Installer Process Flow.

Installation Process

The following sections describe the steps in the installation process.

File Extraction

When you run the executable file for the package, its contents are extracted into a temporary extraction directory. The location of that directory can be randomly generated by the package installer, or you can specify it as part of a command-line option. If you do not specify a path, the package installer determines which drive on the local fixed disks has the most disk space. It then uses a Windows application programming interface (API) to generate a random name for the extraction directory and places the directory at the root of the drive. For more information, see Extracting Update Package Contents Prior to Deployment.

Analysis and Inventory

The software update installation begins from the extraction directory that was just described. The Update.inf configuration file that is a part of the package installer includes the installation logic and registry changes that are required to install the software update. The package installer identifies which files to install and examines the currently installed versions of those files. If the current version is the same as or newer than the version being installed, the package installer does not update the file. In rare cases where the version numbers are identical, but the file hashes are different, the package installer updates the file.

File Archiving

Before any changes are made to the files or the registry, the package installer archives in an uninstall directory a copy of the files that already exist on the system. (For more information about removing software updates, see Removing Software Updates later in this document.) The uninstall directory also contains Spuninst.exe, an executable file that will remove the update, and Spuninst.inf, a configuration file that includes the logic and registry changes needed to direct the removal of the software update.

File Copy and Cleanup

After the package installer has completed the archiving process, it copies the new files to your computer and makes the appropriate registry changes. After the software update is applied, the package installer runs any final processes listed in the configuration file and logs the installation in Event Viewer. It performs a final cleanup that deletes the temporary directories created during the installation and removes from the registry the list of software updates contained in the service pack. In some cases, you might need to restart the computer to complete the installation.

Registry Entries for Software Updates

When you install a software update, entries are added to the registry that document the installation process. These entries include details concerning which files have been installed, and where to find the archive directory if you should ever want to remove the software updates. These registry entries can be used by Microsoft Baseline Security Analyzer V1.2.1 (MBSA), the QFE check tool, Add or Remove Programs, and other non-Microsoft tools to identify and display the fixes that are currently installed on your system. For more information about the QFE check tool, see Qfecheck.exe Verifies the Installation of Windows 2000 and Windows XP Hotfixes on the Microsoft Web site.

A service pack contains all of the software updates released since the previous service pack or commercially released version of the product. When you install a service pack, entries for updates contained in the service pack are removed from the registry and replaced with one registry entry for the service pack itself.

Note: Removing a service pack will restore any previously installed updates, their registry keys, and their entries in Add or Remove Programs.

Two registry locations are written when a software update is installed. These are commonly referred to as the Updates and Add or Remove Programs keys. The Updates key contains details about all Microsoft software updates. The Add or Remove Programs key contains information about Microsoft software updates that are displayed in Add or Remove Programs. A third registry key, called Hotfix, contains limited information about some Windows software updates.

Note: Because many software update installations no longer populate the Hotfix registry key, do not use this registry key to validate that a software update is installed. It might be installed and not appear in this registry key. Instead, use the Updates registry key.

Software updates are identified by the letters KB or Q, followed by the number of the Microsoft Knowledge Base (KB) article. Software updates released in 2003 and later use a preceding KB; software updates released before 2003 are preceded by the letter Q.

The Updates Registry Key

The Updates registry key lists Windows and other Microsoft software updates installed by the package installer. For service packs and some software updates, only the summary information is provided. For most other software updates, however, the Updates registry key provides file list entries in addition to the summary information.

Summary information

The summary information provided in the Updates registry key includes details about the software update. You can find this information at the following location:

HKEY_LOCAL_MACHINE\Software\Microsoft\Updates\Product\SPX\KB######

Product –The product for which the software update is being installed (such as Windows or SQL Server).

SPX – The number of the service pack (SP) in which the software update is contained. For Windows service packs and non-Windows software updates, this part of the registry key might not be present.The following example shows the registry key you would use to obtain this summary information if you were to install a post-Service Pack 1 (SP1) software update for Windows XP:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB823980

The following table lists and describes the registry key values for the Updates key that can apply to a software update. (Not all of the keys listed in the table will necessarily be populated for every software update.)

Table 1 – Summary Registry Key Values for a Software Update

KeyDescription

PackageName or Description

Name of the software update package.

PackageVersion

Package version number. For more information, see Package Versioning later in this document.

Publisher

Always Microsoft Corporation.

PublishingGroup

Identifies the Microsoft product team releasing the software update. This value is not populated for most updates.

Releasetype or Type

Type of software update (such as an update, update rollup, service pack, feature pack, critical update, security update, or hotfix).

ARPLink

Link to Add or Remove Programs key in the registry.

InstalledBy

User who installed the software update.

InstalledDate

Date the software update was installed.

InstallerName

The installer that was used. This is Update.exe for all examples discussed in this document.

InstallerVersion

Version of the package installer.

UninstallCommand

The path to the removal command for the software update. You can run this command to remove the software update. If the /nobackup command-line option was used to install the software update, however, this entry will be blank. For more information, see Command-line Options later in this document.

File list information

The file list registry key provides a list of the files installed by the software update. You can find the file list key at the following location:

HKEY_LOCAL_MACHINE\Software\Microsoft\Updates\Product\Service Pack\KB######\Filelist

The following example shows the location of the file list registry key that would apply if you were to install a post-SP1 update for Windows XP:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB823980\Filelist

Under the file list registry key are subkeys numbered 0 through n, one for each file installed as part of the software update.

The following table lists subkeys and their descriptions. (Not all subkeys listed will necessarily be populated for every software update.)

Table 2 - File List Registry Subkeys

SubkeyDescription

FileName

Name of the file installed.

WhyIncluded

Why this file was included in the software update.

Affected – The updated file.

Dependent Binary – File or files that the updated file is dependent on.

Supporting – File or files that the software update requires.

Note: This value is not populated for most Windows software updates.

FileVersion or Version

File version.

BuildDate

Date file was built.

BuildCheckSum

File checksum information.

InstallLocation or Location

Where file is installed.

Notes: If the software update type listed in the Summary key is service pack, there will not be a file list because the number of files included in a typical Windows service pack is very large. For a list of the files included in a particular service pack, see the corresponding Microsoft Knowledge Base article for that service pack release.

Some Microsoft software updates will not contain file list information because the software updates are cumulative and would therefore cause the size of the registry to increase with duplicate information.

The Add or Remove Programs Registry Key

Software updates are listed individually in Add or Remove Programs in Control Panel. Add or Remove Programs uses the following registry key to track installed software:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Information for software updates and other installed programs is available in this registry key. Software updates are listed by their Knowledge Base article number, under the entry for the Microsoft product that has been updated.

You can view installed software updates by performing the following procedure.

To view installed software updates

1.

Open Control Panel, and then double-click Add or Remove Programs.

2.

In Add or Remove Programs, you will see a list of all programs and software updates installed on your computer.
On computers running either Windows XP Service Pack 2 (SP2) or later, or Windows Server 2003 Service Pack 1 (SP1) or later, check to ensure that the Show Updates check box is selected.

3.

To view more information about a particular software update, locate its entry in the list in Add or Remove Programs, and click to select it.

Note: Software update packages that were built with a package installer version 5.3.18.6 or later, and that were installed using the /nobackup option will include an entry in Add or Remove Programs, but they will not include a Remove button. Software update packages installed with the /nobackup option and with a package installer version prior to 5.3.18.6 might not even include the entry in Add or Remove Programs. For more information, see Appendix A – Installer Versioning and Features.

The following table lists and describes Add or Remove Programs registry keys. (Some keys listed in the table might not be populated for every software update.)

Table 3 - Add or Remove Programs Registry Key Listing

KeyDescription

Comments

General comments. Not present in all updates.

DisplayName

Text displayed in the Add or Remove Programs entry.

DisplayVersion

Version of the update installed. See Package Versioning for more information.

Helplink

Link to Microsoft Knowledge Base article.

NoModify

Determines whether the Change button appears in Add or Remove Programs.

NoRemove

Determines whether the Remove button appears in Add or Remove Programs.

NoRepair

Determines whether the Repair button appears in Add or Remove Programs.

ParentKeyName

Registry key name of the application in Add or Remove Programs that the fix applies to. Also used to differentiate between Windows and non-Windows updates.

ParentDisplayName

Used by Add or Remove Programs when the parent listed in ParentKeyName is not found. This name is used to create a virtual entry if necessary. This is necessary for the operating system, which has no parent in Add or Remove Programs.

Publisher

Value is Microsoft Corporation for all software updates published by Microsoft.

RegistryLocation

Registry key for the software update itself.

ReleaseType

Indicates type of software update.

UnInstallString

Path to software update removal program.

URLInfoAbout

URL under the Publisher link in the Support Information dialog box.

The Hotfix Registry Key

The Hotfix registry location was previously used to record information about the software updates installed. The Hotfix registry location is no longer populated for many software updates.

Registry location

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Hotfix\KB######

The following table lists and describes Hotfix registry keys and their values.

Table 4 - Hotfix Registry Key Values

KeyDescription

Backup Dir

Directory where the backup files are stored.

Comments

Optional comments.

Fix Description

Update type and Knowledge Base article number.

Installed By

No longer used. See previous discussion of the Updates registry key.

Installed On

No longer used. See the previous discussion of the Updates registry key.

Service Pack

Identifies the service pack in which the software update is projected to be included.

The Pending File Renames Registry Key

When you install a software update on a computer that is running, some of the files targeted for update might be in use. For some software updates, the package installer automatically shuts down any running services so the affected files can be updated. If a software update packaged with package installer version 6.1.22.0 or later is installed in attended mode, which requires your interaction, you might receive a message that asks you to close one or more applications so the software update can be applied without requiring you to restart your computer. For information about how to determine the version of the package installer, see Appendix A – Package Installer Versioning and Features.

If you do not close the application, or the service cannot be shut down, the file cannot be replaced or deleted at that time. When this occurs, the updated version of the file is added to the Pending File Renames (PFR) queue, a registry key that tracks files that must be replaced or deleted when the computer is restarted. You can find this registry key at the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\

The value is PendingFileRenameOperations, which is of type REG_MULTI_SZ.

When you restart the computer, and the files are no longer in use, they are either replaced with the updated versions contained in the package, or they are deleted. The PFR registry key is removed when the file update is completed.

If a PFR operation is required, the installation is not complete until you restart the computer.

Important: If you are installing a security update and a restart is required, the security update might not take effect until you restart the computer. This can leave your computer in an unprotected state. To help maintain the security of your computer, be sure to restart it as soon as the security update installation is complete.

For more information about the PFR registry key, see article 202071, “PRB: Troubleshooting MoveFileEx() MOVEFILE_DELAY_UNTIL_REBOOT,” in the Microsoft Knowledge Base.

Registry Keys to Determine Restart Status

You can examine certain registry locations to determine whether you must restart your computer in order for a software update installation to be complete and to take effect. You can use Regedit to examine the Pending File Rename registry key described in the previous section for this purpose. However, this is not a reliable method because, even if this key is missing or empty, you might still need to restart your computer before the installation of a software update is complete.

In package installer versions 6.1.22.0 and later, there is a new global restart indicator key that makes it easier for you to determine whether a restart is required. When a restart is required after installing or removing a software update, flags are set in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile

You can also use Regedit to examine this key.

The following table lists and describes the flag values within this key.

Table 5 – Global Restart Registry Key Values

Flag ValueDescription

0x00000000 (0)

No restart is pending.

0x00000001 (1)

A software update removal is pending a restart.

0x00000002 (2)

A software update installation is pending a restart.

0x00000003 (3)

Both an installation and a removal are pending a restart.

If this key is missing, a restart is not pending. However, only software updates that include package installer version 6.1.22.0 or later will set these flags, so this registry key might not always accurately indicate whether a restart is pending.

Advanced Features of the Package Installer

This section reviews some of the advanced functions available in the package installer. These features include application error reporting, service pack file caching, automatic recovery, hotpatching, hotfix migration, blocklists, and branching.

Application Error Reporting

Application Error Reporting is included in package installer versions 5.4.15.0 and later.

With your consent, the package installer sends information to Microsoft if your system fails or stops responding. Microsoft uses this information to improve its software products. All of the information collected through this process is handled according to the policies detailed in article 283768, “Description of the end user privacy policy in application error reporting,” in the Microsoft Knowledge Base.

Windows Service Packs and Optional Components

When you install a Windows service pack, a new baseline is created because many of the operating system files are updated. During a service pack installation, the package installer creates a directory at %WINDIR%\ServicePackFiles for all of the service pack files. The package installer then puts that path in the following registry key:

HKLM\Software\Microsoft\Windows\Currentversion\Setup\servicepacksourcepath

Windows File Protection, which replaces corrupted or missing operating system files, and the Windows Optional Component Manager, which installs Windows components, both use Setup API functions to find the necessary files to install.

When Setup API is asked to retrieve a system file, it follows a sequence to find the file. It first looks for the file in the dllcache directory (%WINDIR%\system32\dllcache). It then looks in the driver cache (%WINDIR%\Driver Cache), and next in the ServicePackFiles directory. The last place it looks is the original installation operating system CD-ROM.

Because the dllcache directory is emptied periodically, the ServicePackFiles directory is the location that holds the newest versions of the operating system files that are not currently in use on the computer. For example, if you install Internet Information Services (IIS) after installing a Windows service pack, and the dllcache was emptied, the Optional Component Manager will look in the ServicePackFiles directory to get the latest files for IIS. The other option would be to retrieve the files from the original operating system CD-ROM, which would have older versions of those files that do not contain any of the updates included in the service pack.

The % WINDIR %\ServicePackFiles directory is created only for a service pack installation, not for other types of software updates.

Automatic Recovery

The package installer used for Windows XP Service Pack 2 (SP2) includes a new automatic recovery process for service pack installations. This version of the package installer (5.5.1005.0) sets indicators in the registry to execute an automated removal of the service pack if the computer restarts unexpectedly while the service pack is being installed.

This mechanism restores the previous service pack level by using saved backup information and a text file that contains file copy information. You can use a similar mechanism to remove software updates manually through the Recovery Console. See To perform a manual removal through the recovery console for details.

The process used for automatic recovery has greatly reduced the potential for startup problems that can result from partial service pack installation. When the computer restarts during an installation of Windows XP SP2, Session Manager starts the recovery process. A message appears stating that Setup was interrupted, and that the prior configuration will be restored. This screen and its message are shown in the following figure.

Figure 2 – Restoring prior configuration screen

Figure 2 – Restoring prior configuration screen

As part of this process, the SetupType value in the registry key HKLM\System\Setup is changed to 2. This causes the operating system Setup program to run the command in the CmdLine value of that key, which points to the Spuninst.exe file. This, in turn, triggers the addition of a value to the registry location

HKLM\Software\Microsoft\Windows\Current Version\RunOnce, which provides the informational prompt shown in the following figure.

Figure 3 – Automatic recovery prompt

Figure 3 – Automatic recovery prompt

After the computer restarts, it should be functional, but it might be in an unstable state. As a result, the prompt indicates that you should uninstall the partially installed service pack through Add or Remove Programs in Control Panel. For details, see Removing Software Updates.

Hotpatching

Hotpatching, also known as “in-memory patching,” is designed to reduce server downtime when you install updates onto computers that are running 32-bit versions of Windows Server 2003 with Service Pack 1 (SP1). The goal is to enable the installation of software updates without having to restart your servers.

If a file is in use when you install a software update, it usually cannot be replaced with the new version until the computer restarts. Hotpatching, however, allows for the automatic insertion of code from a simple software update into a running process. This means that system files can be updated while they are in use.

When a file is hotpatched, the new version of a function from the software update is loaded into memory, and a single line of code in the original function is changed to branch to the new version. After the jump to the new function is injected, each subsequent execution of the function points to the new version. (The next figure illustrates this process.) Applications that are in the middle of a call to the function before the software update was applied are allowed to terminate normally.

Hotpatching is complemented by the usual software update process in which the file on disk is replaced, allowing future spawns of the affected process to contain the software update. Hotpatching is possible only for software updates that provide isolated fixes for individual functions; it is not compatible with software updates that update several interdependent functions. The Knowledge Base article that describes a particular software update will clearly indicate that it is compatible with hotpatching if this is the case.

Figure 4 - Hotpatching overview

Figure 4 - Hotpatching overview

Not all Windows Server 2003 software updates support installation through hotpatching. See Deploying Hotpatches section for more details.

Using Blocklists to Overwrite Installed Software Updates

Some software updates (typically hotfixes) are released near the end of a service pack release cycle and are not included in the service pack. The released service pack files might contain other changes not included in the versions installed by the software updates. A service pack installation will not overwrite these files because the software update files will have a higher version number than the service pack files. These software updates are known as “blocklisted” software updates. They are listed in the Updtblk.inf file that is included with the service pack package. Blocklisted updates are repackaged after the release of the service pack so they can be installed with the new service pack. To identify which software updates are on the blocklist, see the service pack release notes document in the Microsoft Knowledge Base, or examine the Updtblk.inf file located in %WINDIR%\inf\ after the service pack is installed.

You should download updated versions of those software updates from Microsoft, and then use the package installer’s built-in chaining functionality to combine the software update installation with the service pack installation. See Integrated Installation for details.

During a service pack installation, you will receive the following message if there are blocklisted updates installed on your computer:

This Service Pack contains files that are missing some of the fixes which were previously installed on this computer. To prevent possible problems, these files will not be installed by the Service Pack.

In order to have these fixes contained in both the Service Pack and the previously installed hotfixes, you must obtain and install the updated versions of the following hotfixes prior to or following the installation of the Service Pack. These hotfixes are also listed in the svcpack.log file.

If a pre-service pack release version of the blocklisted software update package is installed on a computer that is running the new service pack, you will receive the following message:

Setup cannot install this hotfix because one or more of its files are out of date. Please download and install the latest version of fix KB######.

You should download the new version of the update package from Microsoft.

This functionality just described was used for Windows 2000 software updates that were released just prior to the release of Windows 2000 Service Pack 3 (SP3) and Windows 2000 Service Pack 4 (SP4). Currently there are no blocklisted software updates for Windows XP or Windows Server 2003, but this might change with future service pack releases for those products.

For more information about blocklisted updates, see the following Microsoft Knowledge Base articles:

810077 How to Suppress the Warning That Appears When You Install SP3 on a Computer on Which Previous Versions of Post-SP3 Hotfixes Are Installed

309601 Some Windows 2000 hotfixes may cause a conflict with Service Pack 3 (SP3) for Windows 2000

Migration

The migration feature ensures that software updates installed prior to a service pack installation do not need to be reinstalled after the new service pack is installed. This functionality was used for some Windows XP software updates that were released prior to the release of Windows XP SP2. However, this approach has been retired in favor of branching, which is described in the next section.

These pre-SP2 software updates were released as “dual-mode” packages. They contained two versions of the software update for the two different operating system levels-- one for Windows XP, and one for Windows XP with SP1. Dual-mode packages include an additional supporting file for the package installer, Xpsp1hfm.exe. This supporting file determines which version of the software update to install, and caches the version for the next service pack level in %WINDIR%\$xpsp1hfm$\KB######\. When the new service pack is installed, the package installer retrieves the software update files for the new service pack level from this cache directory and installs them. The migration operations are logged to %WINDIR%\xpsp1hfm.log. The migration makes it unnecessary to reinstall the fix after the service pack is applied.

For information about dual-mode updates for Windows XP, see article 328848, “Description of dual-mode hotfix packages for Windows XP,” in the Microsoft Knowledge Base.

For information about the directory structure used for migration, see Contents of the Software Update Package later in this document.

Branching

The multi-branch-aware structure, also known as “branching,” supports multiple installation scenarios in the same package, much like the dual-mode installation mentioned in the previous section. Branching is used for some Windows XP software updates released prior to Windows XP SP2, all Windows XP software updates released after Windows XP SP2, and all software updates for Windows Server 2003 operating systems.

Besides the scenario described in dual-mode installations, multi-branch-aware software updates can update different development environments of the same service pack level of the operating system. Between service pack releases, Windows software updates are released from two different development environments, also known as “branches.”

Software updates released through Microsoft Windows Update address widespread critical issues. These software updates are created in the developmental environment known as the General Distribution Release (GDR) branch.

Hotfixes are software updates that address unique customer issues. They are distributed by Microsoft Product Support Services. Hotfixes are created in the developmental environment known as the Hotfix branch, which is also known as the QFE (“quick-fix engineering”) branch. The Hotfix branch also includes software updates from the GDR branch. The following figure illustrates these two branches.

Figure 5 – Updates to a file in multiple branches

Figure 5 – Updates to a file in multiple branches

Having two separate branches helps minimizes the risk when you receive software updates from Windows Update. It does so by making it possible for you to receive software updates that address only critical issues (such as security issues) and does not include additional changes.

Multi-branch-aware software update packages contain multiple versions of the software update. These versions correspond to the GDR and QFE branches for each service pack level. During installation, the package installer uses supporting .inf configuration files to determine whether the files to be replaced are from the GDR branch or the QFE branch. See Contents of the Software Update Package for details. The package installer then installs the appropriate version of the software update. If the version installed is from the branch with fewer cumulative changes (in this example, it would be the GDR branch), the package installer caches the more cumulative versions (in this example, the QFE version) in %WINDIR%\$hf_mig$\KB######\. If a hotfix for one of those files is installed later, the package installer will “migrate” the previously updated files to the QFE versions in order to maintain consistency.

In addition, versions for a higher service pack level (if such versions exist) are also cached so that the software updates can be reapplied when the computer is updated to the next service pack. After the service pack installation, the package installer checks the cache directory at %WINDIR%\$hf_mig$\KB######\ to determine whether there are any software updates to be migrated to the new service pack level. If there are, the package installer installs these software updates from the cache. This method does not use the Xpsp1hfm.exe file that is used in dual-mode packages described previously. Instead, this functionality is built into the package installer itself.

The package installer will “reverse migrate” a software update if the new service pack is removed. It will reapply the original update files for the previous service pack level as part of the service pack removal process.

For more information about branching, see article 824994, “Description of the contents of Windows XP Service Pack 2 and Windows Server 2003 software update packages,” in the Microsoft Knowledge Base.

For information about the directory structure used for migration, see Contents of the Software Update Package.

Fixes from both branches are included in the subsequent service pack, which undergoes extensive testing before public release.

Contents of the Software Update Package

A software update package includes the installer file (Update.exe), supporting files, and the “payload”--the file or files that make up the actual software update. This section discusses the files and directory structure of a software update package.

Package Installer Files

This section describes the core files and the supporting files that are included in the package installer.

Core Package Installer Files

These files are part of the core package installer and change only when a new version of the package installer is released. These files do not change across packages that are built with the same version of the package installer.

The core package installer files are as follows:

Update.exe

Updspapi.dll

Spuninst.exe

Spupdsvc.dll

Sprecovr.exe

Package Installer-related Files

These files support the core files; however, they are not all included in every installer package.

The following table lists all package installer-related files.

Table 6 – Package Installer-Related Files

FileDescriptionPackages That Contain This File

Branches.inf

Defines the hierarchal relationship between branches. See .inf Files for more details.

Only Windows XP and Windows Server 2003

Custom.dll or Spcustom.dll

Contains functionality not natively provided by the package installer. The name might vary by Microsoft product. The Custom.dll used by Windows is called SPCustom.dll. See Custom.dll for details.

All

Empty.cat

Security catalog required for software update removal.

Windows 2000 only

Eula.txt

End-user licensing agreement displayed during attended (interactive) installation.

All

KB######.cat

Security catalog. (Each update has a unique catalog file.)

All

Spmsg.dll

Used by the package installer to record events to Event Viewer.

All

Sprecovr.exe

Performs system recovery if a failure occurs during a Windows service pack installation.

Windows XP SP2
Windows Server 2003 SP1 (Applies only to service pack packages.)

Spupdsvc.exe

Windows service that runs after a reboot if the installation requires processes to be executed after a reboot.

All packages with [ProcessestoRun.AfterReboot] or [ProcessestoRunAfterUninstallReboot] sections in Update.inf

Spuninst.exe

Core file used to remove software updates.

All

Updspapi.dll

Supporting file for the package installer that contains the necessary Setup API functions.

Package installer versions 6.1.22.0 and later

Update.exe

Core of the package installer.

All

Update.inf

Main configuration file that drives the installation. Provides such things as a list of files to install, installation locations, registry keys to update, string information to display during installation, event log names and location, and external processes to run as part of installation process. See .inf Files for details.

All

Updtblk.inf

Identifies blocklisted software updates. See Using Blocklists to Overwrite Installed Software Updates for details.

Some service pack packages and some other software update packages

Update.ver

Describes the version, size, and hash information for the newer versions of the files currently on the system.

All

Update_<branch-SPLevel>.inf

Replaces Update.inf in a multi-branch-aware package, and provides configuration information for installation from the specified branch. Each branch and service pack level to which the software update applies will have its own Update_<branch>.inf file. See .inf Files for details.

Windows XP SP2
Windows Server 2003 software update packages

Updatebr.inf

Defines the default branch, provides pointers to the Update.inf files and the common setup files. See .inf Files for details.

Windows XP SP2
Windows Server 2003

Xpsp1hfm.exe

Determines the appropriate version of the fix to install based on the operating system service pack level, and then launches the package installer.

Windows XP dual-mode packages only (prior to Windows XP SP2)

Custom.dll

The custom.dll file provides specific functionality not native to the package installer. The name of the Custom.dll can vary from one Microsoft software update package to another. Custom actions can be invoked at different times during the installation.

.inf Files

The .inf files provide the package installer with configuration details for the installation. This allows for customization of the installation procedure, depending on the software update being installed.

Update.inf

The Update.inf file is the core configuration file for the package installer. All packages include this file. It takes a modified name for multi-branch-aware installations. See Multi-Branch-Aware .inf Files for details.

The Update.inf file structure is extensible. Update.inf provides the package installer with target operating system version information, files to update, registry entries to modify, and external processes to run during installation. Common sections found in most Update.inf files are listed in Appendix B - The Update.inf File. The syntax of the .inf files used by the package installer is very similar to those documented in Creating an INF file in the Microsoft Developers Network (MSDN) library.

Multi-Branch-Aware .inf Files

To support branching, multiple versions of the Update.inf file are required, which are named Update_<branch-SPLevel>.inf. There are also two additional required .inf files, Updatebr.inf and Branches.inf, which identify the branches and their hierarchy. Installation packages for Windows XP SP2 and Windows Server 2003 contain these files.

Branches.inf

The Branches.inf file defines the known branches and the branch hierarchy. It facilitates comparison of file branches by describing their relationships to one another. This file is also used when you must migrate from an earlier version of a hotfix to a later version. Branches.inf is copied to the %WINDIR%\inf\ directory on the computer during installation. When a later version of this file is released with another software update, the one on the computer will be replaced.

Updatebr.inf

The Updatebr.inf file defines the common files and their location in the multi-branch-aware file structure. It also identifies the default branch in the hierarchy. In a multi-branch-aware installation, there are multiple Update.inf files shipped with the software update to accommodate the need for different file sets, based on the branch being installed. One of the critical uses for the Updatebr.inf file is to link the branch with the appropriate Update.inf file.

File Structure of the Software Update Package

When the contents of the software update package have been extracted, they are placed in subdirectories under the extraction folder on the computer’s hard drive. This directory contains the package installer, the supporting files mentioned previously, and the payload.

There are three possible directory structures available: standard, dual-mode, and multi-branch aware.

The structures and the packages found in each operating system are listed in the following table.

Table 7 – Software Update Package Directory Structure by Operating System

File StructureWindows 2000Windows XPWindows Server 2003

Standard

X

X

N/A

Dual-mode

N/A

X (pre-Service Pack 2)

N/A

Multi-branch aware

N/A

X (SP2)

X

Standard Package File Structure

The standard directory structure is the simplest. Files are placed in either the root directory where they were extracted, or in the Update directory.

This is illustrated in the following figure.

Figure 6 - Standard file structure

Figure 6 - Standard file structure

The following table shows each file’s location in the directory structure:

Table 8 - Standard File Structure

DirectoryFiles

Root

Empty.cat
Spuninst.exe
Spmsg.dll
Spupdsvc.exe
Payload files

Root\Update

Custom.dll
Eula.txt
KB######.cat
Update.inf
Update.exe
Updtblk.inf
Update.ver
Updspapi.dll

Dual-Mode Package File Structure

The file structure for the dual-mode installation is more complex than the standard installation and directory structure just described. It carries additional files to service two versions of the same operating system. For example, with this structure, one software update could service computers running Windows XP without SP1 as well as computers running Windows XP with SP1 (see the figure later in this section).

Dual-mode installations are available only for Windows XP software update packages prior to the release of Windows XP SP2. This file structure has been retired in favor of the multi-branch-aware file structure, which is described in the next section.

For example, if you were to perform a dual-mode installation on computers that are running Windows XP as well as computers that are running Windows XP with SP1, the dual-mode installation files would be placed in the following directories:

Root – Contains Xpsp1hfm.exe, the file that determines which service pack level version of the software update files to install.

Common – Contains common installer files used by both versions.

SP1 – Contains newer versions of the files currently on the system and supporting files for installation on Windows XP without a service pack.

SP2 – Contains the newer versions of the files currently on the system and supporting files for installation on computers that are running Windows XP with SP1.

The following figure illustrates the file structure for a dual-mode installation.

Figure 7 – Dual-mode file structure

Figure 7 – Dual-mode file structure

The following table shows the location of the files in the directory structure.

Table 9 – File Location in a Dual-mode File Structure

DirectoryFiles

Root

Xpsp1hfm.exe

Root\Common

Custom.dll
Eula.txt
Spuninst.exe
Spmsg.dll
Update.exe
Update.ver

Root\SP1

Payload files

Root\SP1\Update

KB######.cat
Update.inf
Update.ver

Root\SP2

Payload files

Root\SP2\Update

KB######.cat
Update.inf
Update.ver

Multi-Branch-Aware Package File Structure

When the files from a multi-branch-aware software update are extracted into the root directory, an Update subdirectory and multiple subdirectories for the relevant branches are created. See Branching for more details about multi-branch-aware software update packages.

The first part of the directory name reflects the product milestone (for example, RTM is the original, commercially released version of the product; SP1 means Service Pack 1; and so on). The second part of the directory name identifies the branch or development environment from which the update was built.

In the example illustrated in next figure, the files are placed in one of four directories:

Root – Contains core installer files Spuninst.exe and Spmsg.dll.

Update – Contains common installer and supporting files.

RTMQFE – Contains the QFE branch version of the newer versions of the files currently on the system and supporting files.

RTMGDR – Contains the GDR branch version of the newer versions of the files currently on the system and supporting files.

Figure 8 - Example of multi-branch-aware file structure

Figure 8 - Example of multi-branch-aware file structure

The following table shows the location of the files in the directory structure.

Table 10 - Multi-Branch-Aware File Structure Location

DirectoryFiles

Root

Spuninst.exe
Spupdsvc.exe
Spmsg.dll

Root\Update

Branches.inf
Custom.dll
Eula.txt
KB######.cat
Update_rtmgdr.inf
Update_rtmqfe.inf
Update.exe
Updatebr.inf
Updtblk.inf
Update.ver
Updspapi.dll

Root\RTMGDR

Package files

Root\RTMQFE

Package files

Deploying Your Software Updates

Deployment refers to the method you use to install a software update to individual computers. This section discusses package installation types, package versioning, user rights required to install a package, command-line options, and deployment options and methods.

Package Installation Types

Software update packages are built with three installation types that are distinguished by how they obtain their payload files: self-contained, express, and network. Regardless of how the content is obtained, the package installer follows the same process to complete the installation. This is outlined in the Basic Installation section previously described.

Self-contained Installation

The self-contained installation, also referred to as a standard or full installation, is simple—all of the files that must be installed on the computer as part of the software update are included in the package. See Contents of the Software Update Package for details.

The package installer determines what needs to be installed on the computer, based on file versions, and then proceeds with the installation. This is the preferred installation for large installations behind firewalls where individual computers do not have access to the Internet. It is also preferred where there is a policy prohibiting the installation of software updates from the Internet. Hotfixes obtained from Microsoft Product Support Services, and software updates obtained from the Microsoft Download Center and the Microsoft Windows Update Catalog Web site provide self-contained software update packages for Windows.

Express Installation

The express installation package does not carry the entire contents of the software update, so it is much smaller than the full installation package. Instead, the express installation process generates a list of files that are installed based on the versions currently on the computer, and retrieves those files from the Windows Update Web site. Only the necessary files are downloaded and installed. In addition, the package installer can download only the changes to a file, and then synthesize the updated version of the file from the one currently installed on the computer. These packages use a technology called Binary Delta Compression (BDC). Currently, express installation packages are available only from the Windows Update Web site.

For more information about express installation packages and BDC, see Binary Delta Compression on the Microsoft Web site.

Network Installation

The network installation method discussed in the Deployment Methods section of this document has the benefit of reducing the amount of working disk space that the package installer requires. When the content is placed in a network location, the package installer uses that location as its cached working space instead of using the hard disk on the local computer. This can be very helpful for environments where storage space on the local computer is limited.

During a network installation of a Windows service pack, the ServicePackFiles folder is not created on the local computer because the package installer expects the computer to have access to that network shared folder in the future.

The following registry key points to the network shared folder.

HKLM\Software\Microsoft\Windows\Currentversion\Setup\servicepacksourcepath

Setup API functions use this location to retrieve files needed for Windows File Protection or Optional Component Manager. For more information, see Windows Service Packs and Optional Installed Components.For links to network installation resources, see Windows Deployment Guides.

Package Versioning

In addition to the individual versions of files that are included during a software update installation, versioning is applied to the software update package itself. This is useful when an update is re-released. This is because the version number distinguishes the previous and current software update packages even if the Knowledge Base article number is the same for both versions. After installing the software update, the package version number is retained in the registry.

For more in formation, see Registry Entries for Software Updates.

The following procedure demonstrates the steps to follow to determine the version of a software update package released July 2004 or later.

To determine the version of a software update package released July 2004 or later

Right-click the software update package file whose version you want to check, click Properties, and then click the Version tab.

The package version information is listed in File Version.

For information about how to determine package installer version, see Determining the Package Installer Version in Appendix A of this document.

To view software update package version for packages released before July 2004, extract the package contents and view the Update.inf file. For more information, see Extracting Software Update Package Contents Prior to Deployment.

You can view the software update package version information in the [Strings] section under the key name BUILDTIMESTAMP.

Note: Version information does not appear in the [Version] section of Update.inf.

For software update packages released before July 2004, the version number is a concatenation of the date and time that the package was built. This versioning information helps you mathematically determine which version of an update is the most recent.

The following table provides an example of a legend you could use to translate versioning information for a package with version 20030102.120145, a software update package released before July 2004.

Table 11 –Software Update Package Versioning for Packages Released Before July 2004

DigitsDescriptionExample Values

1 – 4

Year that the update was built

2003

5, 6

Month that the update was built

01

7, 8

Day of month that the update was built

02

9, 10

Integer representing the hour of the day

12

11, 12

Integer representing the minute of the day

01

13, 14

Integer representing the seconds of the day

45

Deployment Modes

Software updates can be deployed in attended or unattended mode, depending on the level of the interaction you want to have with the computer while the installation is taking place. Installations for both modes can be performed with a combination of command-line options. See Command-line Options for more details.

Attended Mode

Attended mode is the typical installation method for an individually managed environment that requires your interaction. The Software Update Installation Wizard is launched. You must then accept the end-user license agreement, determine whether to back up files, and if so, where to back them up. You must restart the computer if necessary at the end of installation.

Unattended Mode

Unattended mode enables the automated installation of software updates and does not require your interaction. If you specify the /quiet command-line option, the installation can be completely silent, with restarts, if they are needed, occurring automatically. Windows Update uses the /quiet option to install packages onto its client computers. You can also specify the /passive command-line option. This provides you with a progress bar and warns you that a restart will occur if one is necessary.

There are several ways to accomplish unattended installation. These include developing custom batch installations by using the command-line options previously mentioned, or using automation software, such as Systems Management Server (SMS) or Windows Update Services, to install software updates on all computers across a network.

If you install a software update manually or run your installation from Windows Update, the installation runs in the user context. You should be an Administrator with the user rights detailed in the next section, Required User Rights. If a software update is deployed through SMS or Windows Update Services, the package installer is spawned in the System context because the parent process runs as a service.

Required User Rights

Package installer versions 5.4.1.0 and later require you to be an Administrator with certain user rights in order to install the software update. These user rights are listed and described the following table.

Table 12 – User Rights Required to Perform an Installation

Group Policy Object Display NameRequiredDescription

Restore files and directories

Required

You must have this user right to perform restore operations. This user right lets you set any valid user or group security identifier (SID) as the owner of an object.

Back up files and directories

Required

You must have this user right to perform backup operations.

Take ownership of files or other objects

Required

You must have this user right to take ownership of an object without being granted discretionary access. This user right allows the owner value to be set only to those values that the holder may legitimately assign as the owner of an object.

Manage auditing and security log

Required

You must have this user right to perform many security-related functions, such as controlling and viewing audit messages. This user right identifies its holder as a security operator. This is required to restore the security access control list (SACL) correctly after replacing files.

Shut down the system

Not required, but preferred

You must have this user right to shut down the computer. Some software updates require that the computer be restarted. If this user right is not available, the user must contact an Administrator with that user right to restart the computer if it is necessary to do so in order to complete the installation.

Debug programs

Not required, but preferred

You must have this user right in order to debug a process. Package installer versions earlier than 5.4.1.0 might require Administrators to have this user right in order to install software updates. For more information, see article 830846, “Windows Product Updates may stop responding or may use most or all the CPU resources,” in the Microsoft Knowledge Base.
You must have the debug programs user right to use hotpatching. For details, see Hotpatching.

Package Installer Scenarios

This section describes the three common uses of the package installer: extracting the contents of a software update package, installing a Windows service pack, and installing a simple software update.

Extracting the contents of a software update package

In some cases, you might want to extract the files from the package before installing it. The next section, Extracting Update Package Contents Prior to Deployment, discusses command-line options that you can use to direct the extraction process.

Installing a Windows service pack

For the purposes of illustration, this is described here as though you were installing Windows 2000 Service Pack 4 (SP4).

To install Windows 2000 SP4, you would double-click the file W2ksp4.exe. This extracts the installation files for the service pack and automatically launches the package installer to install the service pack.

Installing a simple software update

For the purposes of illustration, this is described here as though you were installing the software update associated with Knowledge Base (KB) article 810556.

To install the software update associated with KB article 810556, you would run KB810556_WXP_SP1_x86_ENU.exe. This extracts the installation files for the software update and automatically launches the package installer to install the software update.

Extracting Update Package Contents Prior to Deployment

In some cases, you might want to extract the files from the package before you deploy it. This can help you to better understand the changes that will be made when the software update is installed. In this case, the package installer extracts the contents of the package: the package installer executable files, the supporting files for the package installer, and the payload.

This section discusses how to extract the package contents and explains which command-line options you can use to control the extraction of the software update package.

There are several different options for extracting the contents of the package and for controlling where the extraction occurs. The command-line options determine whether user prompts will appear, and where to extract the files.

The following table details the extraction options and their functions.

Table 13 - Extraction Command-line Options

Command-line OptionsDescription

/quiet

Provides no status dialog box during the extraction. Must be used in combination with /extract or /extract:path, or this option will direct the installation to run in quiet mode. /Q can be used for package installer versions earlier than 5.3.24.4.

/passive

Provides a progress bar during the extraction, but does not prompt you for the destination folder name. Must be used in combination with /extract or /extract:path, or it will direct the installation to run in passive mode. /U can be used for package installer versions earlier than 5.3.24.4.

/extract

Extracts package files without starting the installation. Prompts you for the path to the destination folder for extraction. /X can be used for package installer versions earlier than 5.3.24.4.

/extract:path_name

Extracts software update package files to the specified directory without starting the package installer or prompting you for a destination folder. /X:path_name can be used for package installer versions earlier than 5.3.24.4.

After extraction, the files are placed in the specified folder. If no folder is specified, and the command-line option /extract was used with /passive or /quiet, a randomly named folder (for example, 1ed6b742f546f) is generated and the files are placed there.

The following table provides examples of commands you can use to extract the contents of a software update package.

Table 14 - Examples of Commonly Used Extraction Options

ExampleDescription

Package_name.exe /extract

Prompts for a folder location, and extracts the contents of the package to that location.

Package_name.exe /extract:C:\Update

Extracts the contents of the package to a newly created folder called Update on drive C:.

Package_name.exe /extract /passive

Extracts the contents of the package to a randomly generated folder in the root folder of the current drive.

In package installer versions 5.3.18.6 and later, when the /extract option is specified and a valid path (/extract:C:\path_name) is included, the package installer will suppress the dialog box that confirms the destination folder. Older versions of the package installer will present this dialog box when the /X:path option is specified. To prevent this action, specify /U along with the /X:path command-line option. See Appendix A – Package Installer Versioning and Features for details about package installer features and versioning.

To install a software update package after extracting its contents, run the Update.exe file to begin the installation, or use the command line to specify the options to use with the installation. See Command-line Options for details.

For a dual-mode installation in which the contents of the package were extracted first, use the Xpsp1hfm.exe file instead of Update.exe to run the installation. The same options that apply to Update.exe can be applied to Xpsp1hfm.exe. For more details, see Migration.

Command-line Options

This section describes the command-line options that the package installer supports for installation. You can use these options to modify the default behavior of the package installer for software update installations. The options are passed from the extractable package to the package installer. These options do not affect how the files are extracted, however.

Note: For information about determining which version of the package installer you are using, see Appendix A – Package Installer Versioning and Features.

The options in the following table apply to both the installation and removal of a package unless otherwise noted in the description column. All options listed use a forward slash (/). For compatibility with older versions, a hyphen (-) can still be used in place of the forward slash (/).

Table 15 – Package Installer Command-line Options

OptionDescriptionInstaller Versions

/help

Displays command-line Help dialog box. This option must be used alone.

Version 5.3.24.4 and later support the /help option. For compatibility with older versions, the/? option can be used.

/passive

Unattended mode. No user interaction is required, but installation status is displayed. If a restart is required at the end of Setup, a dialog box appears with a timer and a warning stating that the computer will restart in 30 seconds.

Version 5.3.24.4 and later support the /passive option. For compatibility with older versions, the /u option can be used.

/quiet

Quiet mode. Same as unattended mode, but no status or error messages are displayed.

Version 5.3.24.4 and later support the /quiet option. For compatibility with older versions, the /q option can be used.

/norestart

Do not restart the computer when the installation is complete.
Not compatible with /integrate or /forcerestart.

Version 5.3.24.4 and later support the /norestart option. For compatibility with older versions, the /z option can be used.

/warnrestart

Presents a dialog box with a timer and a warning stating that the computer will restart in x seconds. The default is 30 seconds. Intended for use with either /quiet or /passive.

Version 6.1.22.0 and later support the /warnrestart option.

/forcerestart

Restart the computer after installation, and force other applications to close at shutdown without saving open files first.

Version 5.3.24.4 and later support the /forcerestart option.

/promptrestart

Presents a dialog box that prompts you to restart if required. Intended for use with /quiet.

Version 6.1.22.0 and later support the /promptrestart option.

/forceappsclose

If a restart is required, forces other programs to close without saving when the computer shuts down. Not compatible with /integrate or /norestart.

Version 5.4.15.0 and later support the /forceappsclose option. For compatibility with older versions, the /f option can be used.

/nobackup

Do not back up the files that would later be required to uninstall the software update. The files required to remove the software update will not be backed up during the installation. Although this option can help save disk space, the software update cannot be removed later. Not compatible with /integrate. The /nobackup option is only applicable to package installations.
This functionality varies depending upon the version of the package installer used. For package installer versions earlier than 5.3.18.6, there will be no entry in Add or Remove Programs. For package installer versions 5.3.18.6 and later, there will be an entry in Add or Remove Programs, but there will not be an option to remove the software update.

Version 6.1.22.0 and later support the /nobackup option. For compatibility with older versions, the /n option can be used.

/overwriteoem

Overwrite OEM files without prompting. During a normal installation in attended mode, if a software update installation will overwrite a file supplied by the computer manufacturer, a notification will ask you to confirm whether the file should be overwritten. Specifying this option turns off that functionality and overwrites the file without notification. Running in unattended mode will not overwrite OEM files unless the /overwriteoem option is specified. This option only applies to package installation.

Version 6.1.22.0 and later support the /overwriteoem option. For compatibility with earlier versions, the /o option can be used.

/integrate:path

Integrates software updates into the Windows installation source files or service pack files located at the path specified. The specified path must be fewer than 256 characters. For information about how to deploy an integrated installation (sometimes called “slip streaming”), see Integrated Installation. This option applies only to package installation, not to package removal.

Version 5.4.15.0 and later support the /integrate:pathoption. For compatibility with earlier versions, the /s option can be used.

/log:path

Specifies where to create the log file. The specified path must be fewer than 256 characters.

Versions 6.1.22.0 and later support the /log option.

/ER

Enable extended error reporting. The default behavior of the package installer is to return one of three standard return codes. See Return Codes for more information. Extended return codes are either standard Win32 codes or codes that are specific to the package installer. See Appendix F - Extended Return Codes and Setup API Error Codes for details. This option applies only to package installations.

Versions 5.3.24.4 and later support the /ER option.

/verbose

Enable verbose logging. Upon installation, creates the %windir%\CabBuild.log, which details the files to be copied. Using this option can cause the installation to proceed much more slowly.

Version 5.3.24.4 and later support the /verbose option. For compatibility with earlier versions, the /v option can be used.

/d:path

Specifies a backup directory for Windows service pack installations. The path indicates the destination folder for the backup files. The specified path must be fewer than 256 characters. The default backup location is %systemdrive%\$ntservicepackuninstall$. Only available for Windows service pack installations.

Versions 5.3.16.5 and later are support the /d option.

/hotpatch:disable

Disables hotpatching functionality. See Hotpatching for details.

Use only with Windows Server 2003 packages that are compatible with hotpatching. See Identifying Hotpatching Compatibility for details.

Command-line Option Compatibility

In some cases, you can use command-line options together. In other cases, you should not do so because they are incompatible or might default to unexpected behavior.

The following table lists a variety of combinations and notes their compatibility with each other. If the table entry for a particular combination is blank, the options are compatible and you can use them together. If the W symbol appears for a particular combination, it means that the options are incompatible and should not be used together.

FTable 16 –Command-line Option Compatibility

Table 16 –Command-line Option Compatibility

Chained Installation

Chained installation streamlines the installation of multiple software update packages because it requires only one restart at the end of installation. All Pending File Rename (PFR) operations associated with the software updates installed in a chained installation are committed after that restart.

During a chained installation, the package installer checks the Pending File Rename queue for any file conflicts, and resolves them after each installation.

The following example illustrates how this is done.

A software update is installed that has to create a PFR entry for version 1.2 of Example.dll. Immediately afterwards, a second software update is installed that creates a PFR entry for version 1.1 of Example.dll. The package installer must ensure that the more recent copy of Example.dll is installed on the computer (version 1.2), so it removes the PFR entry for version 1.1.

In earlier versions of the package installer, it was necessary to manually run a tool called QChain to chain a software update installation. In package installer versions 5.3.12.0 and later, QChain functionality is included in the package installer itself, so running the tool separately is no longer necessary. See Appendix A – Package Installer Versioning and Features for information about how to determine the package installer version.

For more information about the QChain tool, see article 296861, “How to install multiple Windows updates or hotfixes with only one reboot,” in the Microsoft Knowledge Base.

When you are installing software updates that were released before December 2002, or that include package installer versions prior to 5.3.12.0, we recommend that you restart the computer after the installation. For more information, see article 815062, “The correct file is not installed when you chain multiple hotfixes,” in the Microsoft Knowledge Base.

Note: The package installer does not allow for chaining the removal of software updates. After a software update is removed, the computer must be restarted if necessary before you remove another software update.

Language Considerations

Some software updates are language-specific and must match the language on the computer. Others are more flexible, enabling one software update to be applied on any computer, regardless of language or locale.

For Windows software updates to function properly, the language of the software update installed must match the default language on the computer. This might not be a requirement for other Microsoft product software updates. If the related Knowledge Base article does not identify the software update as language-specific or neutral, you can determine whether this requirement applies by reviewing the LanguageType value in the Update.inf file. A language code of 0x0 means that the software update will install on any language. See Appendix B – The Update.inf File for more information about how to read the Update.inf file.

For Multilingual User Interface (MUI) packs, there are no specific MUI software update packages. Consequently, the correct way to update these systems is to install the English release of the software update.

For more information, see Service Pack Release Notes for Windows Multilingual Interface (MUI) Version on the Microsoft Web site.

Deployment Methods

There are several methods you can use to deploy software updates to computers in a networked environment. These include running the package manually with a combination of installation command-line options, using an installation batch file, distributing updates by using a shared network distribution folder, combining software updates with Windows Operating System installation, using Systems Management Server (SMS), using Windows Update Services, downloading directly from Windows Update, and using Sysprep. In addition, some Windows service packs can be deployed by using Windows Installer.

Windows Deployment Guides

The table in this section lists the deployment guides that are the best resources for information about deploying Windows software updates. These deployment guides provide specific information about deploying software updates in environments that include a single computer or multiple computers. You should consult the appropriate deployment guide if you are planning a deployment.

Table 17 - Deployment Guides

Operating System and Service PackDeployment Guide Link

Windows 2000 operating systems

Microsoft Windows 2000 Hotfix Installation and Deployment Guide

Windows 2000 – Service Pack 4 (SP4)

Microsoft Windows 2000 Service Pack 4 Installation and Deployment Guide

Windows XP operating systems

Deploying Windows XP Part I: Planning

Windows XP

Deploying Windows XP Part II: Implementing

Windows XP

Microsoft Windows XP Hotfix Installation and Deployment Guide

Windows XP

Guide for Installing and Deploying Microsoft Windows XP Service Pack 2

Windows Server 2003 operating systems

Microsoft Windows Server 2003 Deployment Kit

Large scale deployments

Microsoft Management and Operations

Installing from a Network Folder

To install a software update on multiple computers in an individually managed environment, place the software update on a shared network drive. The distribution folder should be a shared network location that is accessible to all of the computers to be updated. (For details, see the appropriate Windows deployment guide in the previous table.)

For example, to install a software update from a distribution folder named Update_Folder, you would type the following:

\\ServerName\ShareName\Update_Folder\update_name.exe

To customize the installation, use the command-line options described in Command-line Options.

Important: Be sure to review Chained Installation before performing multiple installations at the same time.

Installation Batch Files

Multiple software updates can be installed together through the use of batch files. The following batch file samples are based on two of the more common scenarios for installing multiple software updates from a network shared folder.

The first example demonstrates how to combine the installation of a service pack and a hotfix. The second example shows how to determine whether a restart is necessary after installing three software updates together.

Combining a service pack and software updates

This example chains together the installation of a service pack and a hotfix. The restart required by the service pack installation is suppressed so the hotfix can be applied.

@ECHO OFF
SETLOCAL
REM Location of updates to install
SET PathOfFixes=Drive:\hotfix

%PATHTOFIXES%\SP_install.exe /norestart /passive
%PATHTOFIXES%\Update_A.exe /passive
Shutdown /r

The chaining functionality (see Chained Installation) in the package installer enables multiple installations to be chained together. During this type of installation, the Pending File Rename operations from all installations are processed in one restart. See The Pending File Rename Registry Key for details.

In the previous example, this can only be done for software updates that include package installer versions 5.3.12.0 and later, where QChain functionality is included in the package installer itself. See Appendix A – Package Installer Versioning and Features for information about how to determine package installer version.

The previous example uses the /passive option, which instructs the package installer to run in unattended mode, so you are not required to provide input to the process. This example also includes a restart command that restarts the computer after the hotfix installation.

Determining whether a restart is necessary

The following example illustrates how to use a batch file to evaluate the return code from the package installer to determine whether a restart is necessary. This is the recommended procedure when you are using a batch file to install software updates. A restart could be required by any of the software updates.

@ECHO OFF
SETLOCAL
REM Location of updates to install
SET PathOfFixes=Drive:\hotfix
REM Flag used to determine if a restart is required, initialize to 0
SET Reboot_Needed=0

%PathOfFixes%\update_a.exe /norestart /passive
IF ERRORLEVEL 3010 SET Reboot_Needed=1

%PathOfFixes%\update_B.exe /norestart /passive
IF ERRORLEVEL 3010 SET Reboot_Needed=1

%PathOfFixes%\Update_C.exe /norestart /passive
IF ERRORLEVEL 3010 SET Reboot_Needed=1

REM force restart here 
IF %Reboot_Needed%.==1. Shutdown /r

The example checks the return code from the package installer after each software update to determine whether a restart is necessary. See Return Codes for details.

Note: For Windows XP and Windows Server 2003, the shutdown command used in the previous example is part of the operating system and is available by default. For Windows 2000, the same functionality is available through the Windows NT Resource Kit utilities; Shutdown.exe and Shutgui.exe and must be installed separately.

Integrated Installation

An integrated installation is one in which service packs or other software updates are installed together with the operating system. You can use this type of installation, also known as “slipstreaming,” to fully update a computer in a single imaging process. This installation enables the operating system image to be updated with a service pack, software updates, or both, before installation. The /integrate command-line option is used for integrated installations.

A software update can be integrated into the Windows operating system source files. This procedure is useful, for example, if you want to integrate a security update or an entire service pack with the operating system source files. One benefit of this approach is that it can help protect a new operating system installation from being infected with a virus that the security update is designed to prevent.

To perform this type of installation, you create a network shared folder for the Windows operating system installation files. You use the /integrate command-line option to direct the package installer to copy the software update files to the shared network folder you just created. The original operating system files will be overwritten with the updated ones. When the operating system files from this network shared folder are installed onto a computer, the computer will receive the updated versions instead of the original versions. This is illustrated in the following example.

KB123456.exe /integrate:c:\source_files

In this example, the hypothetical software update KB123456 is being combined into a directory with Windows source files.

The following table lists scenarios for integrated installations and indicates whether the functionality in the package installer supports them.

Table 18 – Integrated Scenarios

Integrated Installation ScenarioSupported

Integrate a simple software update into an operating system.

YES

Integrate a Windows service pack into an operating system.

YES

Integrate a simple software update into an operating system that has previously been integrated with a service pack.

YES

Integrate a simple software update into an operating system that has previously been integrated with any number of simple software updates.

YES

Integrate a service pack into an operating system that has previously been integrated with another service pack.

YES

Integrate a service pack into an operating system that has previously been integrated with a simple software update.

NO

Integrate a service pack with a simple software update.

NO

Integrate a simple software update with another simple software update.

NO

For more information, see article 828930, “How to integrate software updates into your Windows installation source files," in the Microsoft Knowledge Base.

For a full discussion on how to implement an integrated install, see Windows Deployment Guides.

Deploying Windows Service Packs through Group Policy

You can deploy most Windows service packs through Group Policy by using Update.msi, a special version of the service pack package. The machine-assigned distribution method is the only one available with Update.msi.

For more information about deployment, see Windows Deployment Guides in this document, and article 278503, “Best Practices for using Update.msi to deploy Service Packs,” in the Microsoft Knowledge Base.

Note: Microsoft does not support customers repackaging software updates with a different installer. The package installer and the Windows Installer are not interchangeable. Packages built with one installer technology have been tested and optimized to work only with that technology.

Return Codes

The package installer provides you with feedback on the outcome of an installation through a return code. When you install a software update with a batch file, the return code is returned to the calling process. See Installation Batch Files for details. It can help you determine your next course of action. If an installation fails, the return code is also recorded in the installation log file. See Package Installer Log Files for more details about these log files.

By default, the package installer uses three values to report the status of the installation. The following table lists the three values and their corresponding error codes:

Table 19 - Return Codes

ValueError CodeDescription

0

ERROR_SUCCESS

Success

3010

ERROR_SUCCESS_REBOOT_REQUIRED

Success with reboot required

1603

ERROR_INSTALL_FAILURE

Failure

Extended return codes provide more detailed information related to an error generated during installation. When you pass the /ER command-line option to the package installer, extended return codes are returned. The installation log always contains the extended error code, even if the /ER option was not provided. Extended return codes are available in package installer versions 5.3.24.4 and later. See Appendix A – Package Installer Versioning and Features for details.

When you enable the extended return codes through the /ER option, valid return codes will be from one of two categories: the standard Win32 errors documented in System Error Codes on the Microsoft Web site, or return codes that are specific to the package installer. For the list of package installer-specific return codes, see Appendix E - Extended Return Codes and Setup API Error Codes.

Identifying Installed Software Updates

After software updates are installed, they are listed in Add or Remove Programs in Control Panel. Because software updates are considered additions to the original released product, they are listed in Add or Remove Programs under the entry for the original product.

Qfecheck.exe is another tool you can use to identify installed Windows software updates.

For more information about Qfecheck, see the following articles in the Microsoft Knowledge Base:

282784, “Qfecheck.exe verifies the installation of Windows 2000 and Windows XP hotfixes”

304864 “Qfecheck Hotfix Tool Reports False Need to Reinstall Freshly Installed Hotfixes”

Deploying Hotpatches

Before you use hotpatching to deploy a software update in a production environment, determine whether the software update supports hotpatching. Then evaluate the installation in a representative test environment.

Identifying Hotpatching Compatibility

The two following conditions must be met for a software update to be compatible with hotpatching:

The software update package must support hotpatching. To determine this, check the Microsoft Knowledge Base article associated with the software update. The article will specify whether hotpatching is supported. If hotpatching is not mentioned, the package does not support it.

You can also determine whether hotpatching is supported by extracting the software update package contents and looking for files with .hp extensions. For details on how to extract package contents, see Extracting Update Package Contents Prior to Deployment.

The installed file on the computer can be updated using hotpatching. Determine which operating system file the software package will update. View the properties for that file on the computer to which you plan to apply the software update. You might be able to use hotpatching to install the software update if the file version details in Other version information (see Figure 9) include (srv03_gdr.######-####) or (srv03_sp#.######-####). You cannot use hotpatching to install the software update if the file version details include (srv03_qfe.######-####) or (srv03_rtm.######-####). You must also have the latest security updates for those files installed. To determine whether the latest security updates are installed, go to the Microsoft Windows Update Web site.

Note: The branch information might not always be included in the version properties for a particular file.

The following figure shows the properties of two files.

Figure 9: Properties of a non-hotpatching compatible file and a hotpatching compatible file

Figure 9: Properties of a non-hotpatching compatible file and a hotpatching compatible file

In this figure, the example on the left shows a file that cannot be updated using hotpatching. The example on the right shows a file that you might be able to update using hotpatching.

Installing a Hotpatching Package

Hotpatching functionality is enabled by default for compatible packages. Therefore, the same procedures for deploying a “regular” package can be used for hotpatching packages. See Command-line Options for more details.

When you install a software update in attended mode, a message will appear if the installation fails or if a restart is required. If no message appears, the installation is successful, and the server does not require a restart. In unattended mode, check the installation log or the return code to verify this. See Package Installer Log Files for more details.

Another way to determine whether a hotpatch has been applied is to check the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\InstalledHotpatches

This registry key will contain values named for each of the files to which a hotpatch was applied. This key is removed when the system is restarted because hotpatches no longer exist after the computer is restarted.

Even if you can use hotpatching to install a software update, the server might still require a restart after installation. A restart might be required if a software update is installed while a debugger is connected to the applicable process.

Note: To avoid having to restart production servers unexpectedly after installing a software update, deploy the software update in a test environment first to verify that the installation works as expected.

To disable hotpatching functionality and install a software update as a regular package, use the /hotpatch:disable command-line option.

Removing Software Updates

It might be necessary to remove software updates installed with the package installer. When a software update is installed, a backup directory is created at %SystemRoot%\$NtUninstall[KBArticleNumber]$\ for simple updates. A backup directory is created at %SystemRoot%\$NtServicePackUninstall$ for Windows Service Packs.

The backup directory contains the original files that the software update replaced, a file called Spuninst.exe that performs the removal, and Spuninst.inf, which contains the logic needed for the removal, including files to be replaced and registry entries to be changed. If the /nobackup command-line option was specified, this directory will not be created. For a service pack installation, if the /d:path command-line option was used, the service pack backup directory will be created in the location you specify. See Command-line Options for more details.

Note: By default the backup directories are hidden. The “Show Hidden Files and Folders” option must be selected in order for you to view these directories and their contents.

Removal of a software update replaces the files on the computer with the original files from the backup directory and changes registry entries back to the values they held before the software update was applied. Entries from Add or Remove Programs in Control Panel are also removed. If a service pack is removed, the individual Add or Remove Programs entries for the software updates that were “rolled up” into the service pack are restored. The following figure illustrates this process.

Figure 10 – Overview of software update removal

Figure 10 – Overview of software update removal

Removal Methods

This section provides detailed information about methods you can use to remove a software update.

To remove a software update by using Add or Remove Programs:

Open Control Panel.

Click Add or Remove Programs, and then click the entry for the software update you want. On computers running Windows XP SP2 or later, or Windows Server 2003 SP1 or later, ensure the “Show Updates” check box is selected.

Click the Remove button. If the software update cannot be removed, the Remove button will appear.

Follow the instructions in the Software Update Removal Wizard. The removal process might require you to restart the computer.

When the removal is completed, a message will appear verifying that that the software update was removed successfully.

To remove a software update by calling Spuninst.exe directly:

Navigate to the %WINDIR%\$NtUninstall[KBArticleNumber]$\spuninst\ directory for the software update that you want to remove.

Double-click spuninst.exe.

Follow the instructions in the Software Update Removal Wizard.

When the removal is completed, a message will appear verifying that that the software update was removed successfully.

Spuninst.exe can also be executed from the command-line or through a batch file with appropriate command-line options specified to customize the installation.

In package installer versions prior to 6.1.22.0, you must be logged on in order to remove software updates.

Note: The package installer does not allow for chained removal of software updates. After a software update is removed, it might be necessary to restart the computer before you remove another software update. For more information about chaining during installation, see Chained Installation.

To perform a manual removal through the recovery console:

If the computer does not boot properly after you install an update, it is possible to remove the update without booting into Safe Mode. Spuninst.exe can be executed in the Recovery Console.

The following example illustrates how this is done. Windows XP is the operating system used in this example.

Insert the Windows XP CD-ROM in your computer's CD-ROM or DVD-ROM drive, and then restart your computer.

When the "Press any key to boot from CD" message appears on the screen, press a key to start your computer from the Windows XP CD-ROM.

Note: Your computer must be configured to start from the CD-ROM or DVD-ROM drive. For more information about how to configure your computer to start from the CD-ROM or DVD-ROM drive, see your computer's documentation, or contact your computer's manufacturer.

The following message appears on the “Welcome to Setup” screen:

This portion of the Setup program prepares Microsoft Windows XP to run on your computer:

To setup Windows XP now, press ENTER.
To repair a Windows XP installation using Recovery Console, press R.
To quit Setup without installing Windows XP, press F3.

When you see this message, press R to start Recovery Console.

Type the number of the installation you want to repair. If you have only one installation of Windows on the computer, type 1, and then press ENTER.

Enter the administrator password, and then press ENTER.

Type the following commands to start the manual removal:

cd $ntservicepackuninstall$\spuninst
batch spuninst.txt
exit

Restart the computer

Open Regedit.exe and set the following registry key to Local System:

HKLM\System\CurrentControlSet\Services\RpcSs\ObjectName“

Run %windir%\$<updatebackupdirectory>$\spuninst\spuninst.exe. This will roll back any registry changes, execute any processes that need to be run, and so on.

During this manual removal, you might encounter several "Access Denied" error messages. This is expected. This occurs because the batch file is trying to copy files that are in use and cannot be accessed.

If this method does not work, you can remove the software update by repairing the Windows installation using the original Windows CD-ROM that you used to install the operating system.

Note: If a software update installation fails after files have started copying, the package installer will attempt to roll back the installation by calling Spuninst.exe directly. The package installer will try to restore the computer to its original state, but it might be necessary to perform one of the removal methods listed previously to remove the partially updated files.

Command-line Options for Removing Software Updates

The following command-line options are supported for removing software updates:

/passive

/quiet

/warnrestart

/promptrestart

/norestart

/forcerestart

/forceappsclose

/log:path

/verbose

For details about these options, see Command-line Options.

Order of Removal

Software updates must be removed in the reverse of the order in which they were installed. This means that, to keep the files on the operating system consistent, you must remove the most recently installed Windows software update first, remove the next most recently installed software update next, and so on.

If you attempt to remove software updates in the wrong order, and the removal is in attended mode (requiring user interaction), the following error message will appear:

Setup detected the following programs on your computer: 
List of software updates and applications 
If <software update> is removed, these programs may not run correctly.

If the removal was run in unattended mode, it will fail without displaying an error message, and the details of the failure will be recorded in the software update removal log file. See Log Names and Location for details.

For detailed information about removing software updates, see article 823836, “Removing Windows software updates in the wrong order may cause the operating system to stop functioning,” in the Microsoft Knowledge Base.

Important: We do not recommend removing security updates because this can leave your computer in unprotected state that could compromise its security.

Understanding Package Installer Log Files and Error Messages

Event Log Entries

After a software update installation has completed, including any necessary restarts, an event is added to the system log. This event indicates that the update was properly installed.

This is illustrated in the following example:

Event Type:Information
Event Source:NtServicePack
Event Category:None
Event ID:4371
Date:3/18/2004
Time:12:51:42 PM
User:DOMAIN\username
Computer:COMPUTERNAME
Description:
Windows XP Service Pack 2 was installed (Service Pack 1 was previously installed). 
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp

When a software update is removed, the following entry is logged to the System event log:

Event Type:Information
Event Source:NtServicePack
Event Category:None
Event ID:4382
Date:5/25/2004
Time:10:28:42 AM
User:COMPUTERNAME\Administrator
Computer:COMPUTERNAME
Description:
Windows XP Service Pack 2 was removed from your computer, and the previous Windows XP 
configuration was restored.
For more information, see Help and Support Center at 
http://go.microsoft.com/fwlink/events.asp

The previous examples are for Windows XP SP2 installation and removal, but similar event log entries will be made for any software update.

Package Installer Log Files

The package installer log files are generated during the installation or removal of a software update. They contain status and error information about the process. See Appendix D – Sample Package Installer Logs for sample installation and removal logs with annotations on the entries.

Log Names and Location

For every software update installed, a new log file is generated. The package installer log files are located in the Windows root (%WINDIR%) directory. The log file for Windows service pack installations is called Svcpack.log. Log files for other software updates are named by Knowledge Base article number for easy identification.

For example, to install the software update associated with Knowledge Base article 824146, the log file would be named KB824146.log. If a software update is reinstalled, the log file for that software update is appended with the information from the new installation.

The name of the package installer log is defined by the Update.inf file. See the InstallLogFileName variable under the [Strings] section in Update.inf.

Standard Windows log file names are as follows:

Table 20 – Standard Log File Names

Type of LogLog File Name

Service pack installation

Svcpack.log

Service pack removal

Spuninst.log

Software update installation

KB######.log

Software update removal

KB######Uninst.log

The following sections describe the standard Windows log files.

Svcpack.log

The main log file for Windows service pack installation is %windir%\svcpack.log. This file contains information and errors that occur during service pack installation. It is appended each time you try to install the same software update, so entries pertaining to the most recent installation are at the end of the file.

Note: This log often contains errors that are not indicative of a problem that occurred during the installation. See Non-Error Log Entries for details.

Setupapi.log and Updspapi.log

The package installer uses the Setup API functions to perform certain tasks related to reading .inf files, establishing file trust and installing drivers. These actions are logged in %windir%\setupapi.log. In packages built with package installer versions 6.1.22.0 and later, there is also a log file at %windir%\updspapi.log. Errors and status messages specific to Setup API functions appear in these logs. A partial listing of error codes is in Appendix E - Extended Return Codes and Setup API Error Codes.

For more information, see Setup API at the Microsoft Web site.

KB######.log

This file logs the installation of a software update that is not a Windows service pack. The file is located at %windir%\KB######.log. It contains information and errors that occur during a software update installation. It is appended each time you try to install the same software update, so entries pertaining to the most recent installation are at the end of the file. This log will often contain errors that are not indicative of a problem that occurred during the installation. See Non-Error Log Entries for details.

KB######uninst.log

This file logs the removal of a software update that is not a Windows service pack. The file is located at %windir%\KB######uninst.log. It is created when you initiate the removal of a software update. Status information and errors that occur during the removal are logged here. This file is not appended on subsequent removals, so it only provides a record of the most recent removal of that software update.

Spuninst.log

This file logs the removal of a Windows service pack. The file is located at %windir%\spuninst.log. It is created when you begin the process of removing a service pack. Status information and errors that occurred during the removal are logged here. This file is not appended on subsequent removals, so it only provides a record of the most recent service pack removal.

Spupdsvc.log

It might be necessary for a software update to run certain processes after restarting the computer. This is handled by the file Spupdsvc.exe, and its actions are logged in %windir%\spupdsvc.log. It documents whether every process that it was required to run was properly executed. Problems are logged using standard Windows error codes.

Cabbuild.log

%windir%\CabBuild.log is created only when a package is executed with the /verbose command-line option. See Command-line Options for details. Performing an installation with this option might increase the installation time. This option is useful, however, for identifying file-copy issues because it includes complete details about the installation target files and source files.

Spslpsrm.log

%systemdrive%\spslpsrm.log is created when the /integrate command-line option is used. It provides a log of the operation. See Integrated Installation for details.

Installation Log Contents Summary

The following is a summary of the information found in the installation log files.

Package and platform analysis

Command-line arguments used to start the installation

Package installer version

Whether the installation is a service pack or a simple software update

Backup location

Package installation location

Inventory

OEM file check results

Hotpatching status

Download statistics for express packages

Disk usage calculations

Timing statistics

File/registry backup status

File copy

Pending File Rename operations

Security catalog installation

Registry updates

Determine reboot status

Processes executed from the Custom.dll and return codes

Return codes (extended and basic)

Reboot status

Pending file renames from the registry

Troubleshooting

Non-Error Log Entries

The main installation logs contain a number of entries that seem to be errors, but which are actually just informational. This is because the package installer uses the standard Windows Setup API, and thus has limited control over the format and entries. In general, if the installation completes and does not log a failure return code, any “error” messages in the log file are non-critical. If there is a serious error, the installation will stop. The item that caused the failure will typically appear in one of the last lines in the log.

The following table lists common entries in the package installer log that might be confused with actual installation failure errors.

Table 21 - Log Entries That Seem to Be Errors

Log Entry ExampleDetails

DoInstallation: CleanPFR failed:

This indicates that there were no entries in the Pending File Rename (PFR) queue, so there were none to remove.

FetchSourceURL: SetupOpenInfFile Failed to open file: d:\20fc32a210eecc6746827750294191cb\i386\update\update.url

This is an error only for express package installations in which the software update is installed from Windows Update. If all files needed for the software update are local (stand-alone/full installation), it is not an error.

DoInstallation: FetchSourceURL for d:\20fc32a210eecc6746827750294191cb\i386\update\update.inf Failed

This is an error only for express package installations where the software update is installed from Windows Update. If all files needed for the software update are local (stand-alone/full installation), it is not an error.

BuildCabinetManifest:SetupOpenInfFile failed with error INVALID_HANDLE_VALUE

Informational; looking for a file that was not included in the package. A true error only if the installation did not continue past this point.

Failed Deleting C:\WINNT\system32\msiinst.tmp 2

Check to ensure that all directories and files created were removed. The file in question might not have been created, so there was nothing to delete.

RegisterFile:RegOpenKeyEx for SOFTWARE\Microsoft\Updates\Windows 2000\SP4\KB811493\Filelist\3 Failed: 0x2

Informational; looking for a registry key that does not exist. In this example, it might be that software update KB811493 was not previously installed.

LoadFileQueues: SetupGetSourceFileLocation for halacpi.dll failed: 0xe0000102

Any log entries referencing hal*.* files are generally not errors. The package installer always searches the package for hal*.* files, and, if it finds them, installs those files. If it does not find them, it will post this error to the log. Most software update packages do not contain files of this type.

GetCatVersion: Failed to retrieve version information from C:\WINDOWS\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB######.cat with error 0x57

An error was generated during the security catalog check. This is not a true failure if installation continues past this entry in the log.

Failed to query DriverPath for .* with error 0x0

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

Failed to query DrvDescription for .* with error 0x0

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

SetupVerifyInfFile failed with error 0x490 for .* of device .*

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

SetupOpenInfFile in IsThirdPartyInf Failed with error 0xe0000003

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

UpdateMonitoredListFailed WithError 0x6ba

Informational message. This is not a true failure if installation continues past this entry in the log.

SetupDiEnumDriverInfo failed for .* with error 0x00000103

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

SetupFindFirstLine in LoadExclusionList Failed with error: 0xe0000102

Informational message. This is not a true failure if installation continues past this entry in the log.

Driver DateData From Registry for Packet Scheduler Miniport failed with error 0x7a

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

SetupDiEnumDriverInfo() failed with error 0x103

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

InstallCatalogFile: InstallCatalog failed for .* error=0xfffffdda

Jet database error corresponding to manual removal of security catalog. Informational only.

Failed to open the Signing Key with error 0x5

Informational message. This is not a true failure if installation continues past this entry in the log.

UpdateMonitoredListFailed WithError 0x54f

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

\[dumpDownloadTask\] ERROR extracting .* Will go for Fallback

Informational message. This is not a true failure if installation continues past this entry in the log.

\[dumpDownloadTask\] Failed SetFileAttributes for .* Ignore and continue.

Informational message. This is not a true failure if installation continues past this entry in the log.

SetupDiBuildDriverInfoList in CollectThirdPartyDriversFromDevice Failed with error: 2

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

SetupDiBuildDriverInfoList\(\) failed with error 0xe0000201

Informational message relating to driver installation. This is not a true failure if installation continues past this entry in the log.

Errors ending in 0x2

Usually these are “not found” errors. If installation continues past them, they are not a cause of installation failure.

VerifySize errors

These are informational entries. If installation continues past them, they are not a cause of installation failure.

Note: If installation fails, usually the last entry in the log is the error that indicates the cause of the failure. The extended return code can also help you determine the cause of failure.

Common Errors

The following error messages appear in a dialog box during an attended installation. For an unattended installation, the error messages will appear in the installation log file.

Table 22 – Common Errors

Error MessageExplanationSolution

You do not have permission to update <operating system name>. Please contact your system administrator.

The user does not have the required user rights.

Assign the required user rights as outlined in article 888791, “The user rights that are required by Update.exe,” in the Microsoft Knowledge Base.

The version of Windows you have installed does not match the update you are trying to install.

The user tried to install a software update built for an operating system other than the one running on the computer.

Software update packages are built for specific operating systems and service pack levels. Ensure that the update package is the correct version for the system being updated.

Another installation is already in progress. Complete that installation before proceeding with this install.

Another package installer installation is already running when the user tries to install a package.

Use Windows Task Manager to check for another instance of the package installer. Wait for that one to finish before starting another installation.

Setup cannot copy the file XXXX.DLL. Ensure that the location specified below is correct, or change it and insert ‘(Unknown)’ in the drive you specify.

The user installing the software update does not have the right permissions on the target directory.

Check the installation log for more details on the directory.

Failed to add registry entry.

The user installing the software update does not have the right permissions on a particular registry key.

Check the installation log for more details on the specific registry key.

The data is invalid

The user installing the software update does not have the Debug Programs user right.

Assign the required user rights as outlined in article 888791,”The user rights that are required by Update.exe,” in the Microsoft Knowledge Base.
Also see article 830846,”Windows Product Updates may stop responding or may use most or all the CPU resources,” in the Microsoft Knowledge Base.

Setup detected the following programs on your computer: List of software updates and applications
If software update is removed, these programs may not run correctly.

The user is trying to remove a software update that is not the most recently installed one.

Remove software updates in the reverse of the order in which they were installed. See Order of Removal for more details.

This Service Pack contains files that are missing some of the fixes which were previously installed on this computer. To prevent possible problems, these files will not be installed by the Service Pack.
In order to have these fixes contained in both the Service Pack and the previously installed hotfixes, you must obtain and install the updated versions of the following hotfixes prior to or following the installation of the Service Pack. These hotfixes are also listed in the svcpack.log file.

During a service pack installation, the user is notified that there are blocklisted software updates installed on the computer.

Download the new packages for the blocklisted software updates and install them after the service pack Installation. See Using Blocklists to Overwrite Installed Software Updates for details.

Setup cannot install this hotfix because one or more of its files are out of date. Please download and install the latest version of fix KB######.

The user tried to install an earlier version of a blocklisted software update.

Download the new packages for the blocklisted software updates and install them after the service pack Installation. See Using Blocklists to Overwrite Installed Software Updates for details.

Debug Symbols

Debug symbols are no longer included in Microsoft software update packages. Removing the symbols reduced the average software update package size by about 30 percent. If debugging symbols are required, see article 814411, “Hotfix Packages Do Not Include Debug Symbol Files,” in the Microsoft Knowledge Base.

Appendix A – Package Installer Versioning and Features

Versioning

In an effort to consolidate the various installers used for product updates, many Microsoft products use the package installer for software updates.

All updates are matched and tested with current package installer functionality. Therefore, it is important not to distribute software updates using versions of the package installer other than the one it was released with, to avoid introducing errors into the environment.

Package Installer Features by Version

The following table identifies the major features added to each revision of the package installer and the approximate date it entered into production.

Table 23 - Installer Features by Version

VersionSignificant FeaturesReleased

5.3.16.5

Improved loggingUpdated removal user interfaceAbility to remove updates from recovery consoleUser-friendly Add/Remove Program entries for updatesPrintable End User Licensing Agreement (EULA)

March 2003

5.3.18.6

Warn if an installation/removal is attempted in Safe modePackages installed with /N show in Add or Remove Programs

June 2003

5.3.24.4

Integration of Application Error reporting for non-crash errorsSupport for standard (long) command-line Installer options

September 2003

5.4.15.0

Feature details for this version of the package installer can be found in the following Microsoft Knowledge Base Article:832475 Description of the new features in the package installer for Windows software updates

April 2004

6.1.22.0

Feature details for this version of the package installer can be found in the following Microsoft Knowledge Base Article:832475 Description of the new features in the package installer for Windows software updates

November 2004

Note: Some Windows Server 2003 updates were released with the package installer version 5.3.17.9. The feature set for this version is the same as that of package installer version 5.3.18.6.

Determining the Package Installer Version

After understanding what features have been added to the package installer, it is important to differentiate one Installer version from another. To determine whether a software update package uses the package installer as the Setup program, and what version it uses, follow these steps:

Right-click the package, and then click Properties.

On the Version tab, under the heading “Other Version Information”, select Installer Engine. The Value should say “update.exe”

To find out the version, select Installer Version. The Value field will show the version of the package installer used in the package. (See Figure 11)

Figure 11 – Sample Package  Installer Version

Figure 11 – Sample Package Installer Version

For packages released before July 2004, or those packages whose Description value on the General tab is Self-Extracting Cabinet, use the following steps to determine whether the package installer is used and what version it is:

Extract the software update package to a unique temporary folder. For example, to extract the files for an update package that is named KBArticleNumber.exe to a folder that is named ExtractedPackage on drive C, type the following at a command prompt:

KBArticleNumber /extract:C:\ExtractedPackage

Open the temporary folder that contains the extracted files for the software update package. For example, open C:\ExtractedPackage.

Locate the Update.exe file in the temporary folder or a subfolder.

To find the version of Update.exe, right-click the file and then click Properties.

Click the Version tab, and then note the value on the File version line. (See Figure 12.)

Figure 12 - Sample Installer Version

Figure 12 - Sample Installer Version

Appendix B – The Update.inf File

The common sections of an Update.inf file are listed below. An entry’s position in the Update.inf file is irrelevant, but there is a standard order followed by most files. In the following example the order has been changed for clarity, and examples have been taken from multiple Update.inf files. Section names are listed in bold and within brackets.

[Version]

Provides information about the range of product versions to which the update applies. This is validated against the registrykey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ CurrentBuildNumber.

RebootRequired=1

Indicates that the package should require a reboot after installation

Signature                 = "$Windows NT$"

All Windows software updates have this value.

LanguageType              = %LangTypeValue%

System language for this package. If this field is left blank or set to 0x0, this package will install on all languages. %LangTypeValue% is a variable defined in the [Strings] section.

NtBuildToUpdate           = 2600

Minimum required Windows build number (four digits) that this package applies to.

MaxNtBuildToUpdate        = 2600

Maximum required Windows build number (four digits) that this package applies to.

NtMajorVersionToUpdate    = 5

Minimum required major version number the package will apply to.

MaxNtMajorVersionToUpdate = 5

Maximum required major version number the package will apply to.

NtMinorVersionToUpdate    = 1

Minimum minor version number the package will apply to.

MaxNtMinorVersionToUpdate = 1

Maximum minor version number the package will apply to.
This example shows that the package is built for version 5.1, which corresponds to Windows XP.

MinNtServicePackVersion   = 512

Minimum Service Pack level for installation. (Number is Service Pack level * 256.)

MaxNtServicePackVersion   = 512

Maximum Service Pack level for installation. (Number is Service Pack level * 256.)
This example shows that the package applies to Service Pack 2.

ThisServicePackVersion    = 512

Used during Service Pack installations for reinstallation detection. (Number is Service Pack level * 256.)

CatalogFile               = %SP_SHORT_TITLE%.cat

Security catalog for the package.

[ProductCatalogsToInstall]
    %SP_SHORT_TITLE%.cat, update\%SP_SHORT_TITLE%.cat

Provides the name and location of the security catalog installed. The variable %SP_SHORT_TITLE% used in the following example is resolved in the [Strings] section.

[ProductInstall.XX]

These sections identify additional sections of the update.inf file that contain information about a component’s installation, and controls the processing of those sections. There are many different ProductInstall sections, including ones directing conditional installation of files and registry updates.

[ProductInstall.GlobalRegistryChanges.Install]
    AddReg=Product.Add.Reg

Identifies the section that contains registry keys to add during the installation. In this case, the entry references the [Product.Add.Reg] section, which contains the keys to be added.

[ProductInstall.GlobalRegistryChanges.ReInstall]
    AddReg=Product.Add.Reg

Identifies the section that contains registry keys to add if the update is reinstalled. In this case, the entry references the [Product.Add.Reg] section, which contains the keys to be added.

[DestinationDirs]

Provides the target directory and a pointer to the INF section containing the list of files to install. (Note: comments in the update.inf file itself are indicated after a ‘;’)

System32.files=11  ; %WINDIR%\system32 (replace if exist)
  Cache.files=65619  ; %WINDIR%\system32\DllCache (replace if exist)

In this example, the system directory is defined as %WINDIR%\system32\ and the system DLL cache directory as %WINDIR%\system32\DllCache\.

After reading the [DestinationDirs] sections, the Package Installer will retrieve the file names and location for the installation from the [System32.files] and [Cache.files] sections.

[System32.files]
  urlmon.dll,RTMGDR\urlmon.dll

Identifies the file to be copied into the system32 directory

[Cache.files]
  urlmon.dll,RTMGDR\urlmon.dll

Identifies the files to be copied into the DLL cache directory

[ProductInstall.CopyFilesAlways]
  CopyFiles=CopyAlways.System32.files
  CopyFiles=CopyAlways.Inf.files

Lists the files that should always be copied onto the system during the installation.

[ProductInstall.CopyFilesAlways.Professional]
  CopyFiles=CopyAlways.Prf.System32.files
[ProductInstall.CopyFilesAlways.Server]
  CopyFiles=CopyAlways.Srv.System32.files
  CopyFiles=CopyAlways.Srv.Inf.files

Defines the files to install in all cases by platform name; notice the platform name at the end of the section name (Professional and Server in the examples above).

[ProductInstall.ReplaceFilesIfExist]
  CopyFiles=System32.files
  CopyFiles=Cache.files

Identifies files to replace if they already exist on the computer. The actual details of the files to copy are contained in separate sections identified by the CopyFiles directives. In this case, it references two sections to identify the files to copy: [System32.files] and [Cache.files].

[Save.Reg.For.Uninstall]
HKLM,SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%
HKLM,SOFTWARE\Microsoft\Updates\WindowsXP\SP%SERVICE_PACK_NUMBER%\%SP_SHORT_TITLE%

Lists registry keys and values that should be archived during the installation and restored during the software update removal process.

[Product.Add.Reg]

Lists the registry keys to be added when the update is installed. There can be multiple [*.Del.Reg] sections which control deletion of registry entries based on Windows SKU or other parameters.

HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Setup", "LogLevel", 0x10001, 0

Provides the logging level for Setupapi.log or Updspapi.log

HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%SP_SHORT_TITLE%",
"ParentKeyName",0x00000000,"OperatingSystem"
    
HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%SP_SHORT_TITLE%",
"ParentDisplayName",0x00000000,"%PARENT_DISPLAY_NAME%"

These keys are used for the Add or Remove Programs entry. See Add or Remove Programs Registry Key for details.

[Product.Del.Reg]
    HKCR,".doc\WordPad.Document.1\ShellNew","FileName"

Lists registry keys to delete during installation. There can be multiple [*.Del.Reg] sections which control deletion of registry entries based on Windows SKU or other parameters.

[ArchiveCatalogFilesOnly]
    %SP_SHORT_TITLE%.cat

Defines the name of the catalog file to archive in the backup directory. The variable %SP_SHORT_TITLE% is resolved in the [Strings] section.

[SourceDisksNames]
    1=%ServicePackSourceFiles%

Identifies the distribution disk(s) or CD-ROM disk(s) that contain the source files to be transferred to the target computer during installation; if there are multiple installation disks, there will be multiple entries. In the example, the disk ID is 1 and the description is contained in %ServicePackSourceFiles%, which is defined in the [Strings] section.

[SourceDisksFiles]
  RTMGDR\mshtml.dll=1
  RTMGDR\shdocvw.dll=1
  RTMGDR\urlmon.dll=1

Names the source files to install and identifies the disk where those files can be found. The source disk info comes from the [SourceDiskNames] section.

[UninstallSections]
    GlobalRegistryChanges, GlobalRegistryChanges.UnInstall
    Add.Reg, Add.Reg.Uninstall
    Del.Reg, Del.Reg.Uninstall

Since software update removal, which is handled by spuninst.exe, is also .inf driven, the spuninst.inf file is created during installation automatically by the package installer, so that spuninst.exe can successfully remove the update. This section identifies sections to copy from the update.inf to the spuninst.inf during installation.

[Strings]

Defines the strings and other values used elsewhere in the update.inf file

BUILDTIMESTAMP=20030914.180726

Date and time this package was built

ServicePackSourceFiles=”Windows Server 2003 Hotfix Source Files”

See [SourceDiskNames] section above.

SP_SHORT_TITLE=”KB828750”

The Microsoft Knowledge Base article number for the software update

SP_TITLE=”Windows Server 2003 Hotfix - KB 828750”

The official title of the software update

SERVICE_PACK_NUMBER=1

Indicates the desired Service Pack number in which the update will be included. This is a required entry for simple updates, but not for service packs.

ProxyRegKey=SYSTEM\CurrentControlSet\Services\WSPSrv\Parameters
IeRegKey=Software\Microsoft\Windows\CurrentVersion\App Paths\iexplore.exe

Registry keys used elsewhere in the update.inf file

[LinkItems.Create.Uninstall]

Used to create desktop shortcuts as part of software update removal

[GlobalRegistryChanges.UnInstall]
    AddReg=Add.Reg
    DelReg=Del.Reg

Registry changes for software update removal

[Del.Reg.Uninstall]

Delete registry keys during software update removal

[Add.Reg.Uninstall]

Add registry keys during software update removal

[DirectoryId.Include]

Determines the installation location at runtime.

AddDirId = RISAdm.DirId

In this example, AddDirID points to the [RISAdm.DirID] section later in the .inf file.

[RISAdm.DirId]
  DirId = 65625
  CustomFunction = SpCustom.dll,GetRISAdminPathName
  InstallFromSection = RISAdminSection
  CopyFlags = SP_COPY_FORCE_NEWER | SP_COPY_REPLACEONLY

The [RIDAdm.DirID] section identifies what to run; in this case, it is a function in the SPCustom.dll RISAdminSection.

[Configuration]

Required section which appears last in an .inf file by convention. It defines information critical to the installation of the package.

noPNPfiles=1

Disables the OEM file detection (for performance) for packages that don’t overwrite OEM files.

InstallationType        = Hotfix

Indicates package installation mode (simple update vs. Service Pack). Here, hotfix implies that the package should be installed as a simple update.

InstallLogFileName      = %SP_SHORT_TITLE%.log
    UnInstallLogFileName    = %SP_SHORT_TITLE%Uninst.log

Name of the log files for installation and removal

UnInstallDirName        = $NtUninstall%SP_SHORT_TITLE%$

Name of the backup directory

EventLogKeyName         = NtServicePack
    EventLogDllName         = spmsg.dll

Event log information

[Prerequisite]

Indicates conditions that must be met for software update installation to proceed. Each condition will have its own section in update.inf

condition=SingleOp,OnACPower.Section
[OnACPower.Section]
    EqualOp=CheckCustom,,spcustom.dll,OnACPower,,"==", 1
    Display_String=%NotOnACPowerMsg%

This section defines the condition listed in the [Prerequisites] section above. This comes from the update.inf file for Windows XP Service Pack 2, where installation performed a check to ensure the computer being updated was running on AC power.

[ProductInstall.Conditional]

Indicates conditions that must be met for installing specific files.

FileCondition=WindowsMessenger.Condition
[WindowsMessenger.Condition]
    InstallFromSection=WindowsMessenger.Files
    Operation=CustomFunction,spcustom.dll,IsWMUpgradeable
    CopyFlags=SP_COPY_NEWER_OR_SAME

Defines the conditions that must be met for Windows Messenger file copies. The section below, [WindowsMessenger.Files], lists the file groups and operations to perform on these groups.

[WindowsMessenger.Files]
    DelFiles=Program_files.messenger.conditional.Delfiles
    CopyFiles=program_files.messenger.conditional
    CopyFiles=program_files.messenger.inf.conditional

Lists the file groups and operations to perform on these groups for the installation conditions.

[Register.Include]

Supports conditional registry updates during installation. Each condition listed in this section has a corresponding section which describes the conditional operations.

RegCondition=WM.Reg.Install.Condition
[WM.Reg.Install.Condition]
    InstallFromSection=WMSection
    Operation=CustomFunction,spcustom.dll,IsWMUpgradeable
    TargetFromSection=program_files.messenger.conditional

Defines the conditions that must be met for Windows Messenger file registry operations.

[DEVICEID.EXCLUSIONS]
    bth\ms_bthbrb
    bth\ms_rfcomm

Identifies third party drivers to overwrite during installation

[PROVIDER.EXCLUSIONS]
    Microsoft

Identifies a list of providers to be excluded from the third party device check.

[OEMDriver.Exclusions]

The list of drivers that can override the OEM file check. Also includes a flag that determines whether the user is warned when an OEM file is overwritten.

[ProcessesToRun] and [ProcessesToRun.XXX]

Processes to run after all other INF sections have been executed. There are multiple sections that control when during installation these processes should be run, as well as which Windows SKU on which to run these processes (for example, on Professional machines only, etc.)

"%SystemRoot%\Microsoft.NET\Framework\v1.0.3705\copy2gac 
/i /a /p:"""%16427%\microsoft shared\ink\1.7\""""
[DeviceClassList]
    bluetooth={e0cbf06c-cd8b-4647-bb8a-263b43f0f974}

List of device groups, where each item in the group is installed and configured in the same manner. For more information, see the Windows DDK.

[DevicesToUpgrade]
    *PNP0103 = machine.inf
    PCI\VEN_1022&DEV_7451 = machine.inf

Lists devices to upgrade during installation.

[ArchiveCatalogFilesOnly]

Lists security catalog files to archive in the backup directory.

tabletpc.cat
    comctl.cat
    netfx.cat
[WatsonManifestMode.Cancel]
    InvokeWatsonManifest=1
    Version=131072
    EventType="UpdateCancel"
    Main_Intro_Reg = %MainCancelIntroString%
    Main_DetailsLink = %MainCancelDetailsLink%
    Main_ReportBtn = %MainCancelReportBtn%
    Details_Post_Header = %DetailsCancelHeader%
    Details_Post_Body=%DetailsCancelBody%

Required entries for Application Error Reporting feature. For details see Application Error Reporting

Appendix C – Detailed Package Installer Process Flow

Figure 13 – Detailed Installation Procedure

Figure 13 – Detailed Installation Procedure

Figure 13 – Detailed Installation Procedure

Figure 13 – Detailed Installation Procedure

Figure 13 – Detailed Installation Procedure

Figure 13 – Detailed Installation Procedure

Figure 13 – Detailed Installation Procedure

Figure 13 – Detailed Installation Procedure

Figure 14 – Windows XP Service Pack 2 Installation Procedure

Figure 14 – Windows XP Service Pack 2 Installation Procedure

Appendix D – Sample Package Installer Logs

For an overview of the package installer logs, see Package Installer Log Files before using this appendix.

KB######.log

The following installation log has been annotated to provide information about each entry; where there are multiple instances of the same type of entries, they have been removed for clarity. The Service Pack installation log, svcpack.log, will have very similar entries.

Package & Platform Analysis:

[KB834707.log]
1.578: 2004/11/01 06:44:25.406 (local)

The date and time the installation was performed

1.578: c:\17e19c52d072613ef9ce60500ef9612d\update\update.exe (version 6.1.16.0)

The temporary directory name and version of the package installer used

1.578: Hotfix started with following command line: /q

The package type and command-line options used to call the package. For more information, see Command-line Options.

3.031: In Function TestVolatileFlag, line 11641, RegOpenKeyEx failed with error 0x2

Known failure, see Non-Error Log Entries. 0x2 indicates a “not found” error. Since installation continues this is not a true error.

3.031: DoInstallation: CleanPFR failed: 0x2

This is sorting the PFR queue to ensure that the right versions of the files are updated. For more information, see Pending File Renames and Install Chaining. 0x2 indicates a “not found” error, which means there was nothing in the PFR queue. Since installation continues this is not a true error.

3.046: SetProductTypes: InfProductBuildType=BuildType.IP

Indicates that the system on which the update to be installed is Windows XP Professional

3.046: SetAltOsLoaderPath: No section uses DirId 65701; done.

Directory ID 65701 is used to determine an alternate path to the Operating System loader (ntldr). If there isn’t one, the package installer uses the default. If the package doesn’t have any file copies that use this Directory ID, the package installer doesn’t attempt to determine the operating system loader path.

3.109: DoInstallation: FetchSourceURL for 
c:\17e19c52d072613ef9ce60500ef9612d\update\update_SP2GDR.inf failed

Known failure, see Non-Error Log Entries. This is not an express package, and since installation continues this is not a true error.

3.109: CreateUninstall = 1,Directory = C:\WINDOWS\$NtUninstallKB834707$

Indicates that files and registry keys should be backed up and the location of the backup directory. All .dll and .inf files needed for the removal of the update will be placed in this directory.

3.125: LoadFileQueues: UpdSpGetSourceFileLocation for halaacpi.dll failed: 0xe0000102

Known failure, see Non-Error Log Entries. This package does not contain HAL files, and since installation continues this is not a true error.

3.140: BuildCabinetManifest: update.url absent

Known failure, see Non-Error Log Entries. This is not an express package, and since installation continues this is not a true error.

Inventory:

3.140: Starting AnalyzeComponents
3.140: AnalyzePhaseZero used 0 ticks

Millisecond-based timing of a process internal to the package installer. This will appear in the log many times for the different installer processes. It has been removed here for clarity.

3.140: No c:\windows\INF\updtblk.inf file.

Checking for the blocklist INF file. See Overwriting Installed Updates via Blocklists for details.

3.140: SetupFindFirstLine in LoadExclusionList Failed with error: 0xe0000102

The package installer is looking for the load exclusion list, which is the list of files to exclude from the installation. In this case, there is none.

3.140: Oem driver c:\WINDOWS\System32\DRIVERS\e100b325.sys is signed by oem0.cat and will not be replaced

Lists the OEM files that must not be overwritten during the installation.

9.062: AnalyzeComponents: Hotpatch analysis disabled; skipping.
9.062: AnalyzeComponents: Hotpatching is disabled.

Indicates that for this package, HotPatching is not applicable or has been disabled. See HotPatching for details.

9.062: FindFirstFile c:\windows\$hf_mig$\*.*

This is a check to see if there are any updates to migrate. FindFirstFile is checking for items in the %WINDIR%\$hf_mig$ folder. If this is followed by error messages with code 0x2, then the package installer is logging that it didn’t find any files to migrate. If migration is necessary, there will be log entries for each file found that will cause migration.

10.031: Downloading 0 files

This is not an express package so there were no files to download.

10.031: bPatchMode = FALSE

Indicates that this package is not an express package

10.031: Inventory complete: ReturnStatus=0, 6922 ticks

This is the return from the inventory thread (see Appendix C – Detailed Installer Process Flow for details). Return status from this function = 0, indicating success.

10.125: VerifySize: Unable to verify size: Source = NULL: c:\windows\inf\HFX3.tmp

Known failure, see Non-Error Log Entries. Since installation continues this is not a true error.

10.125: Copied file:  c:\windows\inf\branches.inf

File copy confirmation for branches.inf. See Branching for more details.

10.156: Allocation size of drive C: is 4096 bytes, free space = 7807836160 bytes

Determines free space on disk before installation of the software update.

10.156: AnalyzeDiskUsage:  Skipping EstimateDiskUsageForUninstall.

For simple update installation, the check for disk space needed to backup the files is not performed.

10.156: Drive C: free 7446MB req: 34MB w/uninstall: NOT CALCULATED.

Determines free space on disk before installation of the software update. As mentioned in the previous entry, the space required for uninstall was not calculated.

10.156: CabinetBuild complete

Informational message indicating the inventory phase is complete.

10.156: DynamicStrings section not defined or empty.

Informational message indicating the [DynamicStrings] section of the update.inf file is not present. See Appendix B – The Update.inf File for more details.

File/Registry Backup:

11.390: Registering Uninstall Program for -> KB834707, KB834707 , 0x0

Creates romoval information in registry; these are the entries used by Add or Remove Programs.

14.203: System Restore Point set.

Sets the system restore point used by the operating system to return the system to a known state.

File Copy:

14.453: GetCatVersion:  Failed to retrieve version information from 
C:\WINDOWS\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB834707.cat with error 0x57

Known failure, see Non-Error Log Entries. Since installation continues this is not a true error.

14.812: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: 
Copied c:\17e19c52d072613ef9ce60500ef9612d\spuninst.exe -> c:\windows\$hf_mig$\KB834707\spuninst.exe.
14.828: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: 
Copied c:\17e19c52d072613ef9ce60500ef9612d\spmsg.dll -> c:\windows\$hf_mig$\KB834707\spmsg.dll.

Copying installer files to the $hf_mig$ directory for the update, for later migration. See Branching for more details.

15.031: Copied file:  C:\WINDOWS\system32\wininet.dll

File copy confirmation to working directory.

15.562: Copied file (delayed):  C:\WINDOWS\system32\SET4.tmp

This is an entry being made for the Pending File Rename queue.

16.515: Copied file:  c:\windows\$hf_mig$\KB834707\SP2QFE\wininet.dll
16.593: Copied file:  c:\windows\$hf_mig$\KB834707\SP2QFE\shdocvw.dll

Copying newer versions of the files currently on the system. files to the $hf_mig$ directory for the update, for later migration. See Branching for more details.

17.140: DoInstallation: Installing assemblies with source root path: c:\17e19c52d072613ef9ce60500ef9612d\

Side by side (SxS) assemblies are installed with a different mechanism. The package installer looks for any SxS assemblies located in a folder named asms in the package. If they exist, the package installer passes the path to SxS-installation APIs which perform the file copy operations. This entry indicates Update.exe is looking for these assemblies in the root directory of the package. For more information, see Side-by-Side Assemblies in the Platform SDK documentation.

Registry Backup:

17.156: ---- Old Information In The Registry ------
17.171: Source:C:\WINDOWS\system32\SET4.tmp (6.0.2900.2508)
17.171: Destination:C:\WINDOWS\system32\wininet.dll (6.0.2900.2180)
17.187: Source:C:\WINDOWS\system32\SET5.tmp (6.0.2900.2508)
17.187: Destination:C:\WINDOWS\system32\urlmon.dll (6.0.2900.2180)

The package installer performs a check of the Pending File Renames (PFR) key to see if there are any conflicting updates and resolves them. See Pending File Renames for details. The log entries above are the PFR queue before any changes are made to resolve conflicts.

17.265: ---- New Information In The Registry ------
17.281: Source:C:\WINDOWS\system32\SET4.tmp (6.0.2900.2508)
17.281: Destination:C:\WINDOWS\system32\wininet.dll (6.0.2900.2180)
17.281: Source:C:\WINDOWS\system32\SET5.tmp (6.0.2900.2508)
17.281: Destination:C:\WINDOWS\system32\urlmon.dll (6.0.2900.2180)

These log entries are the PFR queue after changes are made to resolve conflicts. In this example, the entries are identical to the ones in the previous section, so there are no collisions in the PFR key.

Determine Reboot Status:

19.656: UpdateSpUpdSvcInf: Source [ProcessesToRunAfterReboot] section is empty; nothing to do.

Informational - The update.inf section [ProcessestoRunAfterReboot] doesn’t contain any processes.

19.656: IsRebootRequiredForFileQueue: At least one file operation was delayed; reboot is required. 
If none are listed below, check above for delayed deletes.
19.656: IsRebootRequiredForFileQueue: c:\windows\system32\wininet.dll was delayed; reboot is required.
19.656: IsRebootRequiredForFileQueue: c:\windows\system32\urlmon.dll was delayed; reboot is required.

Lists items in Pending File Rename queue and mentions that a reboot is required to replace those files.

19.671: DoInstallation: A reboot is required to complete the installation of one or more files.

Indicates that a reboot is needed to complete installation.

19.671: RebootNecessary = 1,WizardInput = 1 , DontReboot = 0, ForceRestart = 0 
Shutdown Initiated in Self Extractor

Flags returned by the Installer relating to the Installer state at finish. In this case, a restart was necessary (RebootNecessary = 1). WizardInput = 1 means that you allowed the computer to restart by not selecting the “Do not reboot now” checkbox on the last page of the Software Update Installation Wizard.

KB######uninst.log

[KB834707Uninst.log]
0.070:======================================================== 0.070: 2005/02/02 15:01:09.958 (local)

Date and time removal was performed

0.070: C:\WINDOWS\$NtUninstallKB834707$\spuninst\spuninst.exe (version 5.5.31.0)

Spuninst.exe file version

0.070: Spuninst.exe was run with the following arguments:  /u

Command line arguments passed to spuninst.exe

0.070: Spuninst.exe is being run from the following location: C:\WINDOWS\$NtUninstallKB834707$

Folder from which removal was performed. Spuninst.exe and spuninst.inf are contained in the “spuninst” subfolder.

6.930:  ---- PendingFileRenamOperations Before Uninstallation ------

Pending File Renames pending at start of install (none in this case). See Pending File Renames for details.

7.691: SetAltOsLoaderPath: No section uses DirId 65701; done.

Since we are not replacing an ntldr file with a non-standard path, there is no need to try to determine the alternate path of the operating system loader.

42.060: PFR Copy:  Copied file:  C:\WINDOWS\system32\browseui.dll
46.316: PFR Copy:  Copied file:  C:\WINDOWS\system32\mshtml.dll

File copy operation beginning. Since files are in use, a Pending File Rename entry is created for each one. See Pending File Renames for details.

52.856: Starting Registry updates
52.856: DoRegUninstall:  SetupFindFirstLine for Reg.Delete.Values failed: 0xe0000102 53.046: 
Done with Registry updates

Registry updates. Any sections that do not exist will come up with the above “error”, which is just noise. See Non-Error Log Entries for details. In this example, there are no values or keys being restored or deleted.

54.118: UpdateSpUpdSvcInf: Source [ProcessesToRunAfterReboot] section is empty; nothing to do.

If there were processes to run after restarting for the removal procedure, the package installer would create a configuration file called spupdsvc.inf. In this case there are no entries in the [ProcessesToRunAfterReboot] section.

54.138:  ---- PendingFileRenameOperations After Uninstallation ------
54.138: Source: C:\WINDOWS\system32\uninst0.tmp Version: 6.0.2900.2180
54.178: Destination: C:\WINDOWS\system32\browseui.dll Version: 6.0.2900.2518
54.178: Source: C:\WINDOWS\system32\uninst1.tmp Version: 6.0.2900.2180
54.228: Destination: C:\WINDOWS\system32\mshtml.dll Version: 6.0.2900.2523

A list of the Pending File Renames after removal. Note that this example uses the “uninst#.tmp” temp file naming scheme. Installer versions 6.1.22.0 and later will use the standard SetupAPI SET*.tmp file naming scheme. See Appendix A – Installer Versioning and Features for more details.

56.120: DeRegistering the Uninstall Program -> KB834707, 0

Remove the update’s entry from the Add or Remove Programs utility. See Add or Remove Programs Registry Key for details.

56.541: DontReboot = 0, ForceRestart = 0

The removal operation was not started with either the /noreboot or /forcerestart command-line options. See Command-line Options for details.

Spupdsvc.log

There will be multiple entry groups for each process that was run. The error code returned is a standard Windows error code.

Sample log entry group:

5.578: [PerformInfInstructions] Running - C:\WINDOWS\system32\spnpinst.exe ...
5.594: [RunProcess] called with C:\WINDOWS\system32\spnpinst.exe
5.594: [IsPointsToExecutable] called with C:\WINDOWS\system32\spnpinst.exe
5.625: [IsPointsToExecutable] checking for the presence of C:\WINDOWS\system32\spnpinst.exe
5.625: [IsPointsToExecutable] C:\WINDOWS\system32\spnpinst.exe exists in C:\WINDOWS\system32
5.750: [RunProcess] calling CreateProcess for C:\WINDOWS\system32\spnpinst.exe
5.828: [RunProcess] CreateProcess Succeeded
26.828: [RunProcess] Process spawned returned error. Process: 
C:\WINDOWS\system32\spnpinst.exe, Exitcode: 0x80070005
26.922: [PerformInfInstructions] Done. Return code: 0

Appendix E – Extended Return Codes and Setup API Error Codes

Many of the extended return code messages have parts of their text inserted at runtime. The Message column in Table 19 shows the messages. The text to be inserted into the message may represent a language, an operating system version, a KB article number, or drive, etc. Whenever there is text to insert into the message, it will be identified by a % followed generally by a number or characters. When reading the following messages, take into consideration that there may be some words missing from text.

Return CodeReturn Code NameMessage

61441

STATUS_FAILED_LANGUAGE_TYPE

Setup cannot update your %1 files because the language installed on your system is different from the update language.

61442

STATUS_CHECKED_FREE_MISMATCH

%1 Setup cannot update a checked (debug) system with a free (retail) version of %2.

61443

STATUS_NOT_ENOUGH_SPACE

There is not enough disk space on %%s to install %1. Setup requires a minimum of %%d additional megabytes of free space or if you also want to archive the files for uninstallation. Setup requires %%d additional megabytes of free space. Free additional space on your hard disk and then try again.

61444

STATUS_INSUFFICIENT_PRIVS

You do not have permission to update %1.

61445

STATUS_UNKNOWN_PRODUCT_TYPE

none

61446

STATUS_SETUP_LOG_NOT_FOUND

Setup could not find the setup.log file in your repair directory.

61447

STATUS_CANT_FIND_INF

Setup could not find the update.inf file needed to update your system.

61448

STATUS_UPDATE_SUCCESSFUL

%1 has been updated. Remove any disks from the floppy disk drives and choose OK to restart your computer. If you change or add any components to your system, you will need to reapply the Hotfix.

61449

STATUS_UPDATE_UNSUCCESSFUL

%1 installation did not complete.

61450

STATUS_SHUTDOWN_UNSUCCESSFUL

%1 Setup was unable to shutdown system. Please shutdown your system manually.

61451

STATUS_FILE_NOT_FOUND_IN_SETUP_LOG

Could not locate entry for HAL.DLL in SETUP.LOG to determine type of HAL to update.

61452

STATUS_INVALID_INF_FILE

The %1 %2 file is not correct.

61453

STATUS_USER_CANCELLED

%1 Setup canceled.

61454

STATUS_PLATFORM_MISMATCH

This %1 is for a different hardware platform.

61472

STATUS_BUILD_VERSION_MISMATCH

Setup has detected that the build version of the system installed does not match the update you are applying to it. You can only install this update on Build %d to Build %d.

61473

STATUS_SP_VERSION_GREATER

The version of Windows you have installed does not match the update you are trying to install.

61474

STATUS_CANT_SPAWN_HOTFIX

%1 Setup could not start the hotfix installation program.

61475

STATUS_CANT_FIND_TAG

%1 Setup could not locate the %2 files.

61476

STATUS_OVERWRITE_UNINSTALL

WARNING: You have chosen to overwrite your existing uninstall: %s If you continue, you will only be able to uninstall to the following Service Pack version: %s Are you sure you want to continue? Click Yes to continue creating the uninstall, No to not create the uninstall.

61477

STATUS_128BIT_VERSION_DETECTED

none

61478

STATUS_WININET_LOAD_FAILED

This Web-based update requires Internet Explorer 3.0 or later. For instructions on how to download a version of this update that does not require a Web connection during installation download and install %1 from http://www.Microsoft.com/Downloads

61479

STATUS_CANT_INSTALL_SP_ON_DTC

This %1 has not been qualified by your hardware vendor for installation on this copy of %2 Datacenter Server. Please contact your hardware vendor for additional information about obtaining a %3 that has been qualified for your system configuration.

61480

STATUS_NECESSARY_FILES_NOT_PRESENT

Not all files necessary to perform an integrated installation are present.

61481

STATUS_SPOOLER_NOT_STARTED

Cannot install %1. The Print Spooler service is not started.

61482

STATUS_MUST_RESTART_FIRST

The system must be restarted before installing the %1 to allow some prior file update operations to complete. (These operations were previously scheduled by some other install or uninstall operation.)

61483

STATUS_NOT_ENOUGH_WITH_UNINST

You do not have enough free disk space on %%s to archive the uninstall files. To install %1 with backup files for uninstall an additional %%dMB is required.

61484

STATUS_CANT_FIND_RSAENHS

Unable to locate RSAENHS.DLL in the update directory high encryption for uninstall aborted.

61485

STATUS_CANT_FIND_ENCININF

Unable to locate UPDENCIN.INF in the update directory, high encryption for uninstall aborted.

61486

STATUS_CANT_FIND_ENCTSINF

Unable to locate UPDENCTS.INF in the update directory, unable to export TS files.

61487

STATUS_ENCINST_PROCESS_FAILED

High encryption ENCINST process failed.

61488

STATUS_ENCINST_UPGRADE_FAILED

High encryption upgrade failed.

61530

STATUS_CANT_OPEN_LOG

Error opening %1 file

61537

ERR_STD_PREFIX

none

61540

STATUS_INVALID_VER_FILE

The update.ver file is not correct.

61546

STATUS_SP_VERSION_GREATER_1

Setup has detected that the Service Pack version of the system installed is newer than the update you are applying to it. You can only install this update on Service Pack %d.

61547

STATUS_SP_VERSION_GREATER_2

Setup has detected that the Service Pack version of this system is newer than the update you are applying. There is no need to install this update.

61548

STATUS_FPNW_FIXUP_FAILED

Setup failed to access or correctly modify your SETUP.LOG file.

61549

STATUS_WRONG_PLATFORM

The version of software you are running does not match the system you are running it on.

61550

STATUS_FAILURE_COPYING_FILES

Failed to completely copy all of the updated files.

61551

STATUS_FAILED_TO_SET_DIR

Failed to set the directory.

61552

STATUS_SETUP_ERROR

An error in updating your system has occurred.

61553

STATUS_RUNNING_DS_PREVIEW

None

61554

STATUS_RUNNING_HYDRA

None

61555

STATUS_RUNNING_STEELHEAD

None

61556

STATUS_HOTFIX_ALREADY_INSTALLED

None

61557

STATUS_SUCCESS_NOREBOOT

%1 has been updated. You must reboot for these changes to take effect. If you change or add any components to your system, you will need to reapply the Hotfix.

61558

STATUS_SP_VERSION_LESSER

Setup has detected that the version of the Service Pack installed on your system is lower than what is necessary to apply this hotfix. At minimum, you must have Service Pack %d installed.

61559

STATUS_NOT_RUNNING_STEELHEAD

none

61560

STATUS_NO_UNINSTALL_AVAILABLE

You cannot uninstall, since an uninstall for %1 has not been created.

61561

STATUS_NOT_RUNNING_HYDRA

none

61562

STATUS_SUCCESS_NOREBOOTNEC

%1 has been updated. If you change or add any components to your system, you will need to reapply the Hotfix.

61563

STATUS_UNINST_NOREBOOTNEC

%1 Hotfix successfully uninstalled.

61638

STATUS_BUILD_VERSION_MISMATCH2

Setup has detected that the build version of the system installed does not match the update you are applying to it. You can only install this update only on Build %d.

61643

STATUS_VLK_BLOCKED

%1 %2 cannot install. The product key used to install Microsoft Windows may not be valid. For more information about why you have received this error message, and steps you can take to resolve this issue, see” How to Tell” at the following Microsoft Web site: http://www.microsoft.com/resources/howtotell/ww/default.mspx.

61644

STATUS_KERNEL_NONSTD

The core system file (kernel) used to start this computer is not a Microsoft Windows file. The Service Pack will not be installed. For more information, see Knowledge Base article %s at http://support.microsoft.com.

61663

STATUS_SP_BUILD_TO_BUILD

This Service Pack cannot be installed on top of the %1 build currently installed on your computer. Cancel this installation process, uninstall your current %2 build, then re-install this Service Pack.

61668

STATUS_WINDOWS_VERSION_NEWER

The version of Windows you have installed is newer than the update you are trying to install. There is no need to install this update.

61669

STATUS_PACKAGE_NOT_APPLICABLE

This package does not apply to the operating system you are running and therefore cannot be installed.

61672

STATUS_INVALID_BRANCHES_INF

The branches.inf file is invalid.

61673

STATUS_INVALID_UPDATEBR_INF

The updatebr.inf file is invalid.

61675

STATUS_REPEAT_INVENTORY

none

61677

STATUS_NO_BRANCH_AVAILABLE

Required installation branch was not found in INF file.

61681

STATUS_INCOMPARABLE_BRANCHES

Files from the package are incompatible with files on your system.

61684

STATUS_PREREQUISITE_FAILED

Setup cannot continue because one or more prerequisites required to install %1 failed. For More details check the Log File %2

61686

STATUS_INVALID_SWITCHES

none

61709

STATUS_BUILD_VERSION_MISMATCH_NO_MAXBLD

none

61710

STATUS_BUILD_VERSION_MISMATCH_NO_MAXVER

none

61711

STATUS_BUILD_VERSION_MISMATCH_MAXBLD_MAXVER

none

61712

STATUS_CANT_SET_DIRID

none

61713

STATUS_INVALID_DIRID_SECTION

none

61714

STATUS_NOSUCHDIRID_SECTION

none

61715

STATUS_INVALID_INSTALL_PATH

none

61716

STATUS_INVALID_COPYFLAG

none

61717

STATUS_UNABLE_TO_SET_DIRID

none

61718

STATUS_INVALID_DIRID_PATH

none

61719

STATUS_BUILD_TYPE_NOT_DETERMINED

none

61952

STATUS_MORE_FILES_FOR_DOWNLOAD

none

61953

STATUS_READY_TO_INSTALL

none

61954

STATUS_PATCH_NOT_FOUND

none

61955

STATUS_PATCH_FILE_CORRUPT

none

61956

STATUS_INDEXFILE_CORRUPT

none

61957

STATUS_UPDATE_ALREADY_RUNNING

none

61958

STATUS_RETRY_REFRESH_INVENTORY

To complete installation of %1, Setup requires an additional download. Please install %1 again.

61959

STATUS_RETRY_SELF_CONTAINED

none

61960

STATUS_RETRIES_EXCEEDED

none

61961

STATUS_CONTINUE_INVENTORY

none

61962

ERROR_INDEXFILE_NOT_FOUND

none

62474

STATUS_UNINSTALL_UNSUCCESSFUL

none

62475

STATUS_COMPLETE

none

62475

STATUS_UNINSTALL_COMPLETE

none

62476

STATUS_COMPLETE_NOREBOOT

none

62477

STATUS_COMPLETE_NORESTART_REQD

none

62478

STATUS_NEW_IE

none

62480

STATUS_UNINSTALL_OUT_OF_ORDER

none

Table 24- Extended Return Codes

Setup API Error Codes

These errors may be found in setupapi.log or updspapi.log.

Inf Parsing

0xe0000000

ERROR_EXPECTED_SECTION_NAME

0xe0000001

ERROR_BAD_SECTION_NAME_LINE

0xe0000002

ERROR_SECTION_NAME_TOO_LONG

0xe0000003

ERROR_GENERAL_SYNTAX

INF Runtime

0xe0000100

ERROR_WRONG_INF_STYLE

0xe0000101

ERROR_SECTION_NOT_FOUND

0xe0000102

ERROR_LINE_NOT_FOUND

0xe0000103

ERROR_NO_BACKUP

Device Installer/Other

0xe0000200

ERROR_NO_ASSOCIATED_CLASS

0xe0000201

ERROR_CLASS_MISMATCH

0xe0000202

ERROR_DUPLICATE_FOUND

0xe0000203

ERROR_NO_DRIVER_SELECTED

0xe0000204

ERROR_KEY_DOES_NOT_EXIST

0xe0000205

ERROR_INVALID_DEVINST_NAME

0xe0000206

ERROR_INVALID_CLASS

0xe0000207

ERROR_DEVINST_ALREADY_EXISTS

0xe0000208

ERROR_DEVINFO_NOT_REGISTERED

0xe0000209

ERROR_INVALID_REG_PROPERTY

0xe000020A

ERROR_NO_INF

0xe000020B

ERROR_NO_SUCH_DEVINST

0xe000020C

ERROR_CANT_LOAD_CLASS_ICON

0xe000020D

ERROR_INVALID_CLASS_INSTALLER

0xe000020E

ERROR_DI_DO_DEFAULT

0xe000020F

ERROR_DI_NOFILECOPY

0xe0000210

ERROR_INVALID_HWPROFILE

0xe0000211

ERROR_NO_DEVICE_SELECTED

0xe0000212

ERROR_DEVINFO_LIST_LOCKED

0xe0000213

ERROR_DEVINFO_DATA_LOCKED

0xe0000214

ERROR_DI_BAD_PATH

0xe0000215

ERROR_NO_CLASSINSTALL_PARAMS

0xe0000216

ERROR_FILEQUEUE_LOCKED

0xe0000217

ERROR_BAD_SERVICE_INSTALLSECT

0xe0000218

ERROR_NO_CLASS_DRIVER_LIST

0xe0000219

ERROR_NO_ASSOCIATED_SERVICE

0xe000021A

ERROR_NO_DEFAULT_DEVICE_INTERFACE

0xe000021B

ERROR_DEVICE_INTERFACE_ACTIVE

0xe000021C

ERROR_DEVICE_INTERFACE_REMOVED

0xe000021D

ERROR_BAD_INTERFACE_INSTALLSECT

0xe000021E

ERROR_NO_SUCH_INTERFACE_CLASS

0xe000021F

ERROR_INVALID_REFERENCE_STRING

0xe0000220

ERROR_INVALID_MACHINENAME

0xe0000221

ERROR_REMOTE_COMM_FAILURE

0xe0000222

ERROR_MACHINE_UNAVAILABLE

0xe0000223

ERROR_NO_CONFIGMGR_SERVICES

0xe0000224

ERROR_INVALID_PROPPAGE_PROVIDER

0xe0000225

ERROR_NO_SUCH_DEVICE_INTERFACE

0xe0000226

ERROR_DI_POSTPROCESSING_REQUIRED

0xe0000227

ERROR_INVALID_COINSTALLER

0xe0000228

ERROR_NO_COMPAT_DRIVERS

0xe0000229

ERROR_NO_DEVICE_ICON

0xe000022A

ERROR_INVALID_INF_LOGCONFIG

0xe000022B

ERROR_DI_DONT_INSTALL

0xe000022C

ERROR_INVALID_FILTER_DRIVER

0xe000022D

ERROR_NON_WINDOWS_NT_DRIVER

0xe000022E

ERROR_NON_WINDOWS_DRIVER

0xe000022F

ERROR_NO_CATALOG_FOR_OEM_INF

0xe0000230

ERROR_DEVINSTALL_QUEUE_NONNATIVE

0xe0000231

ERROR_NOT_DISABLEABLE

0xe0000232

ERROR_CANT_REMOVE_DEVINST

0xe0000233

ERROR_INVALID_TARGET

0xe0000234

ERROR_DRIVER_NONNATIVE

0xe0000235

ERROR_IN_WOW64

0xe0000236

ERROR_SET_SYSTEM_RESTORE_POINT

0xe0000237

ERROR_INCORRECTLY_COPIED_INF

0xe0000238

ERROR_SCE_DISABLED

0xe0000239

ERROR_UNKNOWN_EXCEPTION

0xe000023A

ERROR_PNP_REGISTRY_ERROR

0xe000023B

ERROR_REMOTE_REQUEST_UNSUPPORTED

0xe000023C

ERROR_NOT_AN_INSTALLED_OEM_INF

0xe000023D

ERROR_INF_IN_USE_BY_DEVICES

0xe000023E

ERROR_DI_FUNCTION_OBSOLETE

0xe000023F

ERROR_NO_AUTHENTICODE_CATALOG

0xe0000240

ERROR_AUTHENTICODE_DISALLOWED

0xe0000241

ERROR_AUTHENTICODE_TRUSTED_PUBLISHER

0xe0000242

ERROR_AUTHENTICODE_TRUST_NOT_ESTABLISHED

0xe0000243

ERROR_AUTHENTICODE_PUBLISHER_NOT_TRUSTED

0xe0000244

ERROR_SIGNATURE_OSATTRIBUTE_MISMATCH

0xe0000245

ERROR_ONLY_VALIDATE_VIA_AUTHENTICODE

Table 25- Setup API Error Codes

Click the link below for return codes and error messages returned by the Windows Installer:

Windows Installer Errors Reference

Appendix F – Relevant Knowledge Base Articles

824684 Description of the standard terminology that is used to describe Microsoft software updates

202071 PRB: Troubleshooting MoveFileEx() MOVEFILE_DELAY_UNTIL_REBOOT

810077 How to Suppress the Warning That Appears When You Install SP3 on a Computer on Which Previous Versions of Post-SP3 Hotfixes Are Installed

309601 Some Windows 2000 Hotfixes May Cause a Conflict with Service Pack 3 (SP3) for Windows 2000

328848 Description of Dual Mode Hotfix Packages for Windows XP

824994 Description of the Contents of a Windows Server 2003 Product Update Package

830846 Windows product updates may stop responding or may use most or all the CPU resources

296861 How to install multiple Windows updates or hotfixes with only one reboot

815062 The correct file is not installed when you chain multiple hotfixes

828930 How to integrate software updates into your Windows installation source files

278503 Best Practices for using update.msi to deploy Service Packs

282784 Qfecheck.exe verifies the installation of Windows 2000 and Windows XP hotfixes

304864 Qfecheck hotfix tool reports false need to reinstall freshly installed hotfixes

823836 Removing Windows software updates in the wrong order may cause the operating system to stop functioning

888791 The user rights that are required by update.exe

830846 Windows Product Updates may stop responding or may use most or all the CPU resources

814411 Hotfix Packages Do Not Include Debug Symbol Files

832475 Description of the new features in the package installer for Windows software updates

810766 White Paper: Software Deployment Using Windows 2000 and Systems Management Server 2.0

827227 How to use a Visual Basic script to install the 824146 (MS03-039) or 823980 (MS03-026) security patch on remote host computers

262841 Command-Line switches for Windows software update packages

184305 How to Install and Remove Hotfixes with HOTFIX.EXE

197147 Command-Line switches for IExpress software update packages

Command Line Switches for Windows Installer

Windows Update Services

How to Use Sysprep: An Introduction

Setup API Reference


 

© 2007 Microsoft Corporation. All rights reserved. Terms of Use |Trademarks |Privacy Statement
Microsoft