Intune Win32 App Returns 3010: Why a Successful Install Can Still Look Failed

A Win32 app installer can finish its work and return 3010, while the Intune deployment still looks incomplete or failed. That number is not automatically proof that the package broke. Windows Installer defines 3010 as ERROR_SUCCESS_REBOOT_REQUIRED: the installation succeeded, but a restart is required to complete it.

The important distinction is how Intune maps that return code. If 3010 is left as an ordinary failure, the portal status can mislead you. If it is mapped as a soft reboot, Intune can record the install as successful while allowing the next app installation to continue without immediately restarting the device.

This guide shows what to verify before repackaging an otherwise healthy application.

Quick Fix checklist

1. Capture the exact installer exit code from AppWorkload.log or the installer log.
2. Confirm that the code is 3010, not a different MSI or wrapper error.
3. In the Win32 app Program settings, open Return codes.
4. Add or edit 3010 and map it to Soft reboot.
5. Keep the detection rule focused on the artifact the installer actually creates.
6. Confirm whether the app requires a restart before its service, driver, or shell integration becomes usable.
7. Sync one test device and verify both the Intune state and local detection result.
8. Schedule or communicate the required restart rather than silently treating it as an installation failure.

For a structured second pass, use the free Intune App Failure Analyzer. It is a browser-based, client-side beta. It accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs. It organizes the evidence in the browser; verify the recommendation against the device and Microsoft documentation.

What Intune error 3010 means

Microsoft documents Windows Installer error 3010 as a successful installation that requires a restart. It is different from a generic non-zero failure. The installer has signaled that the current process completed, but Windows cannot finish all changes until the computer restarts.

That can happen when an application installs a service, updates a file that is in use, adds a driver, changes a shell component, or writes configuration that is consumed during startup. The specific reason depends on the installer. Do not infer the reason from 3010 alone.

The correct question is not “Did the installer return zero?” It is:

• Did the installer complete successfully?
• Is 3010 configured as a soft reboot in Intune?
• Does the detection rule now find the installed application?
• Does the app become fully usable after the required restart?

Why the obvious diagnosis can be wrong

A portal entry that says Failed often sends admins toward the content package, install command, or detection rule. Those are valid suspects, but a return-code mapping problem can come first.

Common misdiagnoses include:

• treating every non-zero exit code as an installer failure;
• adding a second install command when the first one already completed;
• changing detection because the app is not ready until reboot;
• forcing an immediate restart for every device when a soft reboot is the intended behavior;
• assuming that a successful 3010 result proves the application is usable before restart.

The reverse problem is also possible: an installer wrapper may return 3010 even though its own prerequisite step failed. The code is evidence, not a substitute for reading the installer and IME logs.

Configure the return code in Intune

Open the Win32 app in the Intune admin center and go to Properties > Program. In the return-code section, make sure 3010 is present and classified as Soft reboot. Microsoft’s Win32 app configuration supports return-code categories that control whether Intune treats a result as success, failure, retry, or a reboot condition.

A soft reboot is not the same as pretending no restart is needed. It tells Intune that the installation result is successful while deferring the restart decision according to the app and device restart policies.

Do not change the installer’s exit code just to make the portal green. Preserve the signal and configure the platform to interpret it correctly.

Verify the local evidence

Start with the IME logs on the affected Windows device:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Search AppWorkload.log for the app name, app ID, and the 3010 result. Then correlate the timestamp with the installer’s own log. You want to distinguish these cases:

Evidence	Meaning
Installer log ends successfully and reports 3010	Installation completed and requested a restart
IME records 3010 as a configured soft reboot	Intune can treat the deployment as successful with restart pending
Detection rule is not found before restart	The app may not expose its final artifact yet
Detection remains missing after restart	Investigate the rule, path, registry view, context, or installer behavior
A wrapper reports 3010 but its child process failed	Fix the wrapper or prerequisite handling first

Check the exact detection artifact rather than relying on a shortcut or the presence of an installer cache. For example, if the rule checks a file version, verify that file and version directly:

$Path = 'C:\Program Files\Contoso\Client\Contoso.exe'

if (Test-Path $Path) {
    Get-Item $Path | Select-Object FullName, LastWriteTime, VersionInfo
} else {
    'Detection file is missing'
}

If the rule checks the registry, confirm the correct hive and registry view. The related guide HKLM vs. HKCU Detection Rules in Intune Win32 Apps covers the false-failure pattern where the application is present but the rule checks the wrong location.

The verified fix

The smallest reliable fix is to align three things:

1. Installer result: confirm that 3010 means successful completion for this package.
2. Intune mapping: classify 3010 as Soft reboot, not Failure.
3. Detection evidence: verify the configured file, MSI product code, registry value, or script result after installation and, when required, after restart.

After saving the app, sync a single test device. Review the new AppWorkload.log entries instead of relying on an old portal result. If the deployment reports success with a pending restart, complete the restart during an approved maintenance window and test the application.

If the app still reports failed after the mapping change, move to the next boundary: requirements and applicability, install context, command-line quoting, detection, or the installer’s own log. How to Read Intune Management Extension and AppWorkload Logs provides the log sequence for that investigation.

Prevention checklist

• Document every non-zero return code emitted by the installer or wrapper.
• Map 3010 deliberately as Soft reboot when the package uses it for successful installation.
• Test the package on a clean device and after the required restart.
• Keep detection independent from temporary installer files and user-specific paths.
• Record whether the app runs as System or User and test under that context.
• Make restart expectations visible to the deployment owner and support team.
• Recheck the app’s installation details after a fresh sync before repackaging.
• Keep the original installer log with the IME evidence for escalation.

Microsoft sources

• Add, assign, and monitor a Win32 app in Microsoft Intune
• Windows Installer error codes
• Troubleshoot Win32 app issues