Skip to content
September 2, 2026 • Mid-Level (3-5 years) How-To

Intune Win32 App Returns Exit Code 0 but Still Fails: Fix Detection First

An Intune Win32 app can return exit code 0 and still report Failed when detection cannot prove installation. Use logs, context, and exact evidence to fix it.

Methodology

Practical guidance for working engineers, with a bias toward steps you can verify and repeat.

• What it covers: the exact problem, workflow, or decision
• What to verify: logs, settings, outcomes, or pass/fail checks
• What to avoid: risky changes without rollback or validation
• What to expect: prerequisites, caveats, and role fit

Intune Win32 App Returns Exit Code 0 but Still Fails: Fix Detection First

An Intune Win32 app can finish its install command with exit code 0 and still appear as Failed. That is not contradictory. The return code describes the install command; the detection rule is a separate test that decides whether Intune can prove the app is present.

This runbook is for the specific symptom: the installer appears to complete, but the Intune device status remains failed or not detected.

Quick fix checklist

  1. In Intune admin center > Apps > All apps > select the Win32 app > Monitor > Device install status, record the device result and app assignment.
  2. Confirm the configured Install behavior is System or User. Microsoft defines System as all users on the device and User as one particular user.
  3. On the device, collect IntuneManagementExtension.log, AppWorkload.log, and AppActionProcessor.log from C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
  4. Prove the installer’s actual output path, registry hive, MSI product code, or script result. Do not use the Start menu entry as proof.
  5. Compare that evidence with the exact Intune detection rule, including 32-bit registry view and version/operator settings.
  6. Correct the detection rule first. Repackage only if the logs show the install command itself failed.
  7. Sync the device and verify that the next evaluation reports the app as detected before expanding the assignment.

Why exit code 0 is not enough

Win32 app processing has at least two decisions: run the install command, then evaluate applicability and detection. A successful process exit does not guarantee that the expected file, registry value, folder, or MSI identity exists where the rule looks.

Typical false diagnoses include:

  • The installer writes to %LOCALAPPDATA%, but the app is configured for System context and the rule checks a machine path.
  • A 32-bit installer writes to the 32-bit registry view while detection searches the 64-bit view.
  • The installer updates an existing product, but the MSI product code or version condition in Intune is stale.
  • A PowerShell detection script works in an interactive administrator session but depends on HKCU, a mapped drive, or an environment variable unavailable to the Intune Management Extension.
  • A vendor bootstrapper returns success before a child installer has created the final artifact.

The first question is therefore not “what new package should I upload?” It is “what exact evidence does Intune evaluate, and does it exist under the configured context?”

Read the client evidence

Microsoft’s Win32 troubleshooting guidance identifies AppWorkload.log as the main app workload log, including check-ins, installs, applicability, and detection. AppActionProcessor.log records app action processing, while IntuneManagementExtension.log helps establish policy and service activity.

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = 'Contoso','Detection','Detected','NotDetected','exit code','AppWorkload'

Get-ChildItem $LogRoot -Filter '*.log' |
  Select-String -Pattern $Terms -SimpleMatch |
  Select-Object Path, LineNumber, Line

Replace Contoso with a distinctive part of the app name. Build a timeline from the log lines:

policy received -> content downloaded -> install command launched -> process result -> detection evaluated -> reported state

If the process result is successful but the following detection evaluation is negative, stay in the detection branch. If content staging or the install command fails first, investigate packaging, command-line switches, permissions, or installer logs instead.

Prove the detection artifact

For a file rule, test the exact configured path:

$Path = 'C:\Program Files\Contoso\Client\Contoso.exe'
Get-Item $Path -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime, VersionInfo

For a machine registry rule, check the hive and value explicitly:

Get-ItemProperty 'HKLM:\SOFTWARE\Contoso\Client' -ErrorAction SilentlyContinue |
  Select-Object InstalledVersion

For a 32-bit app on 64-bit Windows, query the 32-bit view when that is how the installer writes:

Get-ItemProperty 'HKLM:\SOFTWARE\WOW6432Node\Contoso\Client' -ErrorAction SilentlyContinue

For a per-user rule, test the intended user profile and HKCU, not an administrator account chosen only for troubleshooting. Detection evidence must match the app’s install context and assignment design.

PowerShell detection scripts

A custom detection script is only useful when its success contract is unambiguous. Keep it local, deterministic, and independent of interactive state. Test the same path and identity that the Intune Management Extension will use. Avoid mapped drives and prompts.

$exe = 'C:\Program Files\Contoso\Client\Contoso.exe'
if (Test-Path $exe) {
    Write-Output 'Detected'
    exit 0
}
exit 1

Do not treat printed text alone as proof. Compare the script’s configured output expectations and exit behavior with Microsoft’s current Win32 detection-rule guidance, then validate the result in AppWorkload.log or AppActionProcessor.log.

Use the free analyzer without exposing secrets

The free Intune App Failure Analyzer is a browser-based, client-side troubleshooting aid for this review. It accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs. Paste sanitized excerpts only: remove tenant IDs, usernames, device names, URLs containing tokens, and internal paths that reveal sensitive data. Use its output as a checklist, then confirm the proposed cause against the device evidence and Microsoft documentation.

Prevention checklist

  • Pair every install command with a detection test built from the installer’s documented output.
  • Document whether the package is machine-wide or per-user before choosing System or User context.
  • Record 32-bit versus 64-bit registry view in the app’s packaging notes.
  • Test detection after upgrades, not only first install.
  • Keep installer logs and IME logs from a pilot device for every packaging change.
  • Use a small pilot assignment after changing detection; do not immediately redeploy to every device.
  • Treat exit code 0 as install-process evidence, not as proof that Intune should report Installed.

Microsoft sources

#Microsoft Intune #Win32 apps #exit code 0 #detection rules #AppWorkload.log #Intune Management Extension
Was this helpful?

Comments

Comments are coming soon. Have feedback? Reach out via the About page.