How to read an MSI verbose log

First, produce one

Windows does not keep MSI logs by default. You have to ask for one.

msiexec /i package.msi /l*v C:\Windows\Temp\install.log /qn

/l*v means everything, verbose. Anything less and the line you need will be the line that was not logged.

To capture every install on a machine without changing each command, set the logging policy. Create Logging as a REG_SZ with the value voicewarmupx under HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer. Every install then writes an MSI*.LOG into %TEMP%. Turn it off afterwards, it is noisy and it never cleans up after itself.

Where deployment tools put them

An install running as SYSTEM writes to C:\Windows\Temp, not to your profile. Intune Win32 app logs are under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. If you are looking in your own %TEMP% and finding nothing, that is why.

The one search everyone knows

Select-String -Path install.log -Pattern "Return value 3" -Context 8,0

Windows Installer writes Action ended ... Return value 3 after an action fails. The -Context 8,0 is the important part: it shows the eight lines before the failure, which is where the actual reason sits. The failure line itself only tells you which action died.

The return value table, properly

Most guides say "0 means the action was skipped". That is wrong, and it is worth knowing because 0 is a real problem rather than a shrug. Here is Microsoft's actual mapping of logged action return values:

0 ERROR_FUNCTION_NOT_CALLED, a function could not be executed
1 ERROR_SUCCESS, the action completed successfully
2 ERROR_INSTALL_USEREXIT, a user cancelled installation
3 ERROR_INSTALL_FAILURE, a fatal error
4 ERROR_INSTALL_SUSPEND, the installation suspended, incomplete
5 ERROR_SUCCESS, the action completed successfully
6 ERROR_INVALID_HANDLE_STATE, the handle is in an invalid state
7 ERROR_INVALID_DATA, the data is invalid
8 ERROR_INSTALL_ALREADY_RUNNING, another installation is in progress

So 1 and 5 are both success. Anything else deserves a look, and 3 is the one that stops the install and triggers rollback.

What to read once you are there

The custom action line

If a custom action failed you will often see a line naming it directly, along with the error the action itself returned. That number is the vendor's error, not a Windows error, and it is the thing to take to the vendor.

The Note lines

Lines like Note: 1: 2262 carry Windows Installer's internal diagnostic codes. They are terse, but they tell you which table or which operation was involved, and they usually appear right beside the failure.

The properties dump

Near the end, the log prints every property and its value: Property(S): INSTALLDIR = .... This answers most of the questions people ask about a failed deployment. Where did it try to install. Did the transform apply. Was the license key property actually set. It is the fastest way to prove that the command line you thought you deployed is the one that ran.

The final status

Installation success or error status: 1603 is the exit code the installer returned. 1603 is the generic fatal error, and 0x80070643 is the same code wrapped as an HRESULT when Windows Update or a deployment tool reports it.

The one that is not a failure

3010 means the install succeeded and a restart is needed. If your deployment tool reports it as a failure, the tool is misconfigured, not the package.

Or let the tool do it

The log analyzer reads MSI logs directly: it finds the action that returned 3, names the product and version, pulls the Note diagnostics, and explains the final exit code. It runs in your browser, so the log stays on your machine, which matters because an MSI log lists your file paths, your machine name, and occasionally property values you would rather not paste into someone else's service.

Open the log analyzer

Return value table checked against Microsoft's Logging of Action Return Values.