Windows Program Compatibility Assistant

Recently, the installer for HelpMaster started having issues and running foul of the Windows Program Compatibility Assistant.  This was strange, because nothing had changed in the installer for a long time.  A few weeks ago however, the installer started to display the following screen soon after invoking the installer.

The problem was, the software did not install at all - this appeared shortly after the installer was run.  Was the PCA being overzealous here?  Wrong even?  What install was it talking about!?  There was no install...it didn't happen!?

Research on this topic will have you chasing leads for operating system version checking, Vista UAC permissions, application and installation manifest files, bizarre Windows version GUIDs and numerous blogs from the Windows compatibility team, Stack-overflow and myriad other tech sources.

Checking the "Application" Windows Event viewer for the source "MsiInstaller" displayed an event with the words "ERROR_INSTALL_USEREXIT    1602    The user cancels installation."

eh?  The user didn't cancel the install - no GUI ever appeared?

We needed further information.  More logging diagnostics.  Setup.exe bootstrappers should have logging capabilities.  To get the HelpMaster installer logging information to a text file, the following statement was run from a cmd window running in Adminstrator mode.

"C:\HelpMaster testing\HelpMaster.exe" /log:"C:\HelpMaster testing\install_log.log"

That's when the true nature of the installation issue become obvious

After a lot of research, false leads and debugging, the issue turned out to be some LUA script reference to a non-existant .net 3.5 sp1 installation stub.  Basically, the bootstrapper was trying to run script that was not part of the installation dependencies - it simply didn't exist. This .net stub was supposed to be run before any of the actual .msi files were to run.

After commenting out the offending luascript in the bootstrapper code, the install worked fine again.

The strange thing is why this only just started to occur.  This issue had been part of the installation script for years, and it only just surfaced.  Did Microsoft update something?  Did Windows Installer update something?  Was this just a Windows 8.1 thing?

The strange, and awkward world of software deployment continues to frustrate. 

The lesson here for installation developers?

1. Always use clean, "test" machines to test software deployment
2. Understand the deployment process - particularly if using bootstrappers to run .msi packages.  This method is a 2-part process - the bootstrapper (.exe) unpacking one or more .msi files and running them according to code/scripting logic.
3. Understand Windows UAC and elevated permissions
4. Understand what your particular bootstrapper is doing
5. Use diagnostic logging when running setup.exe, install.exe etc to see what's going on
6. Check the Windows Event Logs for further clues
7. Read and research
8. Realize that this Windows information message above can be shown after your bootstrapper (.exe) runs, and before any .msi files are executed.  If nothing was installed, then it means you've got a problem with your bootstrapper code, as was the case here.

Another software lesson learned....another successful deployment....another check-in for source control.