Unable to merge Windows Installer database

[CJ Woolard]

When attempting to compile our installation project we suddenly started getting the following error which is preventing us from deploying the installer:

Error during build: Unable to merge Windows Installer database with module [/b]

[dunion]

I just started getting this with IA9

[dunion]

I can remove all merge modules and add a 32 bit merge module and it builds. I started a clean project, tried to add a single 64 bit merge module, that fails, but adding a 32 bit one works. Still seems like machine or application (IA) setting. Any suggestions as to what to look at appreciated. This started after I used ORCA as requred to edit one of our third party merge modules.

[dunion]

Same results, can no longer merge with an x64 merge modules.
Any idea why? I tried a clean install on a fresh vistax64 machine. Install went OK, can do everything but merge with x64 merge modules. Is this the effect of some recent microsoft update to the install system that is incompatible with installaware for all x64 systems?

[dunion]

I was able to run process monitor while the install was building. The installer builds the msi file, then as it attempts to open the msi file to merge the 64 bit merge modules at the low level it's get's an access denied trying to open the file because it is opened for write access by either another thread or someone else - at the time, nothing was running on the system except for InstallAware 9 (current build). I am running InstallAware on Vista x64 Professional OS on both machines. I am going to try to install InstallAware into a 32 bit Virtual Machine and see if that has the same problem or not; if not, that will be a potential work-around. Will InstallAware install and run on a VM?

Thanks.

[dunion]

If I install InstallAware onto a 32 bit VM (MS Virtual PC) on my x64 machine and run the same install, there is no problem merging the x64 bit merge modules, so the problem appears to be only when running installaware directly on the x64 systems. I have so far only tried Vista, I have not tried running InstallAware on Windows 7.

If there is any further diagnostics you want to help get a fix for this problem please let me know. My work-around for now is to build this install on the x32 VM.

[dunion]

RC for R2 update seems to have this working correctly again, same project.
Thanks.

[dunion]

For my problem I identified the trigger. I had installed ORCA to edit some MSM files. That seems to toast InstallAware's ability to add 64 bit merge modules - even re-installing/repair didn't work to fix it. For the 'new version' I was able to verify the problem still exists by setting a restore point, installing ORCA, problem reproduced, restore to restore point, problem is gone.

So something is being registered I'm guessing by ORCA that messes up IA9 and IA9 R2. And the install/repair can't fix it, so it must not be re-registering whatever it is.

The work around for me is never to install that on the same system but my guess is some 'other stuff' from microsoft might do the same thing and other people that get into this state have something that isn't registered quite right.

[MichaelNesmith]

That's very odd, but thank you for the sleuthing!

We have Orca installed right here, but no problems with it so far.

Do you mind sending us your version of Orca that messes things up, along with the specific MSM in question?

We will try to reproduce this in-house and develop a workaround. You could also use PackageAware to determine exactly what Orca setup is doing.

[NathanAfLarac]

I also have the exact same problem om my computer, but I have not installed ORCA.

Any more information on this problem before I start setting up an virtual test computer to analyse this even more?

[dunion]

FYI my solution to this, whose root cause I don't know but maybe is a result of some sort of update of an MS component that causes some 'over-registration' is that if I fully uninstall and reinstall IA, the problem is fixed for 'a while'. Installing Orca definitely breaks it, uninstalling Orca sometimes is a fix (Orca as found on MS site or from inside the SDK Tools, etc.).

So far in all cases a full uninstall/reinstall fixes it. Repair does not.

It doesn't seem to be SP specific on IA9 IA9R2, etc.

[CFConner]

Dunion, please run ORCA and go to Help->About and tell us the version number you have. The latest version of ORCA out there is 5.0.7069.0

=-Chris

[dunion]

Thanks but if I run ORCA it will break InstallAware, causing me to have to uninstall and reinstall to get it even somewhat working again, I've verified that twice now, and I don't have that kind of extra time today or the rest of this week. I would like to resolve the Authenticode issue first then maybe in week or so I can do this test after we get the high-priority two installs built tested and released.

Thanks.

[NathanAfLarac]

I have done some analyze and testing of this problem in a virtual environment and this is what I know so far. I have also found some ways to work around this problem until a permanent solution is found.

My Testing Environment
• A Clean Windows 7 Enterprise (x64, eng) installation
• InstallAware 9 R2 (Studio Admin)
• ORCA (ver: 5.0.7069.0)
• Visual Studio 2010 Premium (full installation)

How to reproduce the problem
1. Install a clean Windows 7 installation.
2. Install InstallAware 9 R2
3. Install Visual Studio 2010 or ORCA

After this it is not possible to build a project in InstallAware that merges with the merge module “Microsoft_VC100_MFC_x64.msm” (the x86 version is till OK). I create a new InstallAware project based on the Basic template and added the merge module.

Reason for the problem
The problem can be nailed down to a COM file named “mergemod.dll”. When InstallAware is installed this file is installed by InstallAware to the folder “C:\Program Files (x86)\InstallAware\InstallAware 9 R2”. This COM file is also registered to the registry during the InstallAware installation.

When I install ORCA or Visual Studio 2010 the same file (but new version) is installed to the folder “C:\Program Files (x86)\Common Files\microsoft shared\MSI Tools” and registered to the registry. Since the registry now point to the newer version of COM object InstallAware will use the new version of the file “mergemod.dll” while building the setup instead of the file in the InstallAware folder.

InstallAware don’t work when using the newer version of the file “mergemod.dll” and merging with x64 merge modules.

My suggestion for a workaround until a fix is release
Workaround 1
Simply replace the “mergemod.dll” file in the folder “C:\Program Files (x86)\Common Files\microsoft shared\MSI Tools” with the file from the InstallAware folder “C:\Program Files (x86)\InstallAware\InstallAware 9 R2”.

Workaround 2
If you want to install ORCA you can also avoid this problem by selecting a “custom” installation and making sure that the component “Merge Module Support” is not installed. This will make sure the newer version of mergemod.dll is NOT installed.

Different versions of mergemod.dll
Installed by InstallAware
Date: 11/12/2004
Version: 2.0.3790.0

Installed by Orca
Date: 4/22/2009
Version: 5.0.7069.0

Installed by Visual Studio 2010 Premium
Date: 3/18/2010
Version: 5.0.7600.16385

Comments
I have the same conclusion as dunion, if I use “Process Monitor” from SysInternals I can see that InstallAware is denied write access to the output .msi file because it is already open by some other process. When I get this problem I can’t delete the .msi file in the output folder until I close InstallAware. I don’t know the reasons for this, but it might help InstallAware to find a fix for this problem.

I hope this information will help other until a permanent solution is found.

[CFConner]

Nice troubleshooting guys!