Windows Installer Team Blog : Troubleshooting

Growing Windows Installer Experts through Troubleshooting

Windows Installer Team — Sat, 19 Jan 2008 17:10:00 GMT

Windows Installer expert Dennis Bareis responded to a previous post, Request for suggestions for updating the 1603 KB article. As I worked through his points, the problem of "Growing Windows Installer Experts through Troubleshooting" came into focus.

Growing Windows Installer Experts through Troubleshooting
One of the challenges faced by the Windows Installer community is that there are not enough experts with the capacity to go all the way through the stack to the underlying Win32 behavior.

As with most "grow expertise" problems, there are a few high traffic areas in which one has the chance offer a novice the opportunity to build their expertise.

Once one identifies the high traffic areas, one should go to where the traffic is.

Top Three High Traffic Areas for Novices
The top three in my mind are: tools environment, troubleshooting, and design (in order of priority).

The primary instance to grow expertise is where a user of a packaging tool has reached the limit of the tools design and yet still needs to do more. This opportunity to evolve expertise is generally lost to the Windows Installer because our various tools vendor partners each own their Integrated Development Environment (as they should ;^).

The secondary instance to grow expertise is when there are errors in the underlying experience and one needs to work backward from the low level data into the friendlier higher level constructs.

The tertiary instance to grow expertise is when novices show interest in design.

When I was little...
My goal in updating the KB would be to provide a bit more guidance to the novice that needs (or perhaps even wants) to grow in the direction of becoming an expert.

One of the challenges after reaching the expert level is trying to remember the road traveled so that one might draw a map for those who come after.

It's been so long since I was a novice, I thought it wise to ask for suggestions on how others guide folks on building their Windows Installer expertise through troubleshooting.

Thanks again for the valuable feedback.

[Author: Robert Flaming]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Request for suggestions for updating the 1603 KB article?

Windows Installer Team — Fri, 18 Jan 2008 23:09:00 GMT

Feedback on our existing Knowledge Base article for the error 1603 is that 'it is not very useful.'

My first thought to update the KB would be to go over the troubleshooting techniques such as verbose logging and then how to find and read the errors in the log.

Before proceeding to writing, I thought I'd check-in with the Windows Installer community via this blog.

Are there things besides troubleshooting info you would recommend get covered in the 1603 KB?

Thanks for your consideration.

Tips to find Windows Installer specific product support

Windows Installer Team — Thu, 03 Jan 2008 23:22:00 GMT

Customers have mentioned having trouble finding Windows Installer support when they try to navigate the maze of Microsoft support offerings.

If you too need to find Windows Installer specific product support, the support staff dedicated to Windows Installer can be reached by

For non-Premier Service accounts, see the Professional Support site

Choose an option from the "Developer" row
Mention key words "Windows Installer", "MSI", and "Development"

For Premier Service accounts, contact your Technical Account Manager

Windows Installer product support services are provided by a dedicated team of specialists inside the larger Microsoft support organization.

If you stump these specialists with a difficult or rare issue, they have an escalation path into the Windows product group.

How to Interpret Windows Installer Logs

Windows Installer Team — Tue, 03 Apr 2007 17:23:00 GMT

If you have a problem with the Windows Installer or an MSI package you're installing, it's a sure bet that you will be told by some smart person to "enable logging".

That's great advice, except ... what do you do with the log once you get it? Well, find out by popping over to my blog, where I walk through the contents of a typical Installer Log:

How to Interpret Windows Installer Logs

[Author: Richard Macdonald]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Arbitrary labels used as Primary keys must not be changed between versions

Windows Installer Team — Wed, 07 Mar 2007 21:17:00 GMT

Summary

Msi Editing tools that write auto generated references inside installer tables may cause unnecessary content to be included inside a patch. ‘Patching’ components with unchanged content may cause them to be uninstalled when the patch is removed thereby breaking the original application.

Scenario

“I create a small patch for my product. When I selectively uninstall the patch my original product is broken. The trouble is I’m using Msi 3.x and this isn’t supposed to happen. Doesn’t Msi 3.x ‘cache’ whatever I patch so I can just roll it back when I uninstall? I have followed all the rules to the letter but can’t see where things are going wrong?”

This Is How I Can Reproduce This Behaviour

I create an installation msi for my simple single file application msiExplorer.exe. There is nothing untoward about this installation. The file goes in Program Files\msiExplorer and puts a shortcut on the desktop. The installation also creates a single registry key HKLM\Software\msiExplorer with value Text set to “A”. It installs. It works. Here’s the registry table:

Next, I create a new ‘upgraded’ version of this product. The only thing I change is the label in the registry column of the registry table. (Why would I want to do that!? – well just bear with me and I’ll explain below). I change the label to “RegKey2”.

Now I go through the patch creation process by duly creating a PCP file. In the PCP I specify the old ‘RTM’ msi and the new ‘updated’ msi – the usual routine. When I execute MsiMsp.exe it works. No errors reported. I can even load the original RTM msi database into Orca and overlay it with my new msp. It confirms that the registry table has been modified and shows me what is now included in the patch.

Notice how the actual Registry key, value and data are the same. Only the Registry column has changed.

Ok, I install RTM. It runs without problem; the registry key is duly created. I apply the patch (msiexec /p msiExplorer.msp). It installs, it runs. The Registry key looks the same – well it would wouldn’t it? At this stage it’s difficult to tell who was responsible for writing that registry value – the RTM install or the subsequent patch.

However I know the patch has been successfully applied because when I look in Add\Remove programs, there is my app and the patch correctly listed.

So everything looks good. Unfortunately the trouble starts when I decide to selectively remove MsiExplorer_Patch1 (msiexec /i msiExplorer.msi MSIPATCHREMOVE=msiexplorer.msp). The patch uninstall executes successfully, Add\Remove programs shows it has been removed and I think I’m ok.

But when I look in the registry.......

.........my registry key has gone. So now you can imagine when I run my app – if it depended on this key – it’s going to fail.

Why does that happen?

The key aspect of the scenario is that the registry key with a new label ‘looks’ like a new registry resource added by the patch. When a patch is removed, the new product is restored to its view minus the patch. Additionally, the Installer processes the patch being removed for any resources that it added. It then schedules removal for those resources. Therefore, while the key with label RegKey1 became active (the verbose log file shows it being written).........

........... it was later deleted per label RegKey2 as part of the added resource cleanup (the last portion of the verbose log file before the end opcode).

So How Could You Unknowingly Get Into This Situation?

I’m using an ‘industrial strength household name Msi Editing tool’ (ISHNMET). It’s a very good product. It has a nice feature which will read a COM Server file and automatically extract the COM registration information and populate the tables. One of these tables is the registry table. It therefore populates the registry column with arbitrary labels Registry1, Registry2...etc. Here’s a mock up of how it might look:

I have to rebuild my msi package every day and have automated the process. The developers submit their updated files and the tables are built by script. When the msi is built by the ISHNMET it does its trick of automatically extracting the COM information. If the developer has built some extra COM functionality into a dll the entries are inserted mid table bumping all the lower rows down. The naming algorithm just re-labels all the rows. In this example Registry4 gets bumped down a row and re-labelled as Registry5

Now when we go through our patch creation process we correctly pick up that MsiExplorer.exe component has changed but inadvertently include component ‘SomeComponent’ because the label changed! Now we are going to deliver a patch which includes the problem discussed above.

To be fair the very latest versions of ISHNMET try to minimise this scenario. However you might for example delete a registry entry and then change your mind, re-create it using the GUI and have it reappear in the registry table with a brand new label. So it probably pays to be aware of the dangers of arbitrary labels.

Does this happen anywhere else?

Exactly the same issue applies to the file table. If the ISHNMET uses arbitrary labels for the files it is adding to the file table then they are subject to the same vulnerability. Where the label in the file table is used as the keypath in the component, it is automatically changed at both reference points when re-labelling occurs. From the ISHNMET point of view this keeps the referential integrity between Component and File nice and tidy. From our point of view though, this will be picked up by MsiMsp.exe. You could finish up attempting to patch a file with an identical copy. Here is what this looks like with my simple example:

Modify the File column of the file table (Was msiExplorer.exe, now msiExplorer1.exe)

... and modify the keypath reference in the component table....

Create the patch and just to confirm it, overlay the RTM msi with the msp.

Install RTM. Install the patch. Use Add\Remove programs to confirm the patch is registered

You might even inspect the patch cache and notice that no copy of msiExplorer.exe has been saved.

Now selectively uninstall the patch and the original msiExplorer.exe (The one in Program Files\msiExplorer) has disappeared. Try to run the shortcut and if you’re lucky the executable will be restored via install-on-demand resilience or in my case, just to prove the point, I hid the source msi so that I could see the install-on-demand dialog.

The app is broken.

This same explanation above works for the File as well – and it should be noted that you’d need to maintain the same filekey for binary delta patching to work (just look at the Patch table and you’ll know why by reviewing the primary key columns for that table)

Here’s the Message

The Installer’s format is a relational database. Identity is expressed by the primary key – which is why it is so crucial. An item is found in the database by searching for its primary key. That’s how transforms can know which data to modify (efficiently) and how Patchwiz can determine what has changed. It’s imperative that the primary keys are not changed between versions of the package.

[Author: Robin Drake]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Windows Installer Appears Every Time a Program is Started

Windows Installer Team — Sun, 05 Feb 2006 21:13:00 GMT

Question

OS: Windows XP Home SP2 with Automatic updates every day at 3AM; Machine: Toshiba Satellite M35X-S311; 80% of hard drive free.

My trial version of Office 2003 expired 1/31/06 (no warning messages received prior). I couldn't access Control Panel (system32/CoPM.cpl error). No System Restore points prior to 1/31/06.

Ever since 1/31/06, windows installer pops up on every application (explorer, print, office). "Preparing to Install just hangs there for a couple of minutes -- for everything.

Spyware, adware and malware has been scanned and removed. I've also had my machine scanned by Hijack this, Norton SystemWorks and Registry Mechanic, and no problem can be found.

I've been to the MS support pages, and have tried

update installer (did not help)
Modify the Registry (article 265194; effective for Office 2000)
I've downloaded Windows Install Cleanup, but am not experienced enough to handle any problems that may ensue

I can't begin to tell you how much this affects my work. I've lost 5 days of writing -- which is how I earn my living -- and I'm obsessed with getting my computer back the way it used to be.

Please tell me how to fix this -- this is a major disaster for me.

Answer

I'm sorry to hear you're having these problems. It sounds like it's quite frustrating and you've run out of options. If the following information doesn't allow you to unblock yourself, I encourage you to call Microsoft Product Support Services.

I try and answer question in three parts:

why is this happening?
what is really failing?
how can I fix this?

Why is this happening?

Creating stable corporate computing platforms was a pillar for the Total Cost of Ownership initiative for the Windows 2000 generation of releases. Part of that effort was the Windows Installer Resiliency features. In the controlled environment of corporate computing, these errors do not occur because the accompanying infrastructure is maintained to automatically respond to these issues thereby reducing total cost of ownership for the corporate customer.

Generally, home computers are subject to much less supervisory oversight and assistance. Without the help of a professional administrator, the quality of the application experience on Windows is at the discretion of the software vendor. Software vendor do make mistakes with the Windows Installer Resiliency features and thus you have this experience.

This specific problem is frequently written about in periodicals user assistance columns. I noted this in the blog entry "Stop Installation Idiocy" PCWorld's Hassle Free PC article

What is really failing?

The Windows Installer Frequently Asked Questions has FAQ items titled:

Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation?

How can I figure out why my package fails to install?

These entries will allow you to turn on Windows event logging and Windows Installer package logging which enable you to determine the which executable (client) and application (package) are providing misinformation to the Windows Installer service.

Behind the covers, it kind of works this way

a client program is trying to assure the correct state of an application.

a client is calling a Windows Installer API (such as MsiGetComponentPath)

either

the system is in an inconsistent state and thereby unable to fulfill the request

two or more packages installed to the system are inconsistent creating a conflict on the system.

the sequence of system (Windows Installer system service) and application (client code and application packaging) functionality is unable to correct the triggering state thus the event is triggered again

How can I fix this?

Generally, start by contacting the Software Vendor(s) that is (are) causing the problem. The event and install logs enabled by the above should allow you to find the offending combination. As a PC is actually a commons, there may be more than one Software Vendor involved. The Software Vendor should be able to tell you how to repair their applications. This is a well traveled troubleshooting route traveled by corporate administrators.

Some home users will give up at this point because they don't have the time or geek-like persistence to work through all the details. Other home users will say they don't have media any more, the software company does not exist any more, or that was an unofficial copy of the application. Still others find their software provider unable to help them due to lack of knowledge, lack of experience, or a propensity to blame the other software provider.

Boiler plate suggestions from an ISV may include (in no particular order)

Repair (msiexec /famus ...)
Uninstall and reinstall (msiexec /x ... followed by msiexec /i ...)
Install again (msiexec REINSTALLMODE="famus" /i ... )
You should be able to try this on your own too.

MSIZap is the the Windows Installer tool that offers to disconnect the Windows Installer portion of the chain. MSIZap just operates on the Windows Installer store of information. MSIZap does not touch the the resources (files and registry keys) of the application. By using MSIZap to remove Windows Installer's knowledge of the application, the calls to the Windows Installer APIs will fail due to unrecognized parameters. The risk to removing the Windows Installer internal data is in how well the client that is calling the Windows Installer APIs responds to return codes (INSTALLSTATE_UNKNOWN for example). From the Windows Installer point of view, MSIZap is a tool of last resort as it eliminates Windows Installer from the equation.

As one will note in the "Stop Installation Idiocy" PCWorld's Hassle Free PC article, MSIZap is a choice user assistance columnists choose to call out.

Hope this helps...

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Windows Installer Troubleshooting Tips from First Week of November

Windows Installer Team — Fri, 11 Nov 2005 18:00:00 GMT

Question 1

What is the correct way to find whether a certain product (msi based setup) is installed on the machine?

Answer 1

Searching for Existing Applications, Files, Registry Entries or .ini File Entries [Windows Installer] lists the built-in detect methods. In this case, the CompLocator Table [Windows Installer] is intended to have the needed functionality.

To find the ComponentId for the CompLocator row,

use Orca to open the MSI of the targeted product
find the key binary dependency in the file table
1. select the file table from the Tables window
2. Choose Edit | Find from the menu
3. In the Find dialog, type in the name of the file that you have a binary dependency on into the Find what edit box then click the Find Next button
4. Continue to hit Find Next on the Find dialog until a row in the file table will be highlighted so click the Cancel button on the Find dialog
copy the Component_ column value from the file table

Select the second column of highlighted row and choose Edit | Copy cell menu item

find the component in the component table

select the component table from the Tables window
Choose Edit | Find from the menu
In the Find dialog, paste the value from step 3 into the Find what edit box then click the Find Next button
Continue to hit Find Next on the Find dialog until a row in the component table will be highlighted so click the Cancel button on the Find dialog

Grab the GUID from the ComponentId

Select the second column of highlighted row and choose Edit | Copy cell menu item

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Windows Installer Troubleshooting Tips From Halloween

Windows Installer Team — Wed, 09 Nov 2005 18:00:00 GMT

Question 1

In my lab automation that silently installs Windows Installer packages. This automation is inconsistently getting Error 1618 from its msiexec calls. Please help unblock this scenario as it's inhibiting our push to ship.

Troubleshooting 1

First, start with the MSDN Library and run a search for "windows installer" 1618. This query (when I click it) turns up Initialization Errors [Windows Installer] as the sixth hit. This page contains

Error code	Value	Error
ERROR_INSTALL_ALREADY_RUNNING	1618	An installation is already in progress

Next, have a look at the machine event log and look for the messages per the MSDN Topic Event Logging

Finally, when one puts this information together, the chances are high that another process, such as SMS or Group Policy, is triggering a silent install of a MSI based product thus the mutex is preventing the simultaneous install of the second product.

Solutions 1

To solve for this scenario, one needs to understand the mechanics of determining if Windows Installer is busy and then one needs to consider the appropriate behavior for their application for the "busy" case.

Generally if Windows Installer is busy , Windows Installer will set the Mutex. For a sample demonstrating the mechanics of checking the mutex, see the Windows Installer Platform SDK bootstrapper code example:

    HANDLE hMutex = 0;
    bool bInstallRunning = false;

    const char *szMutexName = "Global\\_MSISETUP_{2956EBA1-9B5A-4679-8618-357136DA66CA}";
    hMutex = WIN::CreateMutex(NULL /*default security descriptor*/, FALSE, szMutexName);
    if (!hMutex || ERROR_ALREADY_EXISTS == GetLastError())
    {
        bInstallRunning = true;
    }
    else
    {
        bInstallRunning = false;
    }

    // only run one instance at a time
    if (bInstallRunning)
    {
        // silently return - correct return code ?
        uiRet = ERROR_INSTALL_ALREADY_RUNNING;
        goto CleanUp;
    }

    // do work here

CleanUp:
    if(hMutex)
        CloseHandle(hMutex);

For Windows Installer 3.0 or greater, we recommend switching from the mutex to attempting to stop the msi service. If you are unable to stop the service, the service is busy installing another product. In pseudocode, these mechanics would look like

if (MSIServer is not running)
    bInstallRunning = true; // because if the service isn't running there can't be an install running
else  if (MSIServer accepts SERVICE_ACCEPT_STOP)
    bInstallRunning = false; // because if it can stop it can't be installing something
else
    bInstallRunning = false; // because it won't accept the stop, so it's doing an install.

With either of these solutions, a non-privileged context will be unable to detect the state of the engine.

Now that you know the mechanics, you need to consider what to do when the Windows Installer is "busy". There are a number of options and which one you choose depends on your judgment. Some solutions choose surface the fact that the Windows Installer is busy and suggest the user try again later. Other solutions choose to put the "busy" check in a polling loop and attempt an auto recover from the mutex.

Question 2

I have a Windows Installer package that InstallInitialize shows all the features and components are installing Action:Local but after the install the feature is advertised. Can you help explain this? (msi packages and verbose logs sent too)

Answer 2

Generally to find these issues I look at the components with conditions. In this case we have the following Component Table Fragments

Component ComponentId Directory_ Attributes Condition KeyPath

C_Server_ConnectorKeys_For_NonRMS.540EA3C0_A5E9_41EA_A585_822C09EA2650 {3162C002-E983-4C45-BE65-A0EADF35AD49} SDK_DIR.540EA3C0_A5E9_41EA_A585_822C09EA2650 4 IS_ROOT_HEALTH_SERVICE=0 R_Server_ConnectorKeys_For_NonRMS10.540EA3C0_A5E9_41EA_A585_822C09EA2650

C_Core_ConnectorKeys.80B659D9_F758_4E7D_B4FA_E53FC737DCC9 {43DC7EF4-E685-45E1-9B3B-9843A2853E43} CORE_DIR.80B659D9_F758_4E7D_B4FA_E53FC737DCC9 4 USE_SETTINGS_FROM_AD=0 R_Core_Connector01.80B659D9_F758_4E7D_B4FA_E53FC737DCC9

Component	ComponentId	Directory_	Attributes	Condition	KeyPath
C_Server_ConnectorKeys_For_NonRMS.540EA3C0_A5E9_41EA_A585_822C09EA2650	{3162C002-E983-4C45-BE65-A0EADF35AD49}	SDK_DIR.540EA3C0_A5E9_41EA_A585_822C09EA2650	4	IS_ROOT_HEALTH_SERVICE=0	R_Server_ConnectorKeys_For_NonRMS10.540EA3C0_A5E9_41EA_A585_822C09EA2650
C_Core_ConnectorKeys.80B659D9_F758_4E7D_B4FA_E53FC737DCC9	{43DC7EF4-E685-45E1-9B3B-9843A2853E43}	CORE_DIR.80B659D9_F758_4E7D_B4FA_E53FC737DCC9	4	USE_SETTINGS_FROM_AD=0	R_Core_Connector01.80B659D9_F758_4E7D_B4FA_E53FC737DCC9

Cross Referencing the C_Server_ConnectorKeys_For_NonRMS.540EA3C0_A5E9_41EA_A585_822C09EA2650 GUID {3162C002-E983-4C45-BE65-A0EADF35AD49} with the install log and one finds

MSI (s) (44:6C) [14:26:41:656]: Executing op: ComponentUnregister(ComponentId={3162C002-E983-4C45-BE65-A0EADF35AD49},,BinaryType=0,PreviouslyPinned=1)

Now I take the condition and search for it in the log

MSI (s) (44!AC) [14:26:26:828]: PROPERTY CHANGE: Modifying IS_ROOT_HEALTH_SERVICE property. Its current value is '0'. Its new value: '1'.

...

Property(S): IS_ROOT_HEALTH_SERVICE = 1

If it were true that this property was set, it would cause the component to be absent and its absence would cause the feature to appear advertised.

Design Suggestion for Question 2

If the advertised state on the feature is the problem, I suspect what’s called for here is another feature. One could have a child feature that just contains the components that will be toggled and is marked to follow parent. Depending on whether that works for all scenarios, there is also the option to have the new feature sit at the root and then write code to toggle the state of the feature.

Editing credit also belongs to

Phil Wilson, MSI MVP,

Content credit also belongs to

Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
Hem, MSI Team Dev. You can get other Hem insights about developing for Windows Installer from the Windows Installer Chat Archives

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Instance of Troubleshooting Patch Applicability

Windows Installer Team — Fri, 04 Nov 2005 17:00:00 GMT

Context:

While troubleshooting Windows Installer installs can be complex, troubleshooting patch installs adds a couple more layers of complexity (patch transforms and applicability rules). Given the lack of patch troubleshooting documentation (at least that I've seen) I figured I'd take a case where Carolyn has provided detailed analysis for a customer inquiry from Product Support.

Desired Behavior:

Patch 1 targets the Base package and patch 2 targets both the Base and Patch 1

Actual Behavior:

Applying a patch 2 after patch 1 results in the error “The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch.”

Analysis

You can easily analyze a MSP and the usual place to start looking when a patch isn't applicable is the applicability criteria for the MSP. For a patch, there's two layers.

Layer 1
PID_TEMPLATE summary property of the MSP itself. This is the list of target ProductCodes for the patch. You can bypass this layer using PATCH={path to patch} on the command line and invoking a /i type installation operation. MsiApplyPatch and/or "/p patch.msp" involve this layer.
Layer 2
PID_REVNUMBER and PID_CHARCOUNT summary properties of the MSTs embedded within the MSP. The revision number gives the ProductCode-ProductVersion/ProductCode-ProductVersion/UpgradeCode set between the target and update images. The charcount identifies the validation flags.

You can use dfview to look at the substorages within a MSP to find out how many targets it has. That, or just use msiinfo on the MSP since that gives you the list of embedded transforms. Each case here has a single set of embedded transforms.

C:\scratch\rfc>msiinfo patch02.msp
ClassId = {000C1086-0000-0000-C000-000000000046}
[ 5][/k] Keywords = PatchSourceList
[ 7][/p] Template(MSI CPU,LangIDs) = {F7877CD1-F33B-4DCD-8B11-A72BB64F22E6}
[ 8][/l] SavedBy = :QPPrevVersionToQPNewVersion;:#QPPrevVersionToQPNewVersion
[ 9][/v] Revision = {68C7ED9B-4938-492B-B88B-B463E5000817}
[15][/w] Words(MSI Source Type) = 3
 
C:\scratch\rfc>msiinfo patch01.msp
ClassId = {000C1086-0000-0000-C000-000000000046}
[ 5][/k] Keywords = PatchSourceList
[ 7][/p] Template(MSI CPU,LangIDs) = {F7877CD1-F33B-4DCD-8B11-A72BB64F22E6}
[ 8][/l] SavedBy = :QPPrevVersionToQPNewVersion;:#QPPrevVersionToQPNewVersion
[ 9][/v] Revision = {5E64DBA1-44E9-4A04-AF2C-5CCCD109C95D}
[15][/w] Words(MSI Source Type) = 3

So, patch02 is certainly not a multi-target patch.

Now to get to the 2nd layer, you have to go back to the transforms in the temp folder of the machine that generated the patch (assuming the DontRemoveTempFolderWhenFinished property was set in the Property Table of the PCP file). Oh, and one other thing to add. None of these patches have the MsiPatchSequence table so they follow 2.0 patch application rules which means chronological patch application (order in which patches are applied on the machine). Here's the requisite data from the transforms:


C:\scratch\rfc>msiinfo patch01.mst
ClassId = {000C1082-0000-0000-C000-000000000046}
[ 1][/c] Codepage = 1252
[ 2][/t] Title = Customers Product
[ 3][/j] Subject = Customers Product
[ 4][/a] Author = Customers Company
[ 5][/k] Keywords = Installer,MSI,Database
[ 6][/o] Comments = Contact:  Your local administrator
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1033
[ 8][/l] SavedBy = Intel;1033
[ 9][/v] Revision = {F7877CD1-F33B-4DCD-8B11-A72BB64F22E6}10.4.27.01;{F7877CD1-F
33B-4DCD-8B11-A72BB64F22E6}10.5.28.03;{D9929871-61DC-4461-AD49-29212301A721}
[12][/r] Created = 2005/03/11 09:46:38
[14][/g] Pages(MSI Version Used) = 200
[16][/h] Characters(MSI Transform) = 144834583
[18][/n] Application = InstallShield« Developer 8.0
[19][/u] Security = 1
 
C:\scratch\rfc>msiinfo patch02.mst
ClassId = {000C1082-0000-0000-C000-000000000046}
[ 1][/c] Codepage = 1252
[ 2][/t] Title = Customers Product
[ 3][/j] Subject = Customers Product
[ 4][/a] Author = Customers Company
[ 5][/k] Keywords = Installer,MSI,Database
[ 6][/o] Comments = Contact:  Your local administrator
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1033
[ 8][/l] SavedBy = Intel;1033
[ 9][/v] Revision = {F7877CD1-F33B-4DCD-8B11-A72BB64F22E6}10.4.27.01;{F7877CD1-F
33B-4DCD-8B11-A72BB64F22E6}10.5.28.04;{D9929871-61DC-4461-AD49-29212301A721}
[12][/r] Created = 2005/03/11 09:46:38
[14][/g] Pages(MSI Version Used) = 200
[16][/h] Characters(MSI Transform) = 144834583
[18][/n] Application = InstallShield« Developer 8.0
[19][/u] Security = 1

The char count is a combination of validation and error suppression. As the Character Count MSDN Topic says the upper word is validation and the lower word is error condition flags. For both the above transforms, Char Count is 144834583. If you convert 144834583 to hex, you get 0x008A20017 thus the upper word is 8A2 and the lower word is 17. This further means 8A2 is the validation condition. 017 is the error condition.

Now let's break these down using the MSDN Topic MsiCreateTransformSummaryInfo.

Validation Translation:

Note that 0x8A2 is not the default patchwiz value. Our recommendation is 0x922 per the MSDN Topic TargetImages Table (PatchWiz.DLL).

Value	Flags
0x8A2	MSITRANSFORM_VALIDATE_UPGRADECODE (0x00000800) + MSITRANSFORM_VALIDATE_NEWLESSEQUALBASEVERSION (0x00000080) + MSITRANSFORM_VALIDATE_UPDATEVERSION (0x00000020) + MSITRANSFORM_VALIDATE_PRODUCT (0x00000002)

Error Condition Translation:

Value	Flags
0x17	MSITRANSFORM_ERROR_UPDATEMISSINGROW (0x00000010) + MSITRANSFORM_ERROR_ADDEXISTINGTABLE (0x00000004) + MSITRANSFORM_ERROR_DELMISSINGROW (0x00000002) + MSITRANSFORM_ERROR_ADDEXISTINGROW (0x00000001)

Breaking down 0x8A2 into behavior

Flag	Behavior
MSITRANSFORM_VALIDATE_UPGRADECODE (0x00000800)	Validate UpgradeCode for equality.
MSITRANSFORM_VALIDATE_NEWLESSEQUALBASEVERSION (0x00000080)	See Below. Note: This is an unusual choice.
MSITRANSFORM_VALIDATE_UPDATEVERSION (0x00000020)	major.minor.upgrade fields of Product Version should be validated
MSITRANSFORM_VALIDATE_PRODUCT (0x00000002)	Validate ProductCode for equality

So what does newlessequalbase mean?

InstalledVersion <= BaseVersion.

Installed: ProductVersion (ProductVersion of Installed product from in-memory view of Property table)
Base: TransformVersion

The base version that is used is the "Old" Product's version in the Revision property.

So for Patch02, here's what we have:

Installed = 10.5.28.03 (this is the product + Patch01 view of the Property table)
Base = 10.4.27.01

The comparison is then:

10.5.28.03 <= 10.4.27.01

This always evaluates to false. Now if you apply Patch02 on top of just the product (no Patch01), you have the comparison as:

10.4.27.01 <= 10.4.27.01

That's true.

Conclusion

In the end, these patches are poorly authored for their validation conditions. They should use the recommended value: 0x922 and additionally the targeting of Patch02 is all wrong. Since it doesn't obsolete Patch01, it would have to target Patch01 which from analyzing the patch, it does not. It only targets RTM and therefore it's impossible to have a valid sequence of patches from RTM -> Patch01 -> Patch02.

Content credit also belongs to

Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
Nitin, Phil, Alden, and Erik, Microsoft Support Team

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Windows Installer Troubleshooting Tips from Last Week of October

Windows Installer Team — Wed, 02 Nov 2005 17:00:00 GMT

Question 1

Any tips troubleshooting silent install exiting with error 1618?

Answer 1

Start with the Windows Installer SDK.

First, search for “windows installer” 1618 which turns up Initialization Errors [Windows Installer] as the sixth hit.

When you look at this page you’ll see

ERROR_INSTALL_ALREADY_RUNNING

1618

An installation is already in progress

Second, have a look at your event log and look for the messages per the MSDN Topic Event Logging.

When one puts this information together, the chances are high something else is triggering a silent install of a MSI based product thus the mutex is preventing the simultaneous install of the second product.

Question 2

Can you help me troubleshoot my component states?

I have a shared component Component_Perf. It is shared between A.msi and B.msi.

Install A.msi
MSI (s) (68:30) [11:46:28:449]: Component: Component_Perf; Installed: Absent; Request: Local; Action: Local

Install B.msi
MSI (s) (68:50) [11:50:03:096]: Component: Component_Perf; Installed: Absent; Request: Local; Action: Local

Since the component is already installed with A.msi, I was expecting this be Action: Null? Specifically

Install B.msi
Installed: Local; Request: Local; Action: Null

The behavior seems as expected during uninstallation.

Uninstall B.msi
MSI (s) (68:A8) [12:02:01:415]: Component: Component_Perf; Installed: Local; Request: Absent; Action: Null

Uninstall A.msi
MSI (s) (68:74) [12:06:18:157]: Component: Component_Perf; Installed: Local; Request: Absent; Action: Absent

What am I missing?

Answer 2

You still have to install the component for Product B. Note that it shows up as "Installed: Absent" because it's not currently installed. The real question is why do you expect the Action state to be Null? Unless there's a higher version of the component on the machine, it's already installed for Product B, or it's condition evaluates to false, the Action state of Local makes sense.

So essentially Installed = Installed for Product and not Installed on Computer.

Question 3

Is there a way I can achieve the following Custom Action calls using Windows Installer without implementing my own detection mechanism?

Execute CA_Install with the first installed product that includes Component_Perf
Execute CA_Remove with the last removed product that includes Component_Perf

Answer 3

There is an API called MsiEnumClients that gives you client lists of a component. If you're only dealing with per-machine installs, it's an easy API that'll work for you.

Question 4

I want to make a script that adds to the order a constant, to every line in the controlEvent table which has a “Spawndialog” value. There may be more than one such line in every dialog. How can I write a SQL query that updates these lines?

Answer 4

SQL Syntax [Windows Installer] says

Modify existing records in a table UPDATE {table-list} SET {column}= {constant} [, {column}= {constant}][, ...] [WHERE {operation-list}]

UPDATE queries only work on nonprimary key columns.

Examples of Database Queries Using SQL and Script says

Modify an existing record in a table

The following command line changes the existing value in the Title field to "Performances." The updated record has "Arts" as its primary key and is in the Feature table of the Test.msi database.

Cscript WiRunSQL.vbs Test.msi "UPDATE `Feature` SET `Feature`.`Title`='Performances' WHERE `Feature`.`Feature`='Arts'"

Addition however is not part of the subset of SQL Syntax that Windows Installer supports. The way I’ve solved this in the past is to start with the Working with Queries MSDN Topic and between steps 3 and 4, I run MsiRecordGetInteger, do the math, and run MsiRecoredSetInteger.

Question 5

Is there any way to force the components to reload without doing a major upgrade?

Answer 5

No. Please review MSDN Topic Patching and Upgrades, specifically the table at the end of the topic. Given what I understand of this case, this question asks for Major Upgrade behavior in a Small Update which is not possible. Also note: Minor Upgrade does not apply because this functionally wants to reorganize the Feature-Component tree which is not allowed in a minor upgrade.

Question 6

Any thoughts on causing the files to reinstall to the target directory?

Answer 6

I think this asks “can I change the target path during maintenance mode?” to which the answer is ‘No’ per MSDN topic Changing the Target Location for a Directory

Question 7

Can you provide assistance troubleshooting error 1334?

I generated a patch and upon applying that patch received this error:

Error 1334. The file 'Indexes.cmp.751F2241_A570_4290_8C69_419C00462AA5' cannot be installed because the file cannot be found in cabinet file 'Product.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.

MSI (s) (9C:C4) [13:26:07:755]: Product: Division-Product 9.0 -- Error 1334. The file 'Indexes.cmp.751F2241_A570_4290_8C69_419C00462AA5' cannot be installed because the file cannot be found in cabinet file 'Product.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.

So I looked in the SDK for don’t do’s of creating a patch package. Everything I was able to verify as not a problem except for “do not change the order of files in a cabinet”…. When I investigated that one, here’s what I had in my base MSI:

386	PreLoad.cmp	16	\Program Files\Division\Product\SQL\Install\1157\Company\Data\
387	Indexes.cmp	7817	\Program Files\Division\Product\SQL\Install\2416\Company\
388	Tables.cmp	19842	\Program Files\Division\Product\SQL\Install\2416\Company\
389	Driver.ini	358	\Program Files\Division\Product\SQL\Install\2416\
390	DexProcs.cmp	302470	\Program Files\Division\Product\SQL\Install\2416\Company\
391	DexProcs.drp	16	\Program Files\Division\Product\SQL\Upgrade\2416\7.50.0\Company\
392	DexProcs.drp	16	\Program Files\Division\Product\SQL\Upgrade\2416\7.50.0\System\
393	Driver.ini	49	\Program Files\Division\Product\SQL\Lesson\2416\
394	Driver.ini	473	\Program Files\Division\Product\SQL\Upgrade\2416\7.50.0\
395	CAMAU.cnk	48154	\Program Files\Division\Product\
396	CAMCA.cnk	48154	\Program Files\Division\Product\

…and here’s the relevant section of my new MSI:

386	PreLoad.cmp	16	\Program Files\Division\Product\SQL\Install\1157\Company\Data\
387	Driver.ini	49	\Program Files\Division\Product\SQL\Lesson\2416\
388	Driver.ini	473	\Program Files\Division\Product\SQL\Upgrade\2416\7.50.0\
389	Indexes.cmp	7817	\Program Files\Division\Product\SQL\Install\2416\Company\
390	Tables.cmp	19842	\Program Files\Division\Product\SQL\Install\2416\Company\
391	DexProcs.drp	16	\Program Files\Division\Product\SQL\Upgrade\2416\7.50.0\Company\
392	Stubs.drp	16	\Program Files\Division\Product\SQL\Upgrade\2416\9.0.62\Company\
393	Stubs.drp	16	\Program Files\Division\Product\SQL\Upgrade\2416\9.0.62\System\
394	DexProcs.drp	16	\Program Files\Division\Product\SQL\Upgrade\2416\7.50.0\System\
395	Driver.ini	475	\Program Files\Division\Product\SQL\Upgrade\2416\9.0.62\
396	DexProcs.cmp	302470	\Program Files\Division\Product\SQL\Install\2416\Company\
397	CAMAU.cnk	48154	\Program Files\Division\Product\
398	CAMCA.cnk	48154	\Program Files\Division\Product\

OK, so the error is on the italic line above, and well, it’s the first file that doesn’t match its old ID. The bold files above were added, which appeared to cause this whole section to get spanked around.

Are there ways that I can get around this issue?

Answer 7

You need to build your upgrade package based off of the old such that you do not add files in the middle. You control how your package is built so you'll have to handle this yourself. Any new files in the upgrade package need to be added at the end of the file sequence.

Question 8

I would like to find out that is there a property that I can set inside my MSI so that we force the installer to cache a full msi instead of the msi in the installer cache?

Answer 8

Have a look at the ‘v’ option of the /f switch in the MSDN Topic Command Line Options.

Question 9

I get an error message that says: "Windows Installer Service can’t be contacted"

Answer 9

There’s this KB: "Windows Installer Service could not be accessed" error message when installing application”.

Question 10

Do you have troubleshooting pointers for the following error that occurs on x64?

Info 1721.There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: WiaRegSvr32.cmd, location: C:\Winparty2005\WiaRegSvr32.cmd, command: WiaRegSrv32.cmd

Answer 10

Have you verified that your code runs properly outside of an MSI installation?
Does the .cmd file work on x64?
Does your .cmd file run on x64 outside of the MSI package from the same location that it would normally be run (per the log file)?

Question 11

Is there an IA64 version of MSI 3.0 redist?

Answer 11

See http://support.microsoft.com/kb/898715/. MSI 3.1 ships with Win2K3 SP1 but you should update to v2 since v1 had a bug that could cause installations to fail during silent install scenarios.

Question 12

How do I extract files from an MSI package using native code?

Answer 12

Use MsiInstallProduct and include ACTION=ADMIN in szCommandLine...

Question 13

What are the top 10 ways to learn about ClickOnce?

Answer 13

Posted at http://blogs.msdn.com/saurabh/archive/2005/10/28/486106.aspx

Question 14

My Source MSI has 2 files both having File Version : 10
And My Target MSI has 2 files both having File Version : 11

I want to create an .msp for only for one file, not both the files. But when I create a .pcp file it is picking up both the files as the FileVerison has been changed. How can I do that?

Answer 14

Either don’t put the updated file in your Update MSI before building the patch or list the File foreign key for the file(s) you don’t want to update in the UpgradedFilesToIgnore table in the PCP file. See http://msdn.microsoft.com/library/en-us/msi/setup/upgradedfilestoignore_table_patchwiz_dll_.asp for more information.

Content credit also belongs to

Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
Hem, MSI Team Dev. You can get other Hem insights about developing for Windows Installer from the Windows Installer Chat Archives
Heath, Microsoft Developer. You can get other Heath insights about developing for Windows Installer from Heath's blog
Prashant, Microsoft Developer

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

"Stop Installation Idiocy" PCWorld's Hassle Free PC article

Windows Installer Team — Tue, 01 Nov 2005 17:00:00 GMT

While searching for news with "Windows Installer" in the subject, I recently came across the Hassle Free PC article Hassle-Free PC: Fix Stubborn Windows Install Errors where a reader asked for assistance with the Windows Installer dialogs under the subheading “Stop Installation Idiocy”. I thought I'd offer some deeper context on this scenario.

First, if this dialog happens during First Run of the application, this can be by design. Windows Installer encourages application to write their “user data” at first run of the application. This is particularly useful for applications that install to machines that will have multiple users such as home machines with Fast User Switching enabled or to business machines that multiple people will use.

Second, if the application is installing something “on demand”, this too can be by design. This Installation-On-Demand can be useful for a number of design reasons, particularly when an application has a feature that is less frequently. As a hypothetical, let’s say Word studied it’s features and discovered that Mail Merge was used quite infrequently save for holiday greetings times. The Office deployment developers could choose to expose the Mail Merge option on the menu but leave it on the CD until the user actually invoked it. At the point the user invoked Mail Merge, Word could recognize the bits were not installed and then call to the installation package (MSI) and ask for them to be installed. Given all this happens within the application context, the application can wait for the install to complete then load the functionality without the user ever having to leave their context. Admittedly, if a user is not aware that this is possible, this can be disorienting.

Third, if the application state has become inconsistent, this too can be by design. The Resiliency features of the Windows Installer are designed to both detect when an application is out of specification as well as provide actions to put the application back into compliance with the specification. From one point of view, one could say this is the Windows Installer way of addressing DLL Hell. Window Installer will be provide the file each application expects even if they are the same file path and file name. The only way to do this “correctly” is to swap the files out per application context. There are of course other solutions to DLL Hell from Microsoft including the Fusion technology and the Virtual Machine offerings each with it’s own strengths and weaknesses.

Though there are a number of by design cases for the Windows Installer dialogs occurring during application execution, there is the occasional break such as you cite in your article. A sophisticated user can differentiate these cases by following the FAQ entry Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation? That FAQ item reads as follows

Q. Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation?
A. An easy way to determine the cause of an on-demand installation is to look in the application event log for MsiInstaller log messages of the form:
Event Type: Warning Event Source: MsiInstaller Event ID: 1001 Description: Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example' failed during request for component '{00030829-0000-0000-C000-000000000046}' Event Type: Warning Event Source: MsiInstaller Event ID: 1004 Description: Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example', component '{00030829-0000-0000-C000-000000000046}' failed. The resource 'C:\Progam Files\example\example.exe' does not exist.

The first message (with event ID 1001) states which component was being installed. The component listed here is the component named in the Component_ column of the Shortcut table for the particular shortcut.

The second message (with event ID 1004) indicates which component failed detection. Improved event logging in Windows Installer 2.0 has updated the message so that in most cases, the message identifies the actual resource that resulted in the failed detection. The component with the missing or damaged keypath is the component that is triggering the reinstallation.

In the example above, the reinstallation is triggered because the resource 'c:\Program Files\example\example.exe' does not exist. You would then need to find out why the keypath does not exist—in this case, the user deleted it.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Where did my custom action permissions go? Terminal Server is special.

Windows Installer Team — Mon, 24 Oct 2005 08:25:00 GMT

The other day a user complained that they were trying to donfigure Active Directory and their queries were intermittently getting access denied. They had roughly identified the problem as having been related to the Windows 2003 server SP1 however they had not a clue why it worked intermittently. I pecked at the edges saying it would be better not to reply on script custom actions as script custom actions are notorious for not being able to debugged and introduce an unneeded dependency which has lead some to advise against their use (such as astebner and robmen)

Handyman Heath swung in and noted the log contained the reason for the failure:

Not impersonating action for per-machine TS install.

Carolyn then laid down the law:

This is because you're performing a per-machine installation on Terminal Server. There's a section devoted to terminal server behavior in the Windows Installer documentation on MSDN. Of particular interest for you is the topic "Using custom actions from a terminal server".

Using Custom Actions on a Terminal Server
This section describes the use of DLL, EXE, and Script custom actions only when all of the following conditions are true:

The installer package is being installed on Windows 2000 or later.

The package is installed on a system hosting Terminal Services. In this case, the installer sets the TerminalServer property.

The package is installed as a per-machine installation.
If all of the preceding conditions apply, custom actions run in an environment similar to that which exists when an application is installed with no user logged-in. In this case, the following are true:

Deferred custom actions run in the context of the local system unless the action has the msidbCustomActionTypeTSAware attribute. This is true even if the custom action would normally impersonate the user on a system that was not a Terminal Server....

...

So then the person with the problem asked "so if I set the type of the CA from 9222 to 9222 + 16384 we would be back to the original behavior and impersonating the calling user?"

Which Carolyn of course answered with "Yes, on those platforms where msidbCustomActionTypeTSAware is supported/available."

... and so we have yet another happy customer

Now if I could only find some documentation or logging magic that would help call these out without the homework.

Content credit also belongs to

Carolyn, MSI Team Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives
Heaths, Microsoft DevDiv CPX Dev. You can get other Heath insights about developing for Windows Installer from the Heath's blog.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Billboard bug is fixed in MSI Vista

Windows Installer Team — Sat, 08 Oct 2005 19:52:00 GMT

We've got a couple of pings on a billboard bug that I thought I'd share in case others are seeing this problem.

Problem

In Windows Installer 2 billboards showed one after another smoothly during InstallFiles action. With Windows Installer version 3, billboards showed twice during the install. The first time, the billboards showed during generating script and the second time was as they were displayed normally as in Windows Installer 2.

Reason

In MSI 2.0 it was only the GenerateScript action that was sending an ActionStart message while the script was being generated, but now we’re sending the ActionStart message for each individual action that is authored in the .MSI package’s InstallExecute table, while we’re generating the execution script for it. This causes the UI handler to see new actions coming in, to start counting the billboards and - if there are any - to display them in response to progress messages sent by the service.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Most frequent problem with the msi-fusion interaction? Incorrect authoring of strong name.

Windows Installer Team — Sat, 08 Oct 2005 02:18:00 GMT

Question

Most frequent problem with the msi-fusion interaction?

Answer

Incorrect authoring of strong name. This particularly crops up at uninstall time as the MSIAssemblyName table ends up feeding the wrong identity to the Fusion API. This doesn't break at install because the Fusion API does not need to use the identity during installation.

Specific Instance

After applying a Major Upgrade, assemblies from the previous version are remaining in the GAC. The log shows the assemblies being removed. Log Excerpts:

Action 9:00:32: RemoveFiles. Removing files
MSI (s) (80:74) [09:00:32:501]: Executing op: ProgressTotal(Total=5,Type=1,ByteEquivalent=175000)
MSI (s) (80:74) [09:00:32:521]: Executing op: SetTargetFolder(Folder=C:\)
MSI (s) (80:74) [09:00:32:551]: Executing op: FileRemove(,FileName=RTD.dll,,ComponentId={89D876CC-08E6-40BE-ADA1-60A06367E6EE})
MSI (s) (80:74) [09:00:32:571]: delegating uninstallation of assembly file : RTD.dll to Fusion
MSI (s) (80:74) [09:00:32:591]: Executing op: FileRemove(,FileName=ReplView.dll,,ComponentId={310E6806-274C-452F-92A0-84616E49D1BF})
MSI (s) (80:74) [09:00:32:631]: delegating uninstallation of assembly file : ReplView.dll to Fusion
MSI (s) (80:74) [09:00:32:651]: Executing op: FileRemove(,FileName=PerformanceHealthCheck.dll,,ComponentId={51AE0E7A-D7FE-48FC-B02A-4DE0375902FD})
MSI (s) (80:74) [09:00:32:661]: delegating uninstallation of assembly file : PerformanceHealthCheck.dll to Fusion
MSI (s) (80:74) [09:00:32:671]: Executing op: FileRemove(,FileName=DTClassLibrary.dll,,ComponentId={07047D05-CEB0-4EC5-B19F-E7F0BB5AFB3D})
MSI (s) (80:74) [09:00:32:821]: delegating uninstallation of assembly file : DTClassLibrary.dll to Fusion
MSI (s) (80:74) [09:00:32:861]: Executing op: FileRemove(,FileName=System.Runtime.InteropServices.APIs.dll,,ComponentId={CCB66762-BEAF-49D1-B265-C6D70067862C})
MSI (s) (80:74) [09:00:32:941]: delegating uninstallation of assembly file : System.Runtime.InteropServices.APIs.dll to Fusion

So Where's the ICE?

An ICE for this would break a bit of the mold for ICEs in that it would need to check the image against the authoring in the msi. Were we to break this barrier, here's what you'd need to do.

Enumerate the file table and look to determine which ones are managed assemblies.

Extract the assembly identity from each managed assembly in the MSI

Look in the MSI assembly name table to make sure that each identity you found has is also in this table. Any fewer is an error. Any ones you didn't find are also an error.

There are metadata APIs for (1), and Fusion APIs for (2). It's a little ugly because there is a processorArchitecture field, which is new for Whidbey that you have to treat specially.

Content credit also belongs to

Alan, Microsoft Dev
Carolyn, MSI Dev Lead. You can get other Carolyn insights about developing for Windows Installer from the Windows Installer Chat Archives

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Help Troubleshooing 'Error 2902. Operation ixfAssemblyCopy called out of sequence.'

Windows Installer Team — Tue, 04 Oct 2005 09:00:00 GMT

Question

Can you help troubleshooting 'Error 2902. Operation ixfAssemblyCopy called out of sequence.'?

Answer

The 2902 errors generally point to authoring issues. One case has been identified as authoring error wherein the win32 sxs components do not include a key path. For this case, adding a key path corrects the problem.