A deployment shows "Failed" in the Intune portal. The app installed perfectly on the endpoint — you can see it sitting right there in Add/Remove Programs. But Intune logged exit code 1603 and marked the assignment red.
That gap between what actually happened and what Intune thinks happened is where hours disappear. This article covers every exit code you will realistically encounter deploying Win32 apps through Intune in 2026, what each one actually means, and the specific steps to fix them.
How Intune Interprets Win32 App Exit Codes
When Intune Management Extension (IME) runs your install command, it captures the process exit code and maps it against the return codes configured in the Win32 app properties. If the code is not in that list, Intune treats it as a failure.
That is the root cause of most false failures. The installer returned a perfectly valid code. Intune just did not know to expect it.
Three outcomes are possible:
- Success — the code matches a configured success return code
- Soft reboot — the code signals a pending restart is required
- Failure — anything else, including codes the installer considers informational
The default success code is 0. The default soft reboot codes are 1641 and 3010. Everything else fails unless you explicitly add it.
The Exit Codes You Will Actually See
0 — Success
Standard success. The installer exited cleanly. If you are seeing 0 but Intune still marks the app failed, the problem is your detection rule — not the exit code. The app installed, but Intune cannot confirm it. Fix the detection rule first.
1641 — Success, Reboot Initiated
The installer triggered a reboot itself. Intune treats this as a successful install with a hard reboot. No action needed unless the reboot is disrupting users — in which case, review your assignment deadline settings.
3010 — Success, Reboot Required
The most common code you will see from MSI-wrapped applications. Install succeeded. A reboot is pending but not forced. Intune marks this as a soft reboot. Add 3010 to your success return codes if it is not already there. Most engineers get burned by this at least once.
1603 — Fatal Error During Installation
This is the one that causes the most confusion. 1603 means the installer hit a fatal error — but the cause is almost never obvious from the code alone.
Common causes:
- Wrong install context. The app requires per-machine installation but you deployed it per-user, or vice versa. Switch the install behavior in the Win32 app properties.
- A conflicting installation exists. The installer found a previous version and refused to proceed. Add an uninstall step as a dependency or use supersedence.
- Missing prerequisite. The app needs a runtime — Visual C++, .NET, etc. — that is not present on the endpoint. Add it as a dependency in Intune.
- UAC prompt blocked. The installer tried to show a dialog during a silent install. Your silent switch is wrong or missing entirely.
Gotcha: 1603 from an EXE wrapper often means the inner MSI returned 1603, not the wrapper itself. Check %temp%\IntuneManagementExtension\Logs for the actual MSI log.
1618 — Another Installation Is Already in Progress
Windows Installer is locked. Another MSI is running concurrently on the endpoint — which happens when Intune pushes multiple Win32 apps at the same time.
Fix: Add a retry in your deployment, or stagger assignments using filters. IME will retry on its own schedule, but if you need deterministic ordering, use dependencies to sequence installs.
1619 — Installation Package Could Not Be Opened
The .intunewin content could not be extracted, or the install command path is wrong. Check two things:
- The install command in Intune matches the exact filename inside the
.intunewinpackage — case-sensitive on some systems. - The package was not corrupted during the Content Prep Tool wrapping process.
1633 — Platform Not Supported
The installer is 32-bit but you are deploying to a 64-bit system in a context that does not handle the redirect correctly, or vice versa. Verify the architecture setting in the Win32 app requirements tab.
2 — File Not Found
The install command references a file that does not exist at that path. Either the file was not included in the .intunewin package or the path in the install command is wrong. Re-wrap the package and confirm the source folder contains every file the installer needs.
1602 — User Cancelled Installation
The installer displayed a UI and something dismissed it. This should not happen during a silent deployment. It means your silent switch is not suppressing the UI. The fix depends on the installer framework:
- NSIS:
/S(capital S) - Inno Setup:
/VERYSILENT /SUPPRESSMSGBOXES - InstallShield:
/s /v"/qn" - MSI:
/qn
Getting the wrong switch for the wrong framework is one of the most common packaging mistakes. An Inno Setup installer will happily ignore /qn and show its full UI. For the full framework-by-framework reference, see the silent install switches guide.
1 — Incorrect Function / General Error
Vague by design. Usually means the installer returned a non-zero generic failure. Pull the IME log from C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log and look for the actual error string above the exit code line.
-2147023293 (0x80070003) and Other Negative Codes
Negative exit codes are Win32 HRESULT values in disguise. Convert the decimal to hex and look up the HRESULT. 0x80070003 is ERROR_PATH_NOT_FOUND. 0x80070005 is ERROR_ACCESS_DENIED. These almost always point to a path or permissions problem in the install script or command.
Reading the IME Logs
The IME logs are the fastest way to diagnose any exit code. The primary log is at:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.logSearch for the app name or the string ExitCode. You will find a line like:
[Win32App] Installer process exited with exit code: 1603The lines immediately above it show the exact command that ran, the working directory, and any pre/post-install script output. That context is where the real diagnosis happens.
For MSI-based installs, also check:
%temp%\<AppName>_<timestamp>.logIf you passed /l*v in your install command, the MSI verbose log will show the exact action that failed before 1603 was returned.
Configuring Return Codes Correctly
In the Intune portal, navigate to the Win32 app properties and open the Return codes tab. The defaults are:
| Code | Type |
|---|---|
0 | Success |
1707 | Success |
3010 | Soft reboot |
1641 | Hard reboot |
1618 | Retry |
Add any additional codes your installer is known to return. If you are wrapping a legacy EXE that returns 0 on success and 2 for "already installed," add 2 as a success code so Intune does not mark re-deployments as failures.
Gotcha: Adding a code as "Success" when it actually indicates a real failure will mask problems in your deployment reporting. Only add codes you have verified against the installer's documentation or observed behavior. The Intune deployment cheat sheet has the copy-paste return code presets by installer framework.
The Silent Switch Problem Upstream of Exit Codes
Most 1602 and 1603 errors trace back to a missing or wrong silent switch. When the installer shows a UI during a system-context deployment, the user cannot interact with it — the process times out or gets killed, and Intune logs a failure.
The challenge is that silent switches are not standardized. Inno Setup, NSIS, and InstallShield each use different flags, and vendor documentation is often wrong or outdated. Hunting the correct switch manually means reading installer headers, checking vendor forums, or running the installer in a sandbox to observe behavior.
That is where the packaging step matters as much as the exit code handling. If you are wrapping EXEs for Intune and want the silent switch identified automatically, InstallMage detects the installer framework — Inno Setup, NSIS, InstallShield — and extracts the correct silent arguments as part of the conversion pipeline. The output includes ready-to-paste install commands with the right switches already embedded, which eliminates the most common source of 1602 and 1603 errors before they happen.
For a deeper look at when to use MSI versus .intunewin and how that choice affects exit code handling, see Intunewin vs MSI Explained.
Detection Rules and False Failures
A 0 exit code with a "Failed" status in Intune is almost always a detection rule problem, not an exit code problem. The install succeeded. Intune ran the detection rule after install and got no match.
Common detection rule mistakes:
- Wrong registry path. The app writes to
HKLM\SOFTWARE\WOW6432Node\...on 64-bit systems but you are checkingHKLM\SOFTWARE\.... Specify the correct hive and path. - Wrong file version. The detection checks for version
2.1.0but the installer deployed2.1.0.1. Use "greater than or equal to" instead of exact match. - Per-user vs per-machine mismatch. The app installs per-user but your detection rule checks a per-machine registry key. That key does not exist in SYSTEM context.
- ProductCode mismatch. If you are using MSI ProductCode detection, confirm the GUID matches the exact version you deployed. ProductCodes change between versions.
Always use file or registry detection over MSI ProductCode detection for EXE-wrapped packages. ProductCode detection is reliable only for native MSI deployments where you control the GUID. The Intune detection rules guide walks through picking the right method per app.
For a complete walkthrough of detection rule configuration alongside other deployment fundamentals, the Intune deployment best practices guide covers the full pre-deployment checklist.
A Practical Triage Sequence
When a Win32 app deployment fails, work through this order before touching anything in the portal:
- Pull the IME log. Find the exit code and the exact command that ran.
- Check the exit code against the return codes tab. Is the code configured? If not, add it — if it represents success.
- If the code is 1603 or 1602, verify the silent switch first. Then check install context (per-machine vs per-user). Then check for prerequisite gaps.
- If the code is 0 but status is Failed, the detection rule is wrong. Fix the detection rule, not the install command.
- If the code is a negative HRESULT, convert to hex and look up the specific error. Path and permissions issues are the most common cause.
- Re-deploy to a single test device before pushing the fix to the full assignment group.
Frequently Asked Questions
What is the most common Intune Win32 exit code that causes false failures?
Exit code 3010 is the most common. It means the install succeeded and a reboot is pending. If it is not listed in your return codes tab as a soft reboot, Intune marks the deployment failed even though the app installed correctly. Add 3010 to your return codes.
Where are the Intune Management Extension logs stored?
The primary IME log is at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. That is the first place to look for the exact exit code and the command that produced it.
Why does Intune show "Failed" when exit code 0 was returned?
A 0 exit code with a failed status means the install succeeded but the detection rule did not match. The app is on the endpoint — Intune just cannot confirm it. Fix the detection rule. Check the registry path, file version logic, and install context.
What causes exit code 1603 in Intune Win32 deployments?
The four most common causes: wrong install context (per-user vs per-machine), a conflicting existing installation, a missing prerequisite runtime, or a silent switch that failed to suppress a UI dialog. Pull the MSI verbose log from %temp% for the specific action that failed.
How do I add custom return codes to a Win32 app in Intune?
Open the Win32 app in the Intune portal, go to the Return codes tab, and add the code with the appropriate type — Success, Soft reboot, Hard reboot, Retry, or Failed. Any code not in this list is treated as a failure by default.
Why does exit code 1602 appear during a silent deployment?
1602 means the user cancelled the installation. During a silent deployment, it means the installer displayed a UI that could not be interacted with in SYSTEM context. The silent switch is either wrong or missing. Verify the installer framework — NSIS, Inno Setup, InstallShield — and use the correct silent flag for that framework.
Can I use the same return codes for EXE and MSI deployments?
Standard MSI return codes (0, 1603, 3010, etc.) apply to MSI-based installs. EXE installers can return any code the developer chose. Check the installer's documentation or test in a sandbox to identify what codes it returns for success, already-installed, and failure states — then configure your return codes tab accordingly.
Exit code failures are almost always fixable once you know where to look. The IME log tells you what happened. The return codes tab controls how Intune interprets it. The detection rule confirms the result. Get those three aligned and most "Failed" deployments resolve quickly.
If the root cause is a bad silent switch on a legacy EXE, that is a packaging problem — not a deployment problem. Fixing it at the source before the package reaches Intune saves the triage entirely.