Microsoft: I fixed the XPS Essentials Pack for you. It took 10 minutes.

For the impatient, download my transform file and execute msiexec /i <msi> TRANSFORMS=<transform>.

There are only a few things that come close to being as extremely frustrating as receiving a Microsoft XML Paper Specification (XPS) document and not being able to open it. Sure, double-click it you say. Interesting, Mozilla Firefox wants to open it with the XPS viewer, okay. Oh look, I’m stuck in a loop and the number of tabs are increasing… Let’s force Internet Explorer to open it… oh, it’s just hanging… Sigh.

To avoid the awful ActiveX XPS control/viewer that’s baked in with the .NET Framework (3.0+), I tried to install the XPS Essentials Pack, which includes (thank God) a standalone viewer. I answered the installer’s questions and let it churn for a bit. Nearing completion, I was presented with an unavoidable error. Figures.

Following Microsoft Installer debugging protocol, I re-ran setup passing the /l*v install.log switches and argument to dump everything it’s doing to a flat file. Grep’ing out all the properties and such, I found these lines:

Action 16:56:17: WICUpdateInstallAction.
Action start 16:56:17: WICUpdateInstallAction.
Action ended 16:57:09: ExecuteAction. Return value 3.
Action 16:57:09: FatalErrorForm.
Action start 16:57:09: FatalErrorForm.
Action 16:57:09: FatalErrorForm. Dialog created
Action ended 16:57:10: FatalErrorForm. Return value 1.
Action ended 16:57:10: INSTALL. Return value 3.

The above snippet is pretty self-explanatory. A custom action named WICUpdateInstallAction is being executed and is returning a value of 3. One can safely assume this is bad, due to the next action FatalErrorForm being called.

Looking at the Custom Action table within the MSI (with a tool like SuperOrca), I noticed WICUpdateInstallAction executes a binary labeled WICUPDATE. I dug it out of the Binary table and ran it manually to see what’s going on.

Invoking wicupdate.exe manually resulted in the display of familiar hotfix dialogs, but I was greeted by the following error message:

It appears the Microsoft XPS team bundled a hotfix with their installer that is executed unconditionally, but throws an error if it’s already installed. I fired up Orca, created a new transform slate, then dropped the row in the InstallExecuteSequence table, which lists the actions, and their associated sequence, performed during install. This will skip the installation attempt of an update we don’t need and suppress the error. (I could have patched the MSI directly, but I wouldn’t have been able to legally distribute the fix. It’s copyrighted content, after all)

To start the installation with my new transformation logic, I executed msiexec /i <msi filename> TRANSFORMS=<transform filename> and setup completed without a hitch. I opened the XPS document I received, printed it, and went on my way.

What has me confused worried is that the Microsoft XPS team has yet to provide an official fix to what is a laughably trivial problem. Paul Thurrott was quick to defend Microsoft in our conversation, however, saying “… yeah but you probably didn’t regression test [the fix] against Swahili Windows…”.

We’ll see what happens. It’s been almost a month; it took me 10 minutes to fix.