Troubleshoot Win32 app deployment failures

Why did the Win32 app fail? Map the status to a stage

Win32 deployment runs as a sequence on the client, and a failure in one stage stops the rest. Before touching the .intunewin package, identify the stage:

• Targeting — is the device (or its primary user) actually in the assigned group, and not in an exclusion group? Remember that an Available assignment needs a signed-in user and is not supported for device-only targeting.
• Eligibility — do the requirement rules pass? Requirements are evaluated before detection and before the install command ever runs.
• Download — can the device pull the encrypted content (up to 8 GB per package) from the content CDN?
• Execution — does the install command run silently and exit with a return code Intune treats as success?
• State — does the detection rule report the app as installed, and is the restart behavior handled?

Use the per-app, per-device status in Apps > Monitor > App install status to see how far the device got. “Failed” after a download means the command stage; “Installed” in Intune but still reported as failed almost always means the detection rule.

What does each error state actually mean?

The symptom you see in the console narrows the search. Use this table to jump straight to the responsible stage instead of scrolling logs at random.

How do requirement and detection rules cause silent failures?

These two rule types are evaluated at opposite ends of the pipeline, and both can make a perfectly good package “fail” with no installer error at all.

Requirement rules run first. They include OS architecture (x86, x64, ARM64), minimum operating system, and optional checks for disk space, physical memory, logical processors, CPU speed, and custom file, registry, or script requirements. If a device does not meet a requirement, the app is reported as Not applicable — not failed — which is why an app can simply never install on part of your fleet. Loosen or correct the rule and re-evaluate. See Intune requirements for the full list.

Detection rules run after the command and decide whether Intune believes the app is present. Detection types are MSI (matched by product code), File, Registry, and Custom script (PowerShell). The single most common detection gotcha: a custom detection script only reports “detected” when it exits with code 0and writes at least one line to STDOUT. Exit 0 with no output, or output with a non-zero exit, both read as “not detected” — so Intune marks the install failed or reinstalls the app on every cycle even though it is clearly there.

How do I validate the silent install and uninstall commands?

Intune runs your install command as the local SYSTEM account by default (System context), or as the signed-in user (User context) if you chose that. A command that works in your interactive admin prompt can still fail under SYSTEM because of mapped drives, per-user paths, or a prompt that never appears to answer. Validate the exact command outside Intune before re-uploading anything — see install and uninstall commands for the patterns.

Run the install in an elevated SYSTEM prompt (for example with PsExec) using the same switches Intune will use, then capture the exit code immediately:

msiexec /i App.msi /qn /norestart & echo Exit: %ERRORLEVEL%

• Confirm the install is genuinely silent — no UI, no prompts. A hidden dialog under SYSTEM hangs the install until it times out.
• Capture the exit code and compare it to the mapping below. An EXE that returns a non-zero “success” code (some installers use 0 for success but return 1 in valid scenarios) must be mapped explicitly.
• Test the uninstall command the same way — a broken uninstall breaks supersedence and the Uninstall assignment intent.

Which return codes count as success?

Intune maps installer exit codes to outcomes. Anything not in the default map (and not mapped by you on the Program tab) is treated as Failed. Get these right before suspecting the package — many “failures” are just an unmapped reboot code.

If your installer legitimately returns a different code, add it as a custom return code so Intune stops reporting success as failure. For how these tie into restart behavior, see return codes and install behavior.

How do I read the Intune Management Extension logs?

The IME is the agent that does all Win32 and PowerShell-script work on the device. It is installed automatically the first time a device is targeted with a Win32 app or a script, and it polls for new Win32/script policy roughly every hour, plus after a device restart or service restart. Do not confuse that ~1 hour cycle with the general Windows MDM check-in, which runs on a variable schedule (commonly around every 8 hours, more often right after enrollment). If a device just got the assignment, it may simply not have checked in yet.

The device-side reason for almost every Win32 failure is in the IME logs at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Open them with CMTrace for live highlighting and time filtering:

• IntuneManagementExtension.log — service start-up, policy retrieval, and check-in activity.
• AppWorkload.log — the core Win32 app log: download, install command, return code, and detection result.
• AgentExecutor.log — how scripts (including detection and requirement scripts) were launched and what they returned.
• ClientHealth.log — agent health, useful when the IME itself is the problem.

To force a check-in and re-run the workload after a fix, trigger a sync from Settings > Accounts > Access work or school > Info > Sync (or the Company Portal), then watch AppWorkload.log. When the agent is stuck, restarting the service re-reads policy:

Restart-Service -Name IntuneManagementExtension -Force

For a deeper walkthrough of each file and what the entries mean, see the Intune Management Extension logs guide.

What are the most common avoidable mistakes?

• Wrong install context. A per-user installer set to System context (or vice versa) installs to the wrong profile and then fails detection. Match the context to how the installer writes.
• Non-silent switches. A switch that suppresses most UI but still shows one dialog will hang under SYSTEM. Always verify a truly unattended run.
• Detection rule that does not match the command. Detecting an MSI product code while the EXE installs a different build, or pointing a File rule at a path that only exists in User context.
• Unmapped reboot/retry codes. Treating 3010 or 1618 as failure when they are normal.
• Re-uploading the package to “fix” a targeting or requirement problem. Confirm the stage first — most fixes are settings, not files.