Windows installation errors

Every Windows Installer code, in one table

The list is finite and the numbers never change, so here it is in full. The linked ones have a page of their own because they need more than a line; for the rest, the line is the answer.

Codes beginning 0x8007 are different: those are Windows error codes wrapped by the installer, and the last four hexadecimal digits are the real one. Several of them have their own page above.

The step almost nobody takes

Before debugging an installer, confirm the installer is intact. A truncated or modified download produces errors that look like configuration problems and waste hours. Check the file's SHA-256 against our index first: it takes seconds and rules out an entire category of cause.

Common questions

How do I get a verbose log from a Windows installer?

For an MSI, run msiexec /i "package.msi" /L*v "%TEMP%\install.log" from a command prompt and open the file it writes. Many downloads are an .exe wrapping an MSI instead, and those usually accept /log or /l with a path of their own; where a program declares its own switches we list them on its page. The log is the difference between guessing and knowing, and for a code as generic as 1603 it is the only real way forward.

What do I look for in an installer log?

Search it for "Return value 3". Windows Installer records a return value for every action it runs, and 3 is the one that means the action failed, so the lines immediately above it name what was actually being attempted when everything stopped. That is the cause. The error code you saw on screen is only the summary that got reported afterwards.

Why does the same failure show a different code each time?

Because several layers each report it their own way. Windows Installer has its own numbers, the wrapper around it has others, and Windows itself wraps failures again as hexadecimal HRESULTs. That is why the same underlying problem can appear as a four-digit number in one place and an 0x8007 value in another, and why the four hex digits at the end of those are worth converting: they are usually the original code.

Is a failed install always the installer’s fault?

Often it is not. A truncated download, a previous version that did not uninstall cleanly, a locked file held by a running process, or a policy on a managed machine all produce errors that read like the installer is broken. Confirming the file matches its published hash removes the first of those in seconds, which is why it is worth doing before anything else.