Heath Stewart's Blog

Installation sequence restrictions for multi-package transactions

Windows Installer 4.5 introduced a feature to install multiple packages in a single transaction. Multi-package transactions allow setup developers to install multiple packages as an atomic unit that are installed together, or rolled back completely. You can also apply patches to multiple products or even repair multiple products – any maintenance mode installation – within a single transaction. Installation scripts are not merged but executed in the order that packages are installed, and commit actions are deferred till the very end.

There is an installation sequence restriction, however: if you are installing both 32- and 64-bit packages – marked in the Template summary property of an MSI package – you must install the 64-bit packages first before the 32-bit packages.

Within a single transaction, if you install a 32-bit package and then a 64-bit package, any attempts to install files to 64-bit directories like ProgramFiles64Folder will be redirected as highlighted below.

    ******* Product: x86.msi

MSI (s) (3C:4C) [22:35:38:008]: Running installation inside multi-package transaction MultiMsi 

MSI (s) (3C:F4) [22:35:45:821]: Target path resolution complete. Dumping Directory table...
MSI (s) (3C:F4) [22:35:45:822]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (3C:F4) [22:35:45:831]: Dir (target): Key: TARGETDIR    , Object: C:\
MSI (s) (3C:F4) [22:35:45:831]: Dir (target): Key: ProgramFilesFolder    , Object: C:\Program Files (x86)\
MSI (s) (3C:F4) [22:35:45:841]: Dir (target): Key: ManufacturerDir    , Object: C:\Program Files (x86)\Heath Stewart\
MSI (s) (3C:F4) [22:35:45:849]: Dir (target): Key: INSTALLLOCATION    , Object: C:\Program Files (x86)\Heath Stewart\MultiMsi (x86)\ 

    ******* Product: x64.msi

MSI (s) (3C:4C) [22:35:48:404]: Running installation inside multi-package transaction MultiMsi 

MSI (s) (3C:38) [22:35:48:793]: WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in 'C:\Program Files\' folder path. (mask argument = 0, the folder pair's iSwapAttrib member = 0).
MSI (s) (3C:38) [22:35:48:793]: PROPERTY CHANGE: Modifying ProgramFiles64Folder property. Its current value is 'C:\Program Files\'. Its new value: 'C:\Program Files (x86)\'.

MSI (s) (3C:38) [22:35:48:797]: Target path resolution complete. Dumping Directory table...
MSI (s) (3C:38) [22:35:48:798]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (3C:38) [22:35:48:799]: Dir (target): Key: TARGETDIR    , Object: C:\
MSI (s) (3C:38) [22:35:48:799]: Dir (target): Key: ProgramFiles64Folder    , Object: C:\Program Files (x86)\
MSI (s) (3C:38) [22:35:48:800]: Dir (target): Key: ManufacturerDir    , Object: C:\Program Files (x86)\Heath Stewart\
MSI (s) (3C:38) [22:35:48:801]: Dir (target): Key: INSTALLLOCATION    , Object: C:\Program Files (x86)\Heath Stewart\MultiMsi (x64)\

You can see the Windows Installer is redirecting ProgramFiles64Folder to ProgramFilesFolder. Files intended for 64-bit locations end up in 32-bit locations. However, if you reverse the sequence of packages to install the 64-bit package first before the 32-bit package, the directories are resolved correctly as shown below.

    ******* Product: x64.msi

MSI (s) (F4:CC) [22:39:19:277]: Running installation inside multi-package transaction MultiMsi

MSI (s) (F4:70) [22:39:21:325]: Target path resolution complete. Dumping Directory table...
MSI (s) (F4:70) [22:39:21:353]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (F4:70) [22:39:21:361]: Dir (target): Key: TARGETDIR , Object: C:\
MSI (s) (F4:70) [22:39:21:375]: Dir (target): Key: ProgramFiles64Folder , Object: C:\Program Files\
MSI (s) (F4:70) [22:39:21:407]: Dir (target): Key: ManufacturerDir , Object: C:\Program Files\Heath Stewart\
MSI (s) (F4:70) [22:39:21:430]: Dir (target): Key: INSTALLLOCATION , Object: C:\Program Files\Heath Stewart\MultiMsi (x64)\ 

    ******* Product: x86.msi

MSI (s) (F4:CC) [22:39:25:502]: Running installation inside multi-package transaction MultiMsi

MSI (s) (F4:FC) [22:39:25:896]: Target path resolution complete. Dumping Directory table...
MSI (s) (F4:FC) [22:39:25:896]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (F4:FC) [22:39:25:897]: Dir (target): Key: TARGETDIR , Object: C:\
MSI (s) (F4:FC) [22:39:25:898]: Dir (target): Key: ProgramFilesFolder , Object: C:\Program Files (x86)\
MSI (s) (F4:FC) [22:39:25:898]: Dir (target): Key: ManufacturerDir , Object: C:\Program Files (x86)\Heath Stewart\
MSI (s) (F4:FC) [22:39:25:899]: Dir (target): Key: INSTALLLOCATION , Object: C:\Program Files (x86)\Heath Stewart\MultiMsi (x86)\

To install components into their right directories, you must install 64-bit packages first before 32-bit packages. If you have a functional requirement to install the 32-bit packages first you must do so in a separate transaction and simulate rollback yourself: you must uninstall packages from previous transactions.

How to workaround the issue when opening Office applications repairs Visual Studio

Microsoft Visual Studio 2010 Beta 1 customers have been reporting that when they start Outlook or any of the Office applications, VS2010 is repaired. This issue can also happen for VS2005 and VS2008, and for any products using Visual Basic for Applications (VBA).

Besides being an annoyance and potentially taking a while to complete, the repair attempt can prompt for source. Picking the right source may not always be obvious from the dialog caption especially if it is truncated. And all the while Outlook or whichever application you started is probably waiting to finish starting up.

Even if you successfully complete the repair operation, this issue may continue each time you start the same application.

How to workaround this issue

Windows Installer logs an event that describes the requested feature and which product it is repairing. For this simple workaround, you need to find the latest event log entry. Using information in that event log entry, you’ll remove and re-add a feature and all its components into directory that should always be available.

1. Click on Start
2. Click on Run
3. Type “eventvwr” (without quotes) and click OK. If you are prompted to elevated on Vista or newer, click Continue.
4. Expand Windows Logs and click Application
5. Find the recent warning where the Source is MsiInstaller. In Vista and newer,
   1. Click Filter Current Log… in the right action pane
   2. Check Warning
   3. Type “MsiInstaller” (without quotes) in the Event sources edit control
   4. Type “1001” (without quotes) in the event IDs edit control
   5. Click OK

You should see a message similar to the follow,

Detection of product '{316EE0C1-DB94-30BA-95E6-F4959035EE4B}', feature 'VB_for_VS_7_Ent_28_x86_enu' failed during request for component '{DD68FEE8-C369-11D1-A173-00A0C90AB50F}'

I've also attached an event viewer filter you can unzip and import as a custom view.

Keep the log viewer open with the recent warning of type 1001 and open an elevated command prompt.

• On XP as an administrator,
  1. Click on Start
  2. Click on Run
  3. Type “cmd” (without quotes) and click OK
• On Vista and newer.
  1. Click on Start
  2. Type “Command Prompt” (without quotes)
  3. Right click on Command Prompt and click Run as administrator. If you are prompted to elevated, click Continue.

You’ll now use the information in the warning message to run two commands consecutively. The first command removes the feature, and the second command reinstalls it locally. The reason you need to do this for this simple workaround is explained in detail below. Use the GUID after “product” along with the feature name as shown in the corresponding example below.

start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\1.remove.log" REMOVE=VB_for_VS_7_Ent_28_x86_enu
start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\2.addlocal.log" ADDLOCAL=VB_for_VS_7_Ent_28_x86_enu TARGETDIR="%ProgramFiles%\Microsoft Visual Studio 10.0"

You will likely be prompted for your installation media when running the second command, so be sure to have your installation DVD loaded or ISO mounted. If you installed from the web or your media is not available, you will be prompted to download the media from the web.

How to avoid this issue

If you have any external drives connected to your machine, consider disconnecting them when installing Visual Studio or make sure that they are plugged in when starting applications like Outlook if you have any add-ins for those applications installed.

Description of the issue

Some components in Visual Studio are authored to support advertised installations. By default, advertised components will not be installed until they are needed. For COM servers, Windows Installer writes encoded data to the server library registry value like InProcServer32. This information contains information about the product and feature that will install the component. Windows Installer will always trigger a health check when advertised data is present for COM objects since, inherently, the COM server path isn’t registered.

Even though the feature that installs these components is typically installed locally, Windows Installer still writes this encoded data to the registry. This isn’t normally a problem unless the components to be advertised also install to TARGETDIR or a descendant of TARGETDIR that is not otherwise redirected.

Because TARGETDIR must be the root directory of any Windows Installer package, technically every directory is a descendant of TARGETDIR; however, directories like ProgramFilesFolder are automatically redirected to their corresponding directories like C:\Program Files. Custom actions can also redirect directories, and this is typical in Visual Studio. If TARGETDIR itself isn’t redirected, it defaults to ROOTDRIVE which is the fixed drive with the most free space available, and “fixed drive” doesn’t necessarily mean its an internal drive. External drives these days are growing more common. Any descendants of TARGETDIR are also located relative to ROOTDRIVE then.

So if you have an external drive with a lot of free space connected when you installed Visual Studio, a number of components may have gotten installed there. Even if you do not see any files mysteriously appear after installing Visual Studio, components may still have gotten registered to the other drive. This can actually happen for any Windows Installer products.

Now if you start a product like Outlook that might have add-ins installed that use Visual Studio Tools for Office system Runtime (VSTOR) or Visual Basic for Applications (VBA), creating COM objects they install triggers a repair. This happens because Windows Installer requires the COM server path and this, in turn, triggers a health check. Since the component installation directory – TARGETDIR or a descendant when the component was installed – is no longer available, a repair begins but will ultimately fail in this case since the installation directory is unavailable.

Other problems may manifest. For example, if a file within the same feature is missing for unrelated reasons, Windows Installer installer may prompt for source to replace that file.

So if you had an external drive connected when you installed Visual Studio, make sure you keep it connected when starting applications like Outlook if you have add-ins installed – or at least if you’re experiencing this issue. Better yet for VS 2010 Beta 1, disconnect it when installing Beta 1 unless you intend to install Beta 1 to that drive but remember to keep it connected. On a related note, keep in mind that disk space on your Windows system drive is still consumed by Windows Installer, .NET Framework, and a few other components.

We are working to identify all possible components that may cause this issue for future releases, including VS2010.

Detecting Visual Studio 2008 Service Pack 1

The Visual Studio 2008 RTM and SP1 detection keys are largely the same as the Visual Studio 2005 SP1 detection keys, and are documented below. But there is a caveat for released and upcoming versions: the shared detection value can be overwritten by an older installation of the same release.

For example, if you installed VS2008 Professional, then installed VS2008 SP1, and after that installed Team Foundation Client (TFC) 2008 RTM, the shared detection value is reset to 0 instead of 1. To be sure SP1 is installed, you need to detect SP1 on specific editions of Visual Studio 2008 or any other of our 2008 product releases including .NET 3.5 RTM and SP1.

Product family detection value

Product families define a group of products with similar functionality. The “VS” product family, for example, includes many editions but defines all full SKUs of the Visual Studio IDE. To find the service pack level of a product family, search for the following registry value.

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\[ProductFamily]\Servicing\9.0
Value (REG_DWORD): SP

The exception is for product families “NetFX” and “WPF” that use version 3.5 instead of 9.0.

If the registry value is 0, the RTM version of the product family is installed. If the value is 1, then SP1 is installed on the product family.

Keep in mind, however, that this value is shared by all editions within a product family. If an older product edition is installed after a newer product edition within the same product family, the value will be overwritten. To detect whether SP1 is installed you need to check individual product editions.

Product families released for the 2008 wave of products include,

• NetFX, WPF: .NET Framework 2.0, 3.0, and 3.5 including Windows Presentation Framework
• RDBG: Visual Studio 2008 Remote Debugger
• TRIN: Visual Studio Tools for the Office System 3.0 Runtime
• VB: Visual Basic 2008 Express Edition
• VC: Visual C++ 2008 Express Edition
• VCS: Visual C# 2008 Express Edition
• VNS: Visual Web Developer 2008 Express Edition
• VS: Visual Studio 2008 Professional, Visual Studio Team System 2008 Team Suite, etc.
• VSTF: Visual Studio 2008 Team Explorer, Visual Studio 2008 Team Test Load Agent, etc.

Product edition detection value

A product family may install one or more editions. The “VS” product family, for example, contains several editions including “PRO” (Professional"), “VSTS” (Team Suite), and more. To find the service pack level of a product edition, search for the following registry value:

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\[ProductFamily]\Servicing\9.0\[ProductEdition]\[ProductLanguage]
Value (REG_DWORD): SP

The exceptions are for product families “NetFX” and “WPF” that use version 3.5 instead of 9.0, and do not specify a ProductEdition. For .NET itself, the language is always 1033 unless you’re detecting the SP level for a language pack that uses the LCID for a specific culture.

So for .NET, you would check the following registry value:

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\NetFX\Servicing\3.5\1033
Value (REG_DWORD): SP

For either Visual Studio or .NET, if the registry value is 0, the RTM versions of the product family are installed. If the value is 1, then SP1 is installed on the product family.

The ProductLanguage is the LCID of the product installed, such as 1033 for English (US).

The following table contains the list of released product families, editions, and the product names.

Detection in Windows Installer XML

WiX v3 contains a number of properties to detect the SP level. Aaron Stebner has provided a good post that describes how.

Updated log collection utility available for Visual Studio 2010 and .NET 4.0 Beta 1

Last Monday we shipped Visual Studio 2010 Beta 1 and .NET Framework 4.0 Beta 1 to MSDN customers, and made them publicly available Wednesday. More information about Visual Studio 2010 and .NET Framework 4.0 are available on MSDN, and Aaron Stebner has a good collection of direct links.

While we have worked hard to reduce install times and installation issues and hope you don’t encounter any, in case you do experience an issue we encourage you to gather and upload logs using our updated log collection utility available for download. This will automatically package a lot of logs and product information we can use to diagnose problems and compress them into %TEMP%\vslogs.cab by default. You can then open a bug from the support site and attach logs one the bug is submitted.

In an effort to reduce acquisition times by downloading only what you need for your machine instead of an entire DVD image, we have made web installers available for the following SKUs,

• Visual Studio 2010 Processional Beta 1 – Web Installer
• Visual Studio Team System 2010 Team Suite Beta 1 – Web Installer

For help from the community and Microsoft engineers, please visit the forums for these beta 1 releases. We always appreciate your feedback.

Patch Applicability

When installing a patch package, Windows Installer first determines if the patch is applicable. Depending on how the patch is installed, this happens a little differently. Windows Installer can determine the list of applicable products, or it can be told to which products the patch should be applied.

Possible products

To have Windows Installer determine to which products the patch applies, you can execute msiexec.exe with /update or /p as shown in the following example.

msiexec.exe /update patch.msp

Windows Installer will enumerate the list of ProductCodes in the patch’s Template summary property. The same behavior is true when calling the MsiApplyPatch() function or the MsiApplyMultiplePatches() function when the second parameter is null.

You can also tell Windows Installer to which product the patch should applied using /package or /i as shown in the following example.

msiexec.exe /package {ProductCode} /update patch.msp

For the specified ProductCode or product package, Windows Installer will build the PATCH property and pass that in the command line similar to executing msiexec.exe as shown in the following example. When using the PATCH property, the full paths to each patch must be supplied.

msiexec.exe /package {ProductCode} PATCH=full\path\patch.msp

Windows Installer will evaluate each patch against the specified product. However, if installing the patch or patches using MsiApplyMultiplePatches() with a specific ProductCode, Windows Installer will modify the PATCH property to list only the patch packages with the specified ProdutCode in their Template summary property. If you’re not sure which patches apply to a product, this may be desirable behavior. If you pass in the PATCH property yourself and even one patch does not apply to the specified ProductCode, Windows Installer will terminate and return ERROR_PATCH_TARGET_NOT_FOUND (1642).

Verifying applicability

Once the list of patches has been passed into the installation session, Windows Installer will enumerate the transforms in each patch being applied. If a minor upgrade patch is being installed, Windows Installer will also enumerate the transforms in patches that have already been applied because minor upgrade may change which patches are applicable.

Within a patch package are sets of transforms: there is an authoring transform that describes the changes to the product, and a patch transform that describes how to install the patch and which files are updated. These transforms have the same name except the patch transform name begins with a hash (#).

Windows Installer will enumerate each authoring transform, using the following applicability information from their summary information stream.

• Character Count summary property: the upper 16 bits (word) contain the validation flags, and the lower 16 bits contain the error conditions. These flags are documented in detail for the MsiCreateTransformSummaryInfo() function.
• Last Saved By summary property: the platform and language of the product after it has been transformed.
• Revision Number summary property: the ProductCode, ProductVersion, and UpgradeCode of the target product database, and the new ProductCode and ProductVersion of the product after transformation. Changing the UpgradeCode in a patch is not recommended.
• Template summary property: the platform and language of the target product database. This value may be left blank if the transform does not validate the language. Windows Installer does not currently support validation of the platform.

The transform validation bits in the Character Count summary property determine which other summary properties are relevant. The typical validation bits of 0x0922 specify that the target ProductCode and UpgadeCode are equal to those specified in the Revision Number summary property of the transform, and that the full ProductVersion is equal to the value also in the Revision Number summary property. It’s also important to note that Windows Installer only validates up to the first three fields of the ProductVersion. The fourth field can be changed freely in a small update as a means of tracking and diagnosing updates.

If the ProductLanguage was validated, the ProductLanguage of the target product must match the value in the Template summary property.

When an authoring transform has been validated as applicable to the current product, the related patch transform is assumed to be applicable (validation bits are ignored). The remaining transforms in a patch are ignored, though Windows Installer will still log verbose validation information for each remaining transform.

If a valid transform is found within a patch, the patch is applicable to the product. That still doesn’t mean the patch will be applied, however, since the patch must still be sequenced and supersedence determined. But if a patch is applicable, it will at least be registered to the product. This means that it may be applied in the future if other patches are installed or removed from the product, and that it will be uninstalled with the product. However, since a single patch package is cached for all applicable products, the patch package itself is not deleted from the system until all products to which it’s registered are uninstalled or the patch is uninstalled from all applicable products.

Once all applicable patched are determined, a verbose log will display applicable, obsolesced, superseded, and invalid patches as shown in the following log example.

MSI (c) (88:38) [21:17:01:707]: Final Patch Application Order:
MSI (c) (88:38) [21:17:01:707]: {C26A5DDB-E2C5-4D2E-BC6E-449CBA57184E} -
MSI (c) (88:38) [21:17:01:707]: {A4AC638D-2C4F-4C9E-8962-9A674E782259} -
MSI (c) (88:38) [21:17:01:707]: {C697D8F7-E77A-4DA1-9CED-3F3E5115400D} - c:\Users\Test\AppData\Local\Temp\patch1.msp
MSI (c) (88:38) [21:17:01:707]: {73F7C9E3-08EC-4910-8D5B-3BF90C07EC1C} -
MSI (c) (88:38) [21:17:01:707]: Other Patches:
MSI (c) (88:38) [21:17:01:707]: Superseded: {B45F8725-6450-44D0-9284-01F321026767} -
MSI (c) (88:38) [21:17:01:707]: Superseded: {B0BB7DD1-D63A-4B73-8E73-6F055CB541AC} -
MSI (c) (88:38) [21:17:01:707]: Unknown\Absent: {402ADF4A-1B3D-4824-AE69-3606DDC2CE70} - c:\Users\Test\AppData\Local\Temp\patch2.msp

The names of the valid transforms are also registered to the product to save time by not re-evaluating applicable patches and transforms again during repair operations. The names of the valid transforms can be retrieved using the MsiGetProductInfo() or MsiGetProductInfoEx() functions with the INSTALLPROPERTY_TRANSFORMS property.

Transforming the database

Windows Installer will not actually modify the target database unless applying the patch to an administrative installation, which is created by using msiexec.exe /a. The vast majority of time, you will install a patch on a client machine.

Windows Installer will create views on the product database transformed by each applied transform. When Windows Installer queries the package for information, typically the transforms will add to, update, or remove data and tables. However, the transform error condition flags will fail the installation if not satisfied. With the typical transform error condition flags of 0x001f, Windows Installer will only err if the transforms attempt to change the database code page.

Order of events

Determining patch applicability and validating transforms always occurs before installation execution begins. Any code that needs to modify the list of patches must execute before installing or updating a product. This includes calling APIs like the MsiInstallProduct() function. Custom actions scheduled to execute during installation cannot modify the list of patches, and returning an error from any custom action added by a patch will terminate the entire installation session.

Microsoft .NET 1.x and Visual Studio 7.x patches may fail to uninstall

When attempting to uninstall a patch from the products listed in the Applies To section below, the following error may occur.

Internal Error 2771. M953297

The last part of the error message will vary with each patch, where the last 6 digits are the knowledge base article related to the patch.

Applies To

• Microsoft .NET Framework 1.0
• Microsoft .NET Framework 1.1
• Microsoft Visual Studio .NET 2002
• Microsoft Visual Studio .NET 2003
• Microsoft Visual C++ .NET 2003
• Microsoft Visual C# .NET 2003
• Microsoft Visual Basic .NET 2003

Workaround

One possible reason the error has occurred is because a system policy is set. You can temporarily disable this system policy and attempt to reinstall the patch.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

You need to disable the EnforceUpgradeComponentRules Windows Installer system policy using the steps below.

1. Click Start and then click Run.
2. In the Open box, type regedit.exe and click OK. If you are prompted with a User Account Control (UAC) dialog, please authenticate as an administrator or click Continue.
3. Browse to the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
4. Delete the registry value EnforceUpgradeComponentRules and close the registry editor.
5. Click Start and then click Run.
6. In the Open box, type services.msc and click OK. If you are prompted with a User Account Control (UAC) dialog, please authenticate as an administrator or click Continue.
7. Right click on Windows Installer and click on Stop. It is okay if the Stop button is disable: the service was already stopped.
8. Attempt to reinstall the patch.

To optionally re-enable the EnforceUpgradeComponentRules system policy, follow the steps below.

1. Click Start and then click Run.
2. In the Open box, type regedit.exe and click OK. If you are prompted with a User Account Control (UAC) dialog, please authenticate as an administrator or click Continue.
3. Browse to the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
4. Right click on the Installer key and select New, then DWORD.
5. Type the name EnforceUpgradeComponentRules and press Enter.
6. Double click the value you just created, then type 1 and press Enter.
7. Close the registry editor.

Details

Patches created for the products listed in the Applies To section above support the appearance of uninstall by installing an obsolescing patch and installing older baseline files. Back when these products were first released and entered the servicing lifecycle, Windows Installer did not support real patch uninstall. The only way to uninstall patches back then was to installing a patch that obsolesces (the predecessor to supersedence) another patch, optionally carrying a file payload to avoid prompts for source to replace older files. This is shown in the log fragment below where the "anti-patch" {D5C479FB-3609-4A1D-A106-830635BF50B0} obsolesces the related patch {AAC3F1F0-5649-4670-A698-F1523729F015}.

MSI (c) (14:DC) [02:44:31:310]: Final Patch Application Order:
MSI (c) (14:DC) [02:44:31:310]: {411EDCF7-755D-414E-A74B-3DCD6583F589} -
MSI (c) (14:DC) [02:44:31:310]: {D5C479FB-3609-4A1D-A106-830635BF50B0} - D:\Users\Test\AppData\Local\Temp\MSPE928.tmp
MSI (c) (14:DC) [02:44:31:310]: Other Patches:
MSI (c) (14:DC) [02:44:31:310]: Obsolete: {AAC3F1F0-5649-4670-A698-F1523729F015} -

So because another patch is being installed, it cannot remove components from an existing feature. When the EnforceUpgradeComponentRules Windows Installer system policy is set, the installation will fail as shown below.

MSI (s) (EC:C8) [02:44:34:835]: Machine policy value 'EnforceUpgradeComponentRules' is 1
MSI (s) (EC:C8) [02:44:34:835]: SELMGR: Component 'DDPatch.UpdateGac' is registered to feature 'M953297', but is not present in the FeatureComponents table.  Removal of components from a feature is not supported!
MSI (s) (EC:C8) [02:44:34:835]: Note: 1: 2771 2: M953297

This does not otherwise pose a problem because the patch is being uninstalled and the feature affected is specific only to that patch. And if the patch is reinstalled, the feature is explicitly added locally by a custom action anyway since Windows Installer back then also did not automatically determine feature actions during patch installation.

Why does ICE03 state my localized template string is invalid?

Question

When I run ICE validation, why does ICE03 state the following error?

ICE03 ERROR Invalid template string; Table: Error, Column: Message, Key(s): 1958

The string reads,

ユーザー [2] の特権が不十分です。必要な特権をユーザーに付与してインストールを続行しますか? [いいえ] を選択するとインストールは終了します。

Answer

This ICE error can appear in several columns in several tables that use the Formatted column type or a derivative, like the Template column type used by the Message column of the Error table shown above. Formatted column types allow properties to be inserted between square brackets while the Template column type additionally allows field numbers to be inserted between square brackets. But because properties are of the Identifier column type which allows only alphanumeric ASCII characters, the period (.), and underscores (_), unsupported characters cannot appear between square brackets in a Formatted column type or its derivative.

Take a closer look at the highlighted substring below,

ユーザー [2] の特権が不十分です。必要な特権をユーザーに付与してインストールを続行しますか? [いいえ] を選択するとインストールは終了します。

Since that is not a valid property identifier, ICE03 pumps an error message to the validation message handler because it knows from the _Validation table that the containing column is a Formatted column.

To resolve this issue, escape the square brackets using [\[] in place of [ and [\]] in place of ] as shown below.

ユーザー [2] の特権が不十分です。必要な特権をユーザーに付与してインストールを続行しますか? [\[]いいえ[\]] を選択するとインストールは終了します。

Changes to Package Caching in Windows Installer 5.0

Windows Installer 5.0 is shipping in Windows 7 as part of the operating system. To address the issue where the User Account Control consent dialog is displayed with an “Unidentified Publisher”, the .msi package is cached in its entirety.

Prior to Windows Installer 5.0, installation packages, or .msi files, were stripped of their embedded cabinets – if any – when cached on the system to save space. When repairing the product, if installed files were missing then Windows Installer would attempt to use the last used source location, an application-defined location, or prompt for the installation source. While these prompts can be annoying or even difficult to resolve sometimes, they do reduce the disk space required after an installation is complete.

When Vista added UAC, elevation even for administrators by default was required. Elevation was always required for per-machine installations, but administrator accounts already ran with full privileged tokens so elevation was implicit. To add validation to this elevation prompt - aka the consent dialog - the publisher for signed packages was displayed, and “Unidentified Publisher” was displayed for unsigned packages. But during uninstall, packages would display “Unidentified Publisher” even if they were signed because their embedded cabinets were stripped thus invalidating the digital signature and so Windows Installer wouldn’t verify the cached package as shown below using Windows Installer 4.5 on Vista.

MSI (s) (DC:0C) [16:46:44:058]: MSI_LUA: Elevation required to install product, will prompt for credentials
MSI (s) (DC:0C) [16:46:44:059]: MSI_LUA: Entering Credential Request. hwnd = 1120166, MsiAction = 2, productname = Microsoft Visual Studio Team System 2008 Team Suite - ENU, version = 9.0.30729, language = 1033, manufacturer = Microsoft Corporation
MSI (s) (DC:0C) [16:46:44:059]: MSI_LUA:  (continued)... packagepath = , packagesource = , dwUpdates = 0

To resolve this issue, Windows Installer 5.0 in Windows 7 will cache the installation packages without stripping their embedded cabinets and verify the cached package as shown below using Windows Installer 5.0 on Windows 7.

MSI (s) (20:98) [16:51:25:386]: MSI_LUA: Elevation required to install product, will prompt for credentials
MSI (s) (20:98) [16:51:25:386]: MSI_LUA: Entering Credential Request. hwnd = 1116208, MsiAction = 2, productname = Microsoft Visual Studio Team System 2008 Team Suite - ENU, version = 9.0.30729, language = 1033, manufacturer = Microsoft Corporation
MSI (s) (20:98) [16:51:25:386]: MSI_LUA:  (continued)... packagepath = C:\Windows\Installer\33e5a8b.msi, packagesource = C:\Windows\Installer\33e5a8b.msi, dwUpdates = 0

But this won’t prevent prompts for source even if all files are compressed into embedded cabinets. Windows Installer 5.0 does not consider the Installer-cached .msi files to be valid source and will still resolve possible source locations or prompt as it has in the past.

Installation developers should take this into account since Windows Installer already may require so much disk space and compress files if necessary in external cabinets. Consider your servicing scenarios carefully and determine if you should cache the installation source yourself using the Source List APIs like MsiSourceListAddSource provided by Windows Installer, or just let Windows Installer use its default source resiliency behavior.

Feature Changes in Visual Studio 2008 SP1 may prompt for SQLSysClrTypes.msi

After installing Visual Studio 2008 Service Pack 1, adding or removing features from Visual Studio may prompt for the file SQLSysClrTypes.msi with the following text:

Setup is looking for file SQLSysClrTypes.msi.
Please insert Microsoft Visual Studio Team System 2008 Team Suite – ENU disk 1 now.

The text will read differently depending if you have Visual Studio 2008 Professional Edition or another edition or language installed.

Workaround

SQLSysClrTypes.msi is a product package installed with VS2008 SP1. To satisfied this prompt you’ll need to obtain that file again.

1. Download a complete layout of VS2008 SP1 if you haven’t already.
2. Open the directory were you copied VS2008 SP1.
3. Right click on SQLSysClrTypes.msi and select Copy.
4. Open an Explorer window (ex: Windows key + E) and browse to the directory where you installed Visual Studio 2008. By default this is “C:\Program Files\Microsoft Visual Studio 9.0” where C:\ is your system drive.
5. Double click on the folder that corresponds to the name of the product you installed (ex: “Microsoft Visual Studio Team System 2008 Team Suite – ENU”).
6. Right click on empty space in the window, click New, then Folder, and type “wcu” (without quotes).
7. Double click that new “wcu” folder to open it.
8. Right click on empty space in the window, click New, then Folder, and type “smo” (without quotes).
9. Double click that new “smo” folder to open it.
10. Right click on empty space in the window and click Paste.
11. In the dialog prompt requesting SQLSysClrTypes.msi, click the Browse button.
12. Expand folders to select the directory you opened in step 5 and click the OK button. Do not select the “wcu\smo” directory you created.
13. Click the OK button on the dialog prompt.

On 64-bit machines you will always see this prompt when adding or removing features so it is recommended you keep this file for future use. If you are a network administrator or have the installation source copied to your hard drive, you can also create this directory in the root of the original installation source directory and the setup executable will automatically find SQLSysClrTypes.msi.

Repairing Products after Patches Advertised Features

Windows Installer supports advertising features to enable users to later install those features on demand. But Windows Installer may advertise features in when a component is removed from a feature through obsolescence or supersedence. This will leave the product in a broken state while reporting that the patch installed successfully.

Silverlight 2.0 Beta (KB949325) and a Debugger patch (KB944899) introduces this problem since they added components that did not exist in future patches. For Visual Studio 2008 SP1 we detect and provide a tool for this issue. But this can happen to any Windows Installer product and has happened.

To repair these products, one would need to identify the features that were advertised by a previous maintenance installation such as patch install, and then reinstall the product passing those features to the ADDLOCAL property which – as its name implies – adds those features locally. To assist with this task, I have written a simple Windows Script file to unadvertise features for a product or products based on a single ProductCode or by enumerating target ProductCodes from a patch package.

The script can be used with cscript.exe or wscript.exe, though optional verbose output will only display to the console.

Download and extract it. Then to repair a product by ProductCode, run the following command:

cscript.exe //nologo Unadvertise.wsf /ProductCode:{80C06CCD-7D07-3DB6-86CD-B57B3F0614D8}

To repair any products a patch may target, run the following command:

cscript.exe //nologo Unadvertise.wsf /Patch:"%TEMP%\VS90sp1-KB926601-x86-ENU.msp"

You can also pass additional properties, log verbose output, and see what would happen without actually performing a repair. These options are described on the documentation page.

Dictionary of Windows Installer Tokens

If you are writing emails and specifications about Windows Installer all day, chances are your document or mail editor has plenty of squiggly red lines highlighting your presumed spelling errors like MsiPatchSequence. To not miss any actual spelling errors, I find myself double-checking and adding lots of Windows Installer terms to my custom dictionary so instead I created a separate dictionary containing Windows Installer tokens pulled from schema databases and headers.

You can download this zipped Unicode-encoded text file, unzip it, and configure it for use with Microsoft Office applications as described for 2007 and for older versions. This will probably work with other editors as well, but how to add the dictionary is an exercise left for the reader based on the editor.

Another Possible Workaround for Error 1330

When installing Visual Studio 2008, you might run into an error dialog that reads,

Error 1330.A file that is required cannot be installed because the cabinet file D:\cab1.cab has an invalid digital signature. This may indicate that the cabinet file is corrupt.

The path and name of the cabinet may be different, but might often be D:\cab1.cab, where D: refers to your DVD drive.

How to workaround this issue

Some time ago I blogged that you should try copying the installation locally as in some cases this is related to brief network disconnects or disc read lag, or even a bad burn of an ISO image. You should still try that and other methods in some of the comments on that post first since those are for more likely problems.

If you do not have Internet access, or have a restrictive firewall or proxy, setup may be failing to verify the signature because it cannot access the online certificate revocation list (CRL). This is most likely if you encounter the error on cab1.cab for VS2008 or MSDN.

You’ll need a copy of setreg.exe which is available in the .NET Framework SDK, which is now part of the Windows SDK.

By default, a revocation list is checked so Internet access is required. At any user privilege level, you can run the following command to disable CRL checks using option 3:

setreg.exe 3 FALSE

If you still cannot install VS2008 or MSDN with the same error 1330, make sure that option 9 is set to its default value of FALSE. If this option is TRUE, then the timestamp server is queried for a CRL as well and will fail under the same conditions.

Description of the issue

During installation, Windows Installer calls WinVerifyTrust() to verify that a signed file is valid. By default, a certificate revocation list (CRL) is downloaded and queried to determine if that certificate has been revoked. For VS2008, that CRL is located at http://crl.microsoft.com/pki/crl/products/CSPCA.crl. If an Internet connection is unavailable, WinVerifyTrust() cannot download the CRL.

In a Windows Installer verbose installation log, you may see the following:

MSI (s) (54:C4) [11:00:14:659]: Validating digital signature of file 'D:\cab1.cab'
MSI (s) (54:C4) [11:00:16:818]: File 'D:\cab1.cab' is not trusted.  WinVerifyTrust returned 0x800B010E
MSI (s) (54:E4) [11:00:16:819]: Note: 1: 1330 2: D:\cab1.cab 3: 270

Running the following signtool.exe command – also in the Windows SDK – would yield the same error: 0x800B010E, which is CERT_E_REVOCATION_FAILURE.

Setting setreg.exe option 3 to FALSE will disable the online CRL check.

A similar problem may happen if option 9 is set to TRUE, which tells WinVerifyTrust() to check a CRL on the timestamp server if the signature is timestamped. The error returned is different, however: 0x80096005, which is TRUST_E_TIME_STAMP.

Setting setreg.exe option 9 to its default value of FALSE will disable the online timestamp CRL check.

For reference, running setreg.exe without any parameters will list the current options. All the defaults according to MSDN for VS2008-supported platforms are shown below.

Software Publishing State Key Values (0x22800):
   1) Trust the Test Root........................... FALSE
   2) Use expiration date on certificates........... TRUE
   3) Check the revocation list..................... TRUE
   4) Offline revocation server OK (Individual)..... FALSE
   5) Offline revocation server OK (Commercial)..... TRUE
   6) Java offline revocation server OK (Individual) FALSE
   7) Java offline revocation server OK (Commercial) TRUE
   8) Invalidate version 1 signed objects........... FALSE
   9) Check the revocation list on Time Stamp Signer FALSE
  10) Only trust items found in the Trust DB........ FALSE

Windows Installer XML (WiX) v3 Beta Released

Since plans were made to ship WiX v3 in the box for Visual Studio 2010, the WiX working group has been working on fixing all outstanding bugs in the WiX v3 code base. Bob Arnson uploaded packages last week as a test on SourceForge and this week the following installation packages were uploaded on the v3 Beta release page.

• x86: http://downloads.sourceforge.net/wix/Wix3.0.4805.0-x86-setup.zip
• x64: http://downloads.sourceforge.net/wix/Wix3.0.4805.0-x64-setup.zip

(The difference between the two downloads is support for building natively on x64 platforms with MSBuild in the x64 installation package.)

Some major features in v3 include:

• Build patches completely within WiX
• No additional tools required like msimsp.exe from the Windows Installer SDK
• Filter only those resources you want in your patches
• Support for Windows Installer features up to and including Windows Installer 4.5
• Deployment Tools Foundation (DTF)
• Rich managed framework for Windows Installer APIs
• Supports managed custom actions appropriately (out-of-process)
• Support for binder extensions
• Stability improvements
• Performance enhancements
• Compressing files on multiple threads
• Other performance improvements
• Localization improvements
• Tools are localized
• Code pages and locales are handled better

Please download and install WiX v3 and report any bugs you find. We’re working hard to stabilize WiX v3 for production environments inside Visual Studio 2005, 2008, and 2010 as well as outside of Visual Studio using MSBuild or just the command line tools directly.

Visual Studio 2008 SP1 may complain that another patch is installed even after removing it

If Visual Studio 2008 SP1 prompts you to run the Microsoft Visual Studio Patch removal tool, it means that a patch or product is installed that would cause issues when installing VS2008 SP1. The dialog is shown below.

If you run the the patch removal tool and are still seeing this dialog, please follow the workaround below.

Workaround

You will need to search and possible modify your machine’s registry.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

You need to search for “E4F34490B4BE97847AB7446D8AB3D908” which is a representation of the patch code for SP1 Beta - ENU. Only if it is found under key locations described below can you remove it.

1. Click Start and then click Run.
2. In the Open box, type regedit.exe and click OK. If you are prompted with a User Account Control (UAC) dialog, please authenticate as an administrator or click Continue.
3. In the Registry Editor, click on the very top node on the left.
4. Click on the Edit menu and then Find.
5. Paste “E4F34490B4BE97847AB7446D8AB3D908” (without quotes) into the Find dialog, and click Find Next.
6. For each key location it’s found, take note of the path shown in the status bar at the bottom of the Registry Editor window. You may also click on the Favorites menu and click Add to Favorites, then record the full key location.

If you find this key under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products” then the patch is still installed for a product. Try running the patch removal tool again and make sure it completes successfully. If you’re prompted for source, please provide that source to continue.

If you do not find this key under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products” then you may delete the other keys where this was found. This may include one or both of the following locations.

• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Patches\E4F34490B4BE97847AB7446D8AB3D908
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\E4F34490B4BE97847AB7446D8AB3D908

If you do find it under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Patches\E4F34490B4BE97847AB7446D8AB3D908”, before deleting that key look at the LocalPackage value in that key. If that file exists you may delete it but only if “E4F34490B4BE97847AB7446D8AB3D908” was not found under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products” anywhere.

Other patch code representations that the removal tool searches for are listed below. If you continue to have problems after following the steps above, please follow the directions replacing “E4F34490B4BE97847AB7446D8AB3D908” with each of the codes below.

Details

VS2008 SP1 calls MsiGetPatchInfo() to determine if the patch is already installed before it attempts to download it if needed. This API does not require a ProductCode and checks the bulleted locations above for product-independent information which is only the LocalPackage. The source list for the patch is also stored independently of the product but is not relevant.

Since the patch removal tool does not need to carry payload, a list of target ProductCodes is authored into the package and the tool calls MsiGetPatchInfoEx() which does require a ProductCode. This queries the product-specific key under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products” for product-specific patch information.

Windows Installer should remove the patch when the last product to which the patch is applied is removed or has the patch uninstalled from it. That is, when the patch is no longer applied to any products on the machine the patch information should be removed completely and the cached patch package itself removed from the %WINDIR%\Installer directory. If you run msizap.exe on products to which the patch was applied it can cause this problem since msizap is not uninstall. Some other applications also wrap msizap and can cause the same issue.

Adding features to Visual Studio 2008 may fail to load setup components

When attempting to add features to Visual Studio 2008 after it has already been installed, you may see an error that reports,

A problem has been encountered while loading the setup components. Canceling setup.

Fix

Updated: a hotfix has been uploaded to Code Gallery to address this issue. As stated on the page,

Please be aware this Hotfix has not gone through full Microsoft product regression testing nor has it been tested in combination with other Hotfixes.

You may still use the original workaround posted below.

Workaround

You can choose to either remove older patches installed for Visual Studio 2008, or install Visual Studio 2008 Service Pack 1.

To remove older patches,

Windows Vista and Server 2008

1. Click on Start
2. Click on Control Panel
3. Click on Programs
4. Click on View installed updates
5. Scroll to the grouping for Microsoft Visual Studio 2008
6. For each patch,
   1. Select the patch
   2. Click the Uninstall button

Windows XP and Server 2003

1. Click on Start
2. Click on Control Panel
3. Click on Add and Remove Programs
4. Make sure View Updates is checked
5. Scroll to Microsoft Visual Studio 2008
6. For each patch nested beneath it,
   1. Select the patch
   2. Click the Remove button

Whether you have uninstalled older patches or installed VS2008 SP1, after finished run setup from the Programs menu and not from the installation media to add additional features.

Windows Vista and Server 2008

1. Click on Start
2. Click on Control Panel
3. Click on Programs
4. Click on Uninstall a program
5. Select Microsoft Visual Studio 2008
6. Click the Uninstall/Change button

Windows XP and Server 2003

1. Click on Start
2. Click on Control Panel
3. Click on Add and Remove Programs
4. Select Microsoft Visual Studio 2008
5. Click the Uninstall/Change button

Description

This problem is caused when older patches added new Windows Installer features to the product to support servicing scenarios. Patches KB944899v2 and newer – including VS2008 SP1 - update the setup components to remove this incompatibility.

Because the setup components must be updated, only the cached setup components on the hard disk can be replaced. Running setup from Add/Remove Programs (ARP) runs the locally cached setup components in order to add new features without causing the error described. Running setup from the installation media will use the incompatible setup components causing the error to occur again.