Tag Archives: wix

Tips for debugging a WiX MSI

WiX is an excellent technology that simplifies the creation of MSI files using an XML abstraction on top of the Windows Installer APIs. WiX doesn’t change the underlying MSI architecture and it can be a huge pain in the ass sometimes. I thought I would share some tips for debugging what’s going on with an MSI. These tips aren’t specific to WiX, that’s just the technology I’m familiar with.


The first thing you should try is to add the log switch when you run your installer. To do this, open a command prompt in the directory where your MSI file is located and run it with the following parameters:

msiexec yourinstaller.msi /L*v install.log

The /L*v says to log verbose messages to a file.

For a full list of msiexec switches, check out MSDN’s documentation for msiexec.

Re-cache MSI

If you think your package was somehow corrupted or you’ve made a simple such as changing a file’s guid or a feature condition, you can re-cache the package with the following command:

msiexec /fv yourinstaller.msi

This is generally used when you install a product and then thing “oops, I forgot something…”. You don’t want to create a whole new release, so you can update the installed/cached MSI.

Be careful to read the documentation. With the /f parameter, you can’t pass properties on the command line.

Increased Debug Messages

You can actually increase the amount of messages exposed to MSI logs by setting a machine policy for Windows Installer.

Open regedit and go to HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer (you may need to create this key). Add a DWORD key called Debug with a value of 7.

The value of 7 will write all common debugging messages to the log as well as command line information. If you’re passing sensitive data to the installer on the command line, be warned that this information gets dumped via the OutputDebugString function. This means that anyone with physical access to the machine or access to the machine via TCP/IP may be able to read these messages. The documentation for the policy settings warns that this setting is for debugging purposes only and may not exist in future versions of Windows Installer.

For a full list of available settings, check out Microsoft’s Windows Installer Machine Policies.

System Debugging

Passing the logging switch and log file name to an MSI every time you run an MSI can be annoying. You can set the Logging machine policy to have Windows Installer write a log to a temp file, but then you have to track down the temp file.

Instead, you can run Sysinternals’ DebugView. This utility allows you to catch debugging information exposed by the Win32 OutputDebugString function on local and remote machines. This doesn’t just gather information from MSIs. For example, you can open a TFS query editor in Visual Studio 2013 and inspect the queries made via TFS.


Lastly, the Windows SDK contains a file called Orca.msi. Orca is a tool to inspect the contents of an MSI. An MSI is essentially just a database of tables and fields with values. You can open an existing MSI, edit a condition, and save it. This can make investigation a little easier. For instance, if you’re trying to figure out why a condition on a custom action doesn’t seem to be passing, you can edit the MSI and modify the condition instead of rebuilding the MSI. It’s also helpful if you’re trying to figure out how another MSI implements some logic.

I’m sure there are plenty of other techniques for debugging MSI files.

“Unable to update the dependencies of the project”

I’ve recently had to switch from Visual Studio 2012 back to Visual Studio 2010 to do maintenance on another project. This project is currently stuck in Visual Studio 2010 until I have time to convert the old setup projects to WiX. I often receive the following error message during Release builds:

"Unable to update the dependencies of the project"

Closing Visual Studio 2010 and reopening seemed to have fixed the problem up until about a week ago. I’ve found that installing this hotfix seems to resolve the issue. The only problem is that I’ve had to install the hotfix multiple times.

The ’cause’ on the hotfix page says the issue is a result of how Visual Studio 2010 refreshes dependencies. I wonder if this is handled by Windows Updates updating the .NET Framework? Whatever it is, it’s pretty annoying to have to apply this patch regularly. I guess it’s just another reason for developers to move setup projects to WiX.


WiX Installer Update

One thing that has caused me quite a few problems with my WiX installer was optionally displaying a dialog to enter SQL information when the database is installed.

I may change the database to be a critical element of the intall, but I thought this would be a good share.

Based on:

http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx and http://geekswithblogs.net/jwatson/archive/2006/11/03/96052.aspx

To set the next button to display based on features chosen in the feature tree, you can do someting like this:

<publish dialog="CustomizeDlg" control="Next" event="NewDialog" value="SqlSetupDlg"> 1 </publish>

Where “Database” is the name of the feature you want to install.

Other access prefixes are:

  1. (none) Installer property: Value of property (Property) table.
  2. % Environment variable: Value of environment variable.
  3. $ Component table key: Action state of the component.
  4. ? Component table key: Installed state of the component.
  5. & Feature table key: Action state of the feature.
  6. ! Feature table key: Installed state of the feature.

WiX: First impressions.

After working with WiX today, I realized that it’s not perfect. But, it isn’t horrible. Maybe my issues are from following “tutorials” that are written for WiX 2.0, while I’m using WiX 3.0.

Whatever the reason, I have encountered only a few problems so far:

  1. <removefolder id="FolderName" on="uninstall">

    this caused a lot of errors. I don’t know if WiX 3.0 has changed how it handles removal of folders? I noticed when I uninstall without specifying , it actually removes the folder properly. (I’m using this on a folder under ProgramMenuFolder)

  2. Creating a new UI and adding dialogs was a pain. Referencing my dialog with

    kept throwing errors. Quite a few google searches later, I still couldn’t find a fix or a reason for the errors. The resolution: instead of creating the dialog in a different file as a Fragment, I just added it to the file modeled after WixUI_Mondo. After doing this, the dialog worked. Maybe fragments are broken? Or, maybe I wasn’t compiling and linking the library properly.

  3. Many tutorials refer to a tool called tallow to create a Fragment of Components/Files. But, the tool is now called Heat. It’s a useful tool, but I’m still having problems getting Fragments that I create to work right.

That’s about it, I will write up some solutions to these problems if I find them.