If you find that you can't uninstall a product once its installed then I'd recommend that you read the "Uninstall Fails (Don't Panic)" section :-)
- This debug macros may come in handy:
- Installation fails on Vista (only)?
Please see
"7 Reasons Why your Installations May Fail on Windows Vista (And How You Can Fix Them)
".
The symptoms covered are:
- A verbose log contains messages like "Ignoring Disallowed Property PROPERTYNAME".
- Custom actions scheduled for immediate or deferred execution fail with error 1721.
- Custom action fails even though it is set to run "Deferred in System Context".
- When you launch your setup by double clicking the .msi file or running msiexec it fails,
but if you launch it using setup.exe your setup succeeds.
- Your setup fails if run in silent mode,
e.g., using msiexec /q, but succeeds in Full, Reduced, and Basic UI modes.
- The built-in account named "Administrator", which is disabled by default,
is treated in a special way. UAC restrictions do not apply to this
special account, but they do apply for all other members of the Administrators group.
- While your setup executable unpacks or downloads,
it fails with a message similar to
"Unable to save file C:\Windows\Downloaded Installations\...".
- Installation of your product uninstalls another!
You have probably forgotten to generate a new GUID for the
upgrade code.
This is typically set with "Guid.UpgradeCode"
statement in the
version file.
The two packages probably share the same upgrade code and both
(or at least your new package) has entries in the
"Upgrade" table
(or some other mechanism) to automatically
uninstall other versions of the product.
- Look First
Before dismissing any installation error error messages
(installation rollback hasn't happened yet), have a good look at the
environment (installed files, registry, schedules etc).
You could for example manually try any failing command lines to see
if you can work out what is wrong.
- Check my Error Codes Section
If you have an error message of return or error code then you should check the "Error Codes" section of this manual.
- Check MAKEMSI output for WARNINGS
If you get and "WARNING XXXX: type messages possibly due to redefining some values etc, don't ignore them, you should eliminate these first just to be sure...
- Windows Installer Error Messages
Windows Installer may display or log some error codes such as "2740",
while these are not documented, they are listed in a section of the
"MSI.CHM" document (also online) called
"Windows Installer Error Messages
".
Some of these are listed in this document in the "ErrorTemplates.TXT"
section.
It is worth looking at the listing even if Windows Installer
displayed the message text as I've seen it "miss" bits
(for example the middle of a message gets dropped).
It is also worth looking at the
verbose log as the popup message
may have dropped something critical (and you won't know if it has)
but I've never seen the log do so.
Always search Windows Installer logs for
"Return Value 3", if found this indicates a custom action
failed.
- Windows Installer Error Codes
Some codes which may be returned by
MSIEXEC.EXE or appear
in logs are documented at
"http://msdn.microsoft.com/en-us/library/aa368542.aspx
".
- VBSCRIPT or other CA Logs
If the error occurred in a custom action generated with
the "VbsCa" command then this will be traced,
(including in any verbose log)
hopefully providing all the information you need.
Due to MS restrictions vital information can't be captured in
Javascript or even worse in VBSCRIPT, so it sometimes pays to
either insert "here I am" type messages in the script to narrow
down the source of the failure or to run from the command line.
For example if a VBSCRIPT variable is undefined you wont't have the
variable name when running as a custom action but
(at least by default), it will be displayed on failure as a
WSH script run from a command prompt.
- Verbose Windows Installer Log
It is almost always useful to create a
verbose log
of the install, the easiest way to do this is via
the explorer "Install - Verbose Logging" option.
If you are having problems with property values it would pay to
search the whole log for all references to the property in case
there are some unexpected differences.
The log will also tell you whether or not features and components
were scheduled for installation.
The Windows Installer formatting is amongst the worst
I've ever seen and very cryptic but it is still worth having
a look.
The "View Verbose MSI Log" option can make
it easier to read the log.
- Event Log
Windows Installer generates some messages into the event log.
Some of the messages are particularly hopeless and simply
mention a Feature name and a GUID making problems very
difficult to diagnose.
This is a good reason for using a descriptive name which
includes a version number for the "Complete" (or any other)
feature.
- Installing on Vista or newer Operating Systems?
The security has been radically changed so even administrators may
have difficulty installing.
Custom actions may need their attributes changed to work.
- Files Installed or Changed?
If you need to check what files are installed and if they
differ from what was packaged then the simplest way is to open
up the doco (via ARP is one way) and click the verify button.
This will very quickly show you what is installed and changed.
If possible it will check MD5 checksums as well!
If files are not installed where expected the verify will
currently fail (I will eventually get around to fixing this),
it will however correctly report package and component state.
- Double check Custom Action Sequencing
Did you duplicate sequence numbers, if so you probably got a
validation problem and at install time you don't know which one will
install first (or if its always consistent).
- Custom Action Conditions
If your conditions aren't evaluating to what you'd expect then
double check not only the syntax but also the
generic Windows Installer documentation for the life cycle of the properties or
evaluations you are performing.
As an example conditions that look at component or feature state
or actions must be sequenced after "CostFinalize".
- SYSTEM Account Can't Access MSI?
If not installing from the "C:\" (root directory), try copying
the MSI there and install.
If the MSI is on a "net used" drive the system account may not be
able to access this drive letter, if its accessed with a UNC name then
again the system account probably can't access it.
This is a windows installer limitation.
- MSI in an Encrypted Folder?
I've been informed that installs can (always?) fail if the MSI is
run from an encrypted directory.
Again try installing the MSI from the "C:\".
Not sure if compressed folders also cause problems...
- MSI on a Substituted Drive?
An MSI install will probably fail if run from a substituted drive.
Again try installing the MSI from the "C:\".
- MSI Needs Access to other dirs or drives
The comments above about encrypted folders, network or substituted
drives probably also apply to custom actions (at least those that
don't impersonate the user).
- Shortcuts not created (or 1909 error)?
Note that if a non-advertised
shortcut doesn't get created at all (no message) or
you get a runtime error "1909" it is possible that the "Target"
parameter of the Shortcut was invalid
(ensure you supplied the full path to it).
- Policy Issues?
If not installing from the "C:\" (root directory), try copying
the MSI there and install.
I have seen issues from removeable drives and even other
fixed hard drives.
- Related to Windows Schedules?
If its a schedule related issue then see the "Schedule Tips" section.
- Related to Windows Services?
If its a service related issue then see the "Service Tips" section.
- Transform Limitations
Be aware that transforms can't capture all details
(for example "_Streams" table
changes).
- If the problems are with extraction of cabinet files at install time
then see the "Cabinet File Size Limitations" section.
- Determining Cause of Issue based on Modification Time
Sometimes your problem was caused by some event in the past,
if this problem created a file then it is simple to get the creation,
modification or access times to determine when an issue occurred and
try to correlate this with log files or
Event Log entries.
If you have a registry value then its modification time can be
obtained with tools like "KeyTimes.exe".
- Some sundry symptoms...
- Read my doco!
Read it again. If the problem is with a specific command or feature then re-read its documentation (slowly and carefully - follow hypertext links). If a command pay particular attention to any prerequisites and default parameters. A large percentage of the queries I get have already been documented by me (even down to the exact error message). I do get grumpy when this happens. The compiled help has a good search facility - use it. If the documentation is not clear and you can tell me how to improve it then tell me! I am always improving the documentation so check the online version. Be sure to also check out the "bugs" section.
- Check a command's parameters and documentation!
If you have never read the "command parameters" section of the documentation then do so now! Many commands have optional parameters but that doesn't mean they mightn't need to be supplied in some circumstances (its just that they are not always required). Sometimes you need to supply one of a number of optional parameters. If you are having problems with a specific command then re-read its documentation and examine any samples that MAKEMSI installs or documents.
- Norton's Malicious Script Detection
The "Norton's Malicious Script Detection" message might be seen while building an MSI and might also be seen if you are installing an MSI that makes use of the "JsCa" or "VbsCa" commands. - Silent Termination by AntiVirus or AntiSpyware Garbage
Its possible that the creation or updating of an MSI might fail in "strange" ways. Its worth testing for AntiVirus or AntiSpyware issues.
- Double Check Validation and Filtering
It would be wise to have a closer look at any MSI validation messages you have been ignoring or if there were none have a look at the unfiltered output (which is kept). See if a message is listed in the "ICE Messages" section! If unsure I recommend looking in Microsoft's MSI forum
for information on the specific message. It also might be a good idea to do a sanity check using "ORCA" to manually perform the validation (just in case).
- Unexplained Intermittent Problems (strange write and delete errors)
These can quite easily be caused by programs such as virus checkers or anti-spyware tools (typically during a scheduled scan). The "X1.EXE" (Yahoo Desktop Search) tool is a great search program but its indexing really sucks, the fact that they fixed the same bug when I reported it in their previous search tool is particularly annoying. I normally terminate "x1" when building. The problem is that they can be opening the file while MAKEMSI or other programs are trying to create, write to, or delete the file. Unfortunately operating systems don't have inbuilt mechanisms to allow programs such as these to do their job.
- Lots Of, Huge or a Complex MSI
If you have large numbers of something or the size of some of your resources is big then you should check out the Install Site's "What are the limits for a large MSI package?
" page.
- Merge Module Related Problems
There are few merge modules which either cause merge errors in pass 1 or cause validation errors or warnings (which may be safe to ignore). If unsure what you should do then I recommend looking in Microsoft's MSI forum
for information on the specific merge module or the errors it generates.
- Publishing Product Information hang (or long delay)
The last thing an MSI generally does is publish product information, I
have seen this hang (or be very slow). Killing the
"YahooDesktopSearch.exe" program allows it to continue.
I'm not sure if other similar programs (virus checkers etc) can also
have this effect.
- Conditional Processing not Working as Expected
Some people (at least initially) get confused between conditional
"build time" and "run time" processing.
At "run time" you use Windows Installer 'conditions'
to alter processing and at build time you may invoke VBSCRIPT, rexx
or use "#if" or similar commands to dynamically build a static msi.