Building and deploying Windows packages in enterprise deployments can be a challenge when it goes smoothly, but especially difficult when the package deployment hits bumps in the road. Just when you think you’ve got that application perfectly bundled, tested, and deployed, an unforeseen interaction can knock the legs out from under you.
And of course, the behavior of Windows Installer itself can be frustrating and may even seem a bit mysterious; making app deployment even more of a challenge. The installer follows very explicit rules for everything it does, and enforces them rigidly. Creating a log file for an .MSI installation might just be the saving grace – providing insight when troubleshooting installation errors and other unexpected behavior.
Most application packagers are aware that a verbose log file can be can be generated by passing the parameter
/l*v install.log to the Windows Installer engine (msiexec.exe). But what about when Windows Installer unexpectedly initiates a “self repair”, or errors occurs during an application uninstall?
Here’s one thing that can help: There is a registry value that can be set which causes all Windows Installer transactions on a system (installs, uninstalls, repairs, etc.) to be logged to a file. Just add the following key to the registry:
Warning: Don’t goof around in the registry if you don’t know what you’re doing. Seriously. Don’t.
Value Data (Reg_SZ):
Note that which temp directory the log file is created in depends on the user account under which the Windows Installer transaction was run. All the relevant information is logged: custom actions, property states, feature states, and error codes. These can be very helpful in resolving the issue!