Log Dejargonizer

Windows Application Log · Event 1033

Event 1033: Windows Installer installed a product

An MSI-based installer finished, and Windows recorded the product name, version, publisher, and result. It is the closest thing Windows has to a built-in software installation history — and the number at the end is an MSI error code, so a 1033 can perfectly well be a record of a failure.

Also written as MsiInstaller 1033Event ID 1033 msiinstaller

What it means for you

On a personal computer

Something was installed or updated using a Windows Installer package. This is a receipt, not an error. Reading through these in Event Viewer is a genuinely useful way to see what has been installed on your PC and in what order — including things you did not install yourself.

For an analyst

Cheap software inventory with timestamps and a user context, available on every Windows machine without any agent or audit policy. It only covers MSI-based installs, so anything using a custom installer, an EXE bootstrapper, an MSIX package, or a portable binary is invisible here — which is exactly why it is a starting point rather than an answer.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Log Name:      Application
Source:        MsiInstaller
Event ID:      1033
Level:         Information
User:          DESKTOP-WKS042\alaing
Computer:      DESKTOP-WKS042

Windows Installer installed the product. Product Name: Contoso Report Viewer. Product Version: 4.2.1. Product Language: 1033. Manufacturer: Contoso Ltd. Installation success or error status: 0.

The fields that decide it

Everything else in the log line is context.

Product Name
The display name from the MSI package. Attacker-supplied packages set this to whatever they like, so treat it as a claim rather than a fact.
Product Version
Useful for the vulnerability question that usually follows: which version was actually installed, and when.
Manufacturer
The publisher string from the package. Again self-declared, and not the same thing as a verified code signature.
Installation success or error status
The MSI result code. This is the field people skip.
  • 0Success.
  • 1603Fatal error during installation. The generic MSI failure and the most common non-zero value.
  • 1618Another installation is already in progress.
  • 1605The product is not installed, so the requested action does not apply.
  • 3010Success, but a reboot is required to complete it.
User
The account that ran the installer. On a per-machine install this is often SYSTEM because the Windows Installer service does the work, which limits how much the field tells you about who initiated it.

Ordinary reasons this happens

Most of the time it is one of these.

  • Ordinary software installation, patching, or an update that ships as an MSI.
  • Software deployment by Group Policy, Configuration Manager, or Intune, which produces these in bulk on a schedule.
  • A repair operation — Windows Installer self-repair triggered by a missing file logs an install result too.
  • An uninstall, which is recorded by the sibling events rather than by 1033 but often appears in the same sequence.
  • Microsoft Office and Visual C++ runtime updates, which account for a large share of these on a typical machine.

When it is not ordinary

An MSI package used to install a remote-access tool or an agent under a plausible-looking product name.

What gives it awayA product name and manufacturer that do not correspond to anything the organisation deploys, installed outside a maintenance window, with no matching deployment record.

ATT&CK T1105

A legitimate remote monitoring and management product installed by an intruder for persistence.

What gives it awayA genuine, correctly signed product — ScreenConnect, AnyDesk, remote support agents — appearing on a machine where it was never deployed. The install is real; the authorisation is what is missing.

ATT&CK T1219

MSI used to execute code through its custom actions rather than to install anything.

What gives it awayA 1033 with a product name that means nothing, immediately followed by process creation from msiexec.exe spawning a shell or a script interpreter.

ATT&CK T1218.007

What to do next

  1. Read the status code at the end before anything else. A non-zero value means the install failed, and 1033 records failures as readily as successes.
  2. Compare the product name and manufacturer against what you actually deploy. An unfamiliar name is worth a minute even when it looks innocuous.
  3. Note the time and check what else happened around it — process creation from msiexec.exe, a new service (Event 7045), or a new scheduled task (Event 4698) in the following minutes.
  4. Cross-check against the installed products list: `Get-CimInstance Win32_Product` is the obvious command and is also slow and triggers repairs — prefer reading the uninstall registry keys instead.
  5. For a failing install, the event only gives you the code. Re-run with logging — `msiexec /i package.msi /l*v install.log` — because the verbose log names the action that failed and the event never will.
  6. If a remote access product appears, verify it against your own deployment records rather than against whether the vendor is reputable. Legitimate software installed by someone who should not have is the common case.

Queries to run

powershell 1033 is the modern event; 11707 (install succeeded) and 11724 (removal succeeded) are the older pair and still appear alongside it. 
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; Id=1033,11707,11724} -MaxEvents 200 | Select-Object TimeCreated, Id, Message | Format-List
powershell Only the installs that failed. The success cases are the bulk and are rarely what you are looking for. 
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MsiInstaller'; Id=1033} | Where-Object { $_.Message -notmatch 'error status: 0' } | Select-Object TimeCreated, Message
powershell The installed-software list, read the fast way. Win32_Product is the well-known alternative and it re-validates every package as it enumerates, which can trigger repairs. 
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Sort-Object InstallDate -Descending
kql Sorted ascending, this puts software installed on only one or two machines at the top — which is usually where the interesting installs are. 
Event | where Source == 'MsiInstaller' and EventID == 1033 | extend Product = extract(@'Product Name: ([^\.]+)', 1, RenderedDescription) | summarize Hosts = dcount(Computer), Installs = count() by Product | order by Hosts asc

Common questions

Does Event 1033 mean the installation succeeded?

Not necessarily. The event is written whether the install worked or not, and the outcome is the number at the end of the message: 'Installation success or error status: 0' means success. 1603 is the generic fatal MSI error, 1618 means another install was already running, and 3010 means it worked but needs a reboot. Read the number, not the event ID.

Can I use Event 1033 to see what was installed on a PC and when?

Yes, with one important limitation. It covers software installed through Windows Installer packages only, so anything using a custom EXE installer, an MSIX or Store package, a portable executable, or a per-user installer that does not use MSI will not appear. It is a good first pass, not a complete inventory — cross-check against the uninstall registry keys.

What does 'Installation success or error status: 1603' mean?

1603 is Windows Installer's generic fatal error and it means very little on its own — it is the code MSI returns when almost anything goes wrong mid-install. To find the actual cause you need a verbose log: re-run the installer with `msiexec /i package.msi /l*v install.log` and search the log for 'Return value 3', which marks the action that failed.

Why does Event 1033 sometimes show SYSTEM as the user?

Because per-machine MSI installs are carried out by the Windows Installer service, which runs as SYSTEM, even when a person started them. The event records the account that performed the work rather than the one that initiated it. To find out who actually launched the installer, look at process creation events for msiexec.exe at the same time.

Read next

Vendor documentation

Last reviewed 7 September 2026