How to debug an MSI installation
|Article:HOWTO4103|||||Created: 2006-06-29|||||Updated: 2006-07-12|||||Article URL http://www.symantec.com/docs/HOWTO4103|
How can I debug my Windows installer MSI when things go wrong?
The first step in debugging is to enable verbose logging of the install. The Microsoft Windows Installer SDK* help file, MSI.CHM, installed with Wise for Windows Installer and Wise Package Studio, can be searched on MSIEXEC to provide a list of switches for logging, amongst other functions.For verbose logging of an install, a typical msiexec command line might look something like this:
msiexec /i yourfile.msi /L*v c:\temp\yourinstall.log
The 4-digit error codes can be searched for in MSI.CHM to determine their meaning.
Logging can be used for uninstalls as well as installs.
In addition, there is a utility called WILOGUTL.EXE which can help analyze Windows installer logfiles and bring obvious errors to your attention. This utility is available in the Windows Installer SDK, part of the Platform SDK, downloadable from Microsoft. There are different versions available, the latest version being in the Windows 2003 Server SP1 SDK.
To do more in-depth debugging for items such as Custom Actions, the utility DebugView from SysInternals.com can provide another level of diagnostic assistance.
It is necessary to add the Debug (DWORD) entry under "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" and set it to the value of 2.
(From the Platform SDK Help file):
If this per-machine system policy is set to "1", the installer writes common debugging messages to the debugger using the function. If this value is set to "2", the installer writes all valid debugging messages to the debugger using the function. This policy is for debugging purposes only and may not be supported in future versions of Windows Installer.
Note that with Windows Installer version 2.0 and later versions the installer only writes command lines into the log file if the third (0x04) bit is set in the value of the Debug policy. Therefore to display command lines in the log, set the Debug policy value to 7. This does not display properties associated with an Edit Control having the Password Control Attribute set or properties included in the MsiHiddenProperties property. For more information see How do I prevent confidential information from being written into the log file?
Start WinDebug and run your installation.
When you get the error dialog do not click ignore, instead go to DebugView and see what action is triggering the error.
Type 38 Custom Actions
Type 38 custom actions (embedded vbscript) are extremely useful for analysing what is going on within an install. One typical failure scenario that has been encountered in a real-world situation is an MSI which installs perfectly when installed manually, but hangs when installed by Active Directory.
In order to identify which action was causing the hang, a transform was used to insert a Type 38 custom action before every standard action in the InstallExecute sequence. Each Type 38 CA had a single line of code to display which standard action was to run next, for example:
msgbox "The next action is ISCleanUp"
During deployment by AD, a series of dialog boxes were displayed, requiring an "Enter" to continue, which indicated the next action to run. When the hang occurred, it was immediately evident which action was the cause, and further remedial actions could follow.
This technique is also useful for checking the value of properties at different points in the install, or uninstall.
A line of code such as
will display the contents of the public property PROPERTYNAME when the custom action runs.
Details of the msgbox function can be found in the Windows Scripting Host help file: Script56.chm, available from the Microsoft Web site.
Article URL http://www.symantec.com/docs/HOWTO4103