Windows Installer Cache

Windows Installer Cache

  • Comments 27

Windows Installer packages may contain streams identified in the Media table if the Cabinet column value begins with the number sign #, as documented for the Cabinet data type. This cabinet is embedded as a stream within the .msi file and contains files referenced in the File table using their File key column value. When packages are installed, however, cabinet streams are stripped from the .msi file and the .msi file is copied to %WINDIR%\Installer. This saves a significant amount of space required for large packages that are installed on the machine; however, this is part of the reason for prompts for source when the original media isn't available.

As documented in What's in a Patch, patches may also contain embedded streams since .msp files use structured storage as do .msi files. When patches are applied to a product, however, the embedded cabinet streams are not stripped. This is necessary because of how patches are applied and how updated files are made available. The patched files' Sequence column value is updated and a new Media table entry added for each patch being applied. This determines which cabinet stream to use by matching the DiskId column value of the Media table entry to the Media column value in the PatchPackage table. When the patched features are reinstalled the updated files are extracted from the correct patch and copied to the destination location (or to a temporary location to be later copied after a reboot).

For example, we will take a look at the differences between the source and cached .msi files for my Shell Extensions for .NET Assemblies, version 1.4.1993. With the Windows Installer SDK installed as part of the Platform SDK, we'll need to invoke the WiStream.vbs script from the Samples\SysMgmt\Msi\Scripts directory under the Platfrom SDK installation root directory.

First WiStream.vbs is invoked with the AsmShell.msi file that was downloaded as the sole parameter and you'll see the following:

Binary.UpFldrBtn
Binary.NewFldrBtn
Binary.DefBannerBitmap
_8FAD87CB641B23946B4BDE84517E0FCF
?SummaryInformation

Here ? is the character displayed for the octal number \005 which begins the \005SummaryInformation stream as it is displayed in the OEM code page 437 used by the console for U.S. English.

After AsmShell.msi is installed, we need to find the cached package under %WINDIR%\Installer.

Warning: Do not alter the Windows Installer internal information by hand. If you alter the Windows Installer internal information, 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 altering the Windows Installer internal information. Alter the Windows Installer internal information at your own risk.

The names aren't descriptive, so one way of finding the correct .msi file is to open the hidden %WINDIR%\Installer directory in Windows Explorer, change to the Details view, right-click on the columns, and add the Comments column. Find the file with the comment, "Windows Explorer Shell Extensions for .NET Assemblies". Now invoke WiStream.vbs on that file and you'll see the following:

Binary.UpFldrBtn
Binary.NewFldrBtn
Binary.DefBannerBitmap
?SummaryInformation

Notice that _8FAD87CB641B23946B4BDE84517E0FCF is missing. If you look in the Media table for AsmShell.msi you'll see that lone cabinet name is #_8FAD87CB641B23946B4BDE84517E0FCF, which is an embedded stream since it begins with the number sign #.

Now we will do the same with the patch referenced in Updated Sample MSI Scripts, which will allow WiStream.vbs and WiSubStg.vbs to work on .msp files which will be necessary for this next step. After installing the patch that applies to the Platform SDK we invoke WiStream.vbs on the Scripts.msp and will see the following output:

PCW_CAB_PSDK
?SummaryInformation

Next you'll need to find the .msp file in %WINDIR%\Installer that has the revision number {F32C36B7-3547-4B1F-954F-FFED85EBDE92} which, for a patch, is the patch code. Invoking WiStream.vbs on that file yields the following output:

PCW_CAB_PSDK
?SummaryInformation

You'll notice the cabinet stream that contains the patch files is present in both the source and cached .msp files.

Leave a Comment
  • Please add 1 and 4 and type the answer here:
  • Post
  • The tool msizap.exe that is available in the Windows SDK and elsewhere on the web (remember to always

  • PingBack from http://porter.finestmatingstories.com/installercache.html

  • Windows Installer is an engine for performing transactional installations. When installing a product

  • Some customers are reporting that Microsoft Visual Studio 2008 SP1 is failing to install with the following

  • こんにちは! フォーラム オペレーターの服部 清次です。 ここ最近、 MSDN フォーラムの「よくある質問」へのアクセスがだんだん増えてきています。 (^_^)v この勢いを失わないように、これからも皆さんにとって有益な情報をドシドシ載せていきたいと思います!

  • Windows Installer 5.0 is shipping in Windows 7 as part of the operating system. To address the issue

  • Is it possible to access the cached MSI with all the patches overlaid from a custom Action. My new installer needs to query some tables from MSI of an already installed product. But those tables might have changed over time with msp patches.

  • @Deployx, you don't need to. The fact you're running a CA means you're running within a session. Before any action can execute, Windows Installer has already built up an aggregated view of the product and any applicable patches to create a view of all the patches' transformations (in sequenced, superseded order) against the MSI. See http://bit.ly/q6fwS7 for more information.

  • I was trying to figure out how to determine if a patch had been installed - your solution to use Orca was so simple, I am kicking myself for not thinking of it.  Thanks for posting that!

  • On a related topic--how does the installer  know which msi in the cache to run?

    I have the following situation:

        msiA which is unmodified, and msiA1 which is msiA where the product code, upgrade code, and package code have been modified (via Orca).

    If I install msiA, then run msiexec /i msiA1, it tries to repair msiA. I see in the log that msiexec is going first to the cache, then running the cached version of msiA, NOT msiA1. I thought the product code was the key value for finding whether or not an msi was installed.

  • @Dave P, Orca won't show you if a patch is installed or not - just what changes its transforms will apply to an applicable MSI package. There various ways you can use to check if a patch is installed like WMI (select * from Win32_PatchPackage) or PowerShell (http://psmsi.codeplex.com).

  • @Ithaler, it's based on the ProductCode for MSIs and package codes for MSPs. The information is registered along with the file path in the cache.

Page 2 of 2 (27 items) 12