ODBC driver msi Installation is failing in wix exe bundle package

Question

ODBC driver msi Installation is failing in wix exe bundle package

Pushpala, Thejesh 0

Hi Team,

I have created a Wix bundle exe package. In that i'm un installing older version of ODBC driver & trying to install newer version of ODBC driver. Older version un installation is working fine, but Newer version installation is failing. Below is the code

<Chain>

<ExePackage Id="ODBCUnInstall"

          DisplayName="InterSystems ODBC Driver (32-bit)"

          InstallCommand="/s"

          InstallCondition="(EXISTINGFILEVERSION &lt; v2018.1.10.816)"

            Description="Un install the existing ODBC Driver"

            SourceFile="ODBC_UnInstall.bat"/>
``` <!-- 32-bit ODBC InterSystems ODBC Driver - v2018.1.10.816 -->

 <MsiPackage

Id="ODBCDriver32"

Permanent="yes"

ForcePerMachine="yes"

Visible="yes"

DisplayName="InterSystems ODBC Driver (32-bit)"

SourceFile="$(var.externalDir)odbc\InterSystemsODBCDriver.msi" />


In "ODBC_UnInstall.bat" batch file below is the command has been placed.

msiexec.exe /x {BAB6C24A-9D62-4317-A22E-78A0ABF2DD4F} /qn /l*vx log.txt

Un installation is working successfully. But Installation of msi package is failing.

Could you please help me out in resolving this issue.

Regards,

Thejesh.

0 comments

2 answers

Your answer

Answer 1

Taki Ly (WICLOUD CORPORATION) 2,225 Microsoft External Staff Moderator

Hello @Pushpala, Thejesh ,

Thanks for reaching out.

The difficulty you might be experiencing could potentially relate to a Windows Installer Mutex conflict, which is logged as Error 1618. This situation might occur because a batch script initiates the uninstallation process and then exits almost immediately, and as a result, the WiX Burn engine might assume the batch step is fully completed. Consequently, it attempts to start the new MSI installation while the old msiexec.exe process may visibly still be running in the background, which I believe causes the two installation systems to clash.

To resolve this problem, I would suggest looking into a standard alternative, and perhaps the cleanest approach could be utilizing the built-in <MajorUpgrade> element directly within your new MSI. Generally, you do not need a batch file to uninstall older versions, therefore configuring your new MSI to automatically upgrade the old package using their shared UpgradeCode could resolve the timing conflict. Inside the WiX source code (.wxs file) of your newer MSI, you could simply incorporate the following element:

<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />

Alternatively, if modifying the MSI source is not feasible and the old driver belongs to an unrelated third-party package that you must remove by its Product Code, I would recommend avoiding the batch file altogether. Instead, you could call msiexec.exe directly within your <ExePackage>, which would allow the WiX engine to accurately track the external process state and ideally wait for it to finish gracefully, possibly adapting your configuration as follows:

<ExePackage Id="ODBCUnInstall"
          DisplayName="InterSystems ODBC Driver (32-bit)"
          SourceFile="[SystemFolder]msiexec.exe"
          InstallCommand="/x {BAB6C24A-9D62-4317-A22E-78A0ABF2DD4F} /qn /l*vx log.txt"
          InstallCondition="(EXISTINGFILEVERSION...)" />

For further context, I would invite you to review some official documentation that might provide more insights, starting with the WiX Toolset Documentation regarding Major Upgrades. Moreover, you can find additional details about mutex conflicts in the Microsoft documentation covering Windows Installer Error 1618.

Disclaimer: Some links are non-Microsoft website. The pages appear to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classifies as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

I hope these suggestions may point you in the right direction. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Pushpala, Thejesh 0 Reputation points

2026-06-12T08:06:35.0333333+00:00

Hi Thanks for your reply.

ODBC is a external package provided by Inter Systems cache.

I have removed batch file & Un installation is doing in ExePackage "Installation" command as recommended by you. But same issue exists again.

Un installation of ODBC is successful. But installation of ODBC is failing

Could you please help out in resolving this issue.

Regards,

Thejesh.
Taki Ly (WICLOUD CORPORATION) 2,225 Reputation points Microsoft External Staff Moderator

2026-06-12T09:31:05.5+00:00
Hi @Pushpala, Thejesh ,

Thanks for providing that update.

Since the batch file has been removed and msiexec.exe is now called directly, the continuing failure might potentially stem from a different constraint, such as a pending system reboot. Because ODBC drivers usually integrate deeply with the Windows operating system, their uninstallation could often leave behind locked resources or registry keys. Consequently, the uninstallation command might actually complete but could potentially return an exit code of 3010, which indicates a pending reboot, and your bundle engine might perhaps be ignoring this and attempting to proceed with the new installation anyway.

To accommodate this, I suggest adjusting the <ExePackage> configuration to explicitly handle this reboot exit code could prove quite useful, enabling the Burn engine to appropriately orchestrate a system restart if necessary. Incorporating this behavior alongside the existing setup might look something like this:

<ExePackage Id="ODBCUnInstall" DisplayName="InterSystems ODBC Driver (32-bit)" SourceFile="[SystemFolder]msiexec.exe" InstallCommand="/x {BAB6C24A-9D62-4317-A22E-78A0ABF2DD4F} /qn /l*vx log.txt" InstallCondition="(EXISTINGFILEVERSION...)"> <ExitCode Value="3010" Behavior="forceReboot" /> </ExePackage>

Additionally, the underlying failure for the new MSI might not actually be the Mutex conflict anymore, so inspecting the installation log files would be highly recommended to identify the exact new error code. Reviewing the log.txt output from the uninstallation step along with the master log automatically generated by the WiX bundle could provide further insights, and checking the WiX documentation regarding ExePackage ExitCodes might also be helpful.

Hopefully, this approach could clear up the remaining obstacles, and sharing those logs would be appreciated if further assistance is needed.

Thank you.
Pushpala, Thejesh 0 Reputation points

2026-06-12T11:02:54.1266667+00:00

Thanks for your reply.

I have tried above suggested ExitCode include. But still no luck. Still Installation of ODBC not happening

Regards,

Thejesh.
Taki Ly (WICLOUD CORPORATION) 2,225 Reputation points Microsoft External Staff Moderator

2026-06-15T08:16:58.4466667+00:00
Hi @Pushpala, Thejesh ,

Thanks for following up.

Since the reboot code adjustment did not resolve the problem, inspecting the exact error code from the installation logs might possibly be the most crucial next step. The Burn engine automatically generates a master log file in the %TEMP% directory, usually named after your bundle, which could potentially contain the specific failure reason for the new installation phase. Reviewing this master log could perhaps reveal whether the issue relates to insufficient privileges, lingering locked files, or another localized conflict.

To capture the most comprehensive details, enabling verbose logging during the new installation package's execution could prove quite helpful, and you could perhaps reference the Microsoft documentation on Windows Installer logging for further guidance. Additionally, if the new driver is structured as an <MsiPackage>, ensuring it installs with machine-wide administrative rights might also be worth attempting, perhaps by modifying your chain to incorporate a property setting similar to this:

<MsiPackage Id="NewODBC" SourceFile="path\to\new.msi"> <MsiProperty Name="ALLUSERS" Value="1" /> </MsiPackage>

Sharing the relevant failure lines or exact error codes from those log files would be immensely appreciated, as diagnosing the precise root cause without that background data could perhaps prove somewhat difficult.

Thank you.
Taki Ly (WICLOUD CORPORATION) 2,225 Reputation points Microsoft External Staff Moderator

2026-06-17T09:05:45.28+00:00

Hi @Pushpala, Thejesh ,

Have you seen my follow-up in this post? If you have any question, feel free to reach out. I'm happy to support you.
Pushpala, Thejesh 0 Reputation points

2026-06-17T09:08:45.9833333+00:00

Hi Taki Ly,

Thanks for your reply. I was working on some other priority item. Give me some time i will share you the log details.

Regards,

Thejesh.
Taki Ly (WICLOUD CORPORATION) 2,225 Reputation points Microsoft External Staff Moderator

2026-06-17T09:12:34.9166667+00:00

Hi @Pushpala, Thejesh ,

Thanks for the update! Please take your time. Once you have the logs ready, feel free to share them here and I’ll take a look right away.

Thank you.
Taki Ly (WICLOUD CORPORATION) 2,225 Reputation points Microsoft External Staff Moderator

2026-06-19T06:33:52.83+00:00

Hi @Pushpala, Thejesh ,

Do you have any update on this post?

Answer 2

The bundle is uninstalling the old ODBC driver successfully, so the failure is almost certainly in how the new MSI is being invoked or in the MSI’s own upgrade logic, not in the uninstall batch.

From the available information, the following points are relevant:

ODBC drivers are MSI packages that can be installed and upgraded side‑by‑side or blocked by their own upgrade rules. For example, Microsoft’s ODBC driver MSI (msodbcsql.msi) supports side‑by‑side major versions and uses standard MSI upgrade logic to prevent an older package from installing over a newer version.
MSI packages can be authored so that they refuse to install if a newer version is already present. This is done via the MSI Upgrade table and related actions. If the InterSystems ODBC MSI has similar logic, it may be detecting a newer or conflicting product and aborting.
When an MSI refuses to install due to an upgrade condition, Windows Installer typically returns an error code and message such as “A higher upgrade is already installed” and the installation fails.

To move forward, the MSI log from the failing MsiPackage is required. In a WiX Burn bundle, the engine can log the MSI execution; that log will show the exact Windows Installer error code and message. Without that log, the failure reason is opaque.

Based on the context, the recommended steps are:

Enable and inspect MSI logging for the MsiPackage:
- Configure the bundle to generate verbose MSI logs for ODBCDriver32.
- Reproduce the failure and open the MSI log.
- Look for entries around FindRelatedProducts, MigrateFeatureStates, and any CustomAction that returns an error, as well as messages like “A higher version of this product is already installed.”
Check whether the MSI is blocked by its own upgrade rules:
- If the log shows that the MSI detects a newer product and sets an action property (similar to NEWPRODUCTFOUND) and then runs a type 19 custom action (“A higher upgrade is already installed”), the MSI is intentionally refusing to install over what it considers a newer or conflicting version.
- In that case, either:
  - Adjust what is uninstalled (correct product code/upgrade code/version), or
  - Use the vendor’s recommended upgrade path for that driver version.
Verify that the correct product is being uninstalled:
- Confirm that the product code {BAB6C24A-9D62-4317-A22E-78A0ABF2DD4F} in msiexec /x actually corresponds to the product that the new MSI expects to upgrade or replace.
- If the MSI’s UpgradeCode or product code set does not match what is being removed, the MSI may still detect a related product and block installation.
If the MSI is a third‑party ODBC driver:
- For third‑party ODBC drivers, supported checks are limited to:
  - Verifying that the driver’s registry keys exist and point to valid DLL paths.
  - Creating a test DSN and performing a connection test.
- Any deeper troubleshooting of the MSI’s internal upgrade logic (Upgrade table, custom actions) must be done with the driver vendor, since only the vendor knows the intended upgrade behavior.
General MSI upgrade pattern to prevent downgrades (for reference):
- An MSI can be authored so that it installs over older versions but refuses to install if a newer version is present. This is done via entries in the Upgrade table and a type 19 custom action that aborts when a higher version is detected. If the InterSystems MSI uses this pattern, the log will show it.

In summary, the WiX bundle structure is not inherently wrong; the failure is almost certainly due to the InterSystems ODBC MSI’s own upgrade/downgrade rules. The next step is to capture and review the MSI log for ODBCDriver32 to see the exact Windows Installer error and, if it indicates a higher version or related product is already installed, adjust the uninstall/upgrade strategy or work with the driver vendor.

References:

Share via

ODBC driver msi Installation is failing in wix exe bundle package

2 answers

Your answer