This article is for anyone who has ever tried to install a program or critical update/hotfix on Windows and come up against an error which prevented the installation from completing successfully.

Most Windows applications these days are installed by virtue of a technology called MSI - Microsoft Installer. Even those applications that don't display the MSI user interface directly usually use installers which are just front-ends to MSI.

MSI has a few useful features that make it the installer of choice:

• Componentized installs (each portion of an application can be a separate component which can be installed or uninstalled separately)
• Takes care of all dependencies and 'DLL Hell'
• Perfect rollback of failed install attempts (transaction-based installation)
• Scriptable by the developer for custom install actions
• Scriptable by the user for unattended installs
• Completely customisable user interface (MSI can be called programmatically)

MSI is also used to install device drivers, hotfixes, critical updates and Service Packs from Windows Update.

Most MSI installs go without a hitch, but what about when the installation fails? Expect a fairly useless vendor-written error message like "Installation failed!". When an install fails like this, the first step is to check the installation logs, which report everything that happened during the install attempt. These can usually be found in:

C:\Documents and Settings\<User who ran installer>\Local Settings\Temp

There will likely be lots of random files in this folder so right after a failed install, go to this folder, change to Details View and sort the columns by Date Modified in descending order. The '.log' or '.txt' files at the top of the list will likely contain the install logs. The logs have a different name for each product, but their format is generally the same. Some applications don't assign names to the logs and so they are just named 'MSIxxxxx.log'. All of the logs are human-readable files.

Example: The log file for .NET Framework 2.0 is 'dd_netfx20MSIxxxx.txt' where xxxx is 4 hexadecimal digits.

It's important to realise that it is normal for MSI logs to contain numerous warnings and error messages which do not prevent an install from continuing. The trick is to find the ones that matter and learn how to interpret them. There are a few main different log formats which I'll run through below.

All operations during an install are broken down into parts called 'actions'. One type of MSI log has lines which say 'Action start' and 'Action ended' in them to allow you to isolate what happens during a particular action, for example:

Action 4:19:35: FileCost. Computing space requirements
Action start 4:19:35: FileCost.
MSI (c) (B4:48) [04:19:35:963]: Note: 1: 2262 2: Extension 3: -2147287038 
MSI (c) (B4:48) [04:19:35:963]: Note: 1: 2262 2: IniFile 3: -2147287038 
MSI (c) (B4:48) [04:19:35:963]: Note: 1: 2262 2: MoveFile 3: -2147287038 
MSI (c) (B4:48) [04:19:35:963]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 
MSI (c) (B4:48) [04:19:35:963]: Note: 1: 2262 2: ReserveCost 3: -2147287038 
Action ended 4:19:35: FileCost. Return value 1.

This action computes the amount of disk space required for an installation prior to starting. Note that actions can be nested.

The lines starting with 'Action ended' show a return value which gives the outcome of the action. A return value of 1 means the action completed successfully. Certain other values indicate errors. If an action ends in an error, then depending on whether or not the error will prevent the application from running, MSI may choose to rollback (reverse) the installation. If this happens, all the rollback actions will appear in the log too, after the install actions.

Another log type contains lines which begin with the number of seconds since execution started; this is useful if you know roughly how far into an installation something went wrong, or to see how long certain steps took. Here's an example log snippet - arbitrarily chosen - for critical update KB905414 (MS05-045: Vulnerability in Network Connection Manager could allow denial of service):

2.403: AnalyzeComponents: Hotpatch analysis disabled; skipping.
2.403: AnalyzeComponents: Hotpatching is disabled.
2.413: FindFirstFile c:\windows\$hf_mig$\*.*
2.593: AnalyzeForBranching used 30 ticks.
2.593: AnalyzePhaseTwo used 0 ticks
2.593: AnalyzePhaseThree used 0 ticks
2.593: AnalyzePhaseFive used 0 ticks
2.593: AnalyzePhaseSix used 0 ticks
2.593: AnalyzeComponents used 200 ticks
2.593: Downloading 0 files
2.593: bPatchMode = FALSE
2.593: Inventory complete: ReturnStatus=0, 240 ticks
2.593: Num Ticks for invent : 240
2.603: VerifySize: Unable to verify size: Source = NULL: c:\windows\inf\HFX667.tmp 
2.603: Copied file:  c:\windows\inf\branches.inf
2.784: Allocation size of drive C: is 4096 bytes, free space = 29482070016 bytes
2.794: AnalyzeDiskUsage:  Skipping EstimateDiskUsageForUninstall.
2.794: Drive C: free 28116MB req: 11MB w/uninstall: NOT CALCULATED.
2.794: CabinetBuild complete
2.794: Num Ticks for Cabinet build : 201
2.794: DynamicStrings section not defined or empty.
2.794: FileInUse:: need to restart already, turn off
3.795: LoadFileQueues: UpdSpGetSourceFileLocation for halacpi.dll failed: 0xe0000102
3.985: Num Ticks for Backup : 1191
4.155: Num Ticks for creating uninst inf : 170
4.155: Registering Uninstall Program for -> KB905414, KB905414 , 0x0
4.155: LoadFileQueues: UpdSpGetSourceFileLocation for halacpi.dll failed: 0xe0000102
4.316: Copied file:  C:\WINDOWS\system32\spmsg.dll

This log section tells us that the patcher is getting a list of the files it needs, calculating the disk space needed, that a backup of the original files was created, that an uninstaller for the patch was added to the system and so on. One 'tick' is 1ms (1/1000th of a second). The log section covers a span of just under 2 seconds (from 2.403 - 4.316).

A third log type (usually called setupapi.log) begins each line with a hash symbol (#) followed by a letter and a 3-digit number. The letter can be one of:

• - - Action that is being performed or about to be performed
• I - Informational message
• W - Warning that does not stop the install from continuing
• E - Error that may prevent the install from completing and trigger a rollback

The 3-digit numbers are codes indicating more exactly the nature of the information or error.

Here's an example snippet from setupapi.log for a Windows Server 2003 Service Pack 1 installation:

#-198 Command line processed: "C:\WINDOWS\SoftwareDistribution\Download\
ebce56c3ef1f7dbf03c2b569b3f49f6e\i386\update\update.exe" 
#W313 Copy target "C:\WINDOWS\system32\DRIVERS\gmreadme.txt" is also a Delete target,
forcing COPYFLG_NODECOMP.
#W313 Copy target "C:\WINDOWS\system32\DRIVERS\gm.dls" is also a Delete target,
forcing COPYFLG_NODECOMP.
#I443 No installed Authenticode(tm) catalogs matching catalog name "oem13.CAT" were
found that validated file "c:\windows\softwaredistribution\download\
ebce56c3ef1f7dbf03c2b569b3f49f6e\i386\update\update.inf" (key "update.inf").
Error 1168: Element not found.
#I443 No installed Authenticode(tm) catalogs matching catalog name "oem17.CAT" were
found that validated file "c:\windows\softwaredistribution\download\
ebce56c3ef1f7dbf03c2b569b3f49f6e\i386\update\update.inf" (key "update.inf").
Error 1168: Element not found.
#I443 No installed Authenticode(tm) catalogs matching catalog name "oem21.CAT" were
found that validated file "c:\windows\softwaredistribution\download\
ebce56c3ef1f7dbf03c2b569b3f49f6e\i386\update\update.inf" (key "update.inf").
Error 1168: Element not found.
#E099 Writing of "C:\WINDOWS\INF\wmplayer.adm" to "C:\WINDOWS\INF" can cause problems.

This short snippet shows the difference between Informational, Warning and Error messages.

An important thing to note about all the log types is that if you try to install or uninstall the same product more than once, the log is not replaced but the latest installation attempt is added to the end, therefore if you tried to install something several times, the log will contain a record of each installation attempt. It is, of course, important to find the right part of the log to make sure you are examining the most recent attempt!

It's fairly easy to spot when the log for one install ends and the next starts, here are a couple of examples:

18285.672: User Input: OK
18285.672: Update.exe extended error code = 0xf070
18285.672: Update.exe return code was masked to 0x643 for MSI custom action compliance.
3.297: ================================================================================
3.328: 2007/02/02 19:30:45.828 (local)
3.328: C:\WINDOWS\SoftwareDistribution\Download\ebce56c3ef1f7dbf03c2b569b3f49f6e
\i386\update\update.exe (version 5.6.1013.0)

Here an installation failed, the user clicked OK and the installer quit. When the installer starts again it writes the current date and time to the file - in this case 19:30 on 2nd February 2007 and shows the command that it is running.

For setupapi.log logs, you can look for the phrase #-198 Command line processed: preceded by the current date in square brackets, for example:

[2007/02/02 19:30:45 3940.5]
#-198 Command line processed: "C:\WINDOWS\SoftwareDistribution\Download\
ebce56c3ef1f7dbf03c2b569b3f49f6e\i386\update\update.exe"

Windows Update

If you use Windows Update often (and you should), you're probably familiar with the window which tells you how many updates there are and which one is currently being installed. Windows Update is particularly unhelpful when it comes to failed updates as it merely tells you "The following updates could not be installed:".

Fortunately, there are two things you can do. First, check C:\WINDOWS for new log files (sort in descending Date Modified order as described above). Windows Update log files have names like KBxxxxxx.log, Qxxxxxx.log or svcpack.log depending on what is being installed (the first two are for security and general updates, the latter for Service Packs). Once you've opened the log, look at the first few lines. Here's an example for KB920213 (MS06-068: Vulnerability in Microsoft Agent could allow remote code execution) for Windows XP SP2:

[KB920213.log]
3.328: ================================================================================
3.328: 2006/11/16 18:09:53.375 (local)
3.328: C:\WINDOWS\SoftwareDistribution\Download\
b15b843ee2a6cbca76875f1244f36866\update\update.exe (version 6.2.29.0)
3.328: Failed To Enable SE_SHUTDOWN_PRIVILEGE
3.343: Hotfix started with following command line: -q /Z -ER
/ParentInfo:ce0f261b1aa2bc42aa3e362221c8c0dd

Notice the line right underneath the date - this shows you where the update was downloaded. Windows Updates are generally stored in C:\WINDOWS\SoftwareDistribution\Download followed by an arbitrarily chosen hexadecimal folder name. Within that, the installer for the update can usually be found at update\update.exe. Normally the MSI user interface for the update isn't shown - the Windows Update interface is shown instead - but if you double-click on the installer (update.exe) for the failed update you want to retry, the full interface will be shown.

Knowing how to find files downloaded by Windows Update on your system saves you from downloading them again - and knowing where the logs are helps you to identify problems when they go wrong. If you run the update installer manually for the failed patch, you may get a more helpful error message than the standard one given by Windows Update, and you can retry as many times as you need to until the installation succeeds.

Solving the problem

Now that you can find and browse your installer logs, how do we resolve any problems that are found? This is a very general question, and since the problem could be almost anything, the solutions vary wildly. The basic principles of fixing a failed installation are:

• Find the installer logs
• Find the error in the log
• Find out how to resolve the error

For the last step, the internet is your best friend. Here are some places to search in particular:

• Google Groups - the Usenet repository packed with technical problems and solutions. Search for the error message you see in the log; put quotes around it so that Google searches for an exact match. You will likely find a solution here.
• Microsoft's web site - search the knowledgebase for your exact error message, again in quotes. There are many problem solving articles here also.

I have also solved a few installation issues and you can refer to my articles below to find out if your particular problem is one of them:

• Tutorial: How To Fix WMI Corruption

If you've solved an installation issue, feel free to post a comment about it below!