The Intune Win32 App Installed but Says Failed: How to Prove What Actually Broke

A common Intune incident looks contradictory: the application launches on the Windows device, but the Intune admin center reports Failed. The first reaction is usually to rebuild the .intunewin package or rerun the installer.

That is often the wrong first move. A Win32 deployment has more than one state to prove. The install command can return success while detection fails. The app can be installed for one user while a device-targeted rule runs as SYSTEM. A 32-bit installer can write to a different registry view than the one your rule checks. The client can also be reporting an older policy revision.

This runbook separates those cases using evidence from the device instead of the status label alone.

Quick triage checklist

1. Confirm whether the failure is install, applicability, or detection in the device installation details.
2. Check whether the expected executable, MSI registration, or registry value exists on the device.
3. Identify whether the app is assigned to a user or device and whether the install behavior is System or User.
4. Review the Intune Management Extension logs in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
5. Compare the detection rule with the actual installed path, product code, version, and registry view.
6. If the rule is correct, sync the device and confirm that the updated app policy reached the client.
7. Reassign or repackage only after the logs show that the installer itself failed.

For a second opinion on the evidence, use the free Intune App Failure Analyzer. It is a browser-based, client-side beta: you can enter an error code, install command, detection rule, install context, registry view, or IME/AppWorkload log without uploading the log to the site.

Why “installed” and “failed” can both be true

Intune does not decide that an app is installed simply because a process ran. Microsoft’s Win32 app model includes an install command and detection rules. Detection can use an MSI product code, a file or folder, a registry value, or a PowerShell script.

The practical sequence is:

Receive app policy
  -> check applicability and requirements
  -> download and run install command
  -> evaluate detection rule
  -> report the resulting state

If the command returns success but the detection rule returns not detected, the application may be usable while Intune still reports failure. Conversely, a shortcut or executable may exist even though the installer returned an error or stopped before completing required configuration.

Do not use the visible shortcut as proof of a successful Intune deployment. Use the same artifact configured in the detection rule.

Step 1: classify the failure in Intune

Open the app and affected device in the Intune admin center. Start with Apps > Windows > select the Win32 app > Monitor > Device install status, then inspect the installation details.

Record:

• the app name and app ID;
• the assignment target and install intent;
• the reported error code or status text;
• the policy or app revision shown by the client;
• whether the failure occurs before installation, after installation, or during detection.

The label Failed is not enough to choose a fix. If the details show that the app was not detected after the command completed, investigate detection. If there is a download, extraction, command-line, or return-code error before detection, investigate the installer and content path first.

Step 2: verify the installed evidence locally

Use a test device and replace the example values with the artifacts from your package.

For a file rule:

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

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

For an MSI or uninstall registration, check both common machine-wide locations:

$Roots = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

Get-ItemProperty $Roots -ErrorAction SilentlyContinue |
  Where-Object DisplayName -like '*Contoso*' |
  Select-Object DisplayName, DisplayVersion, PSChildName, InstallLocation

PSChildName commonly exposes the MSI product-code key. Compare it with the product code configured in Intune; an upgrade code or an old product code is not equivalent.

For a registry rule, query the exact hive, key, value, and view. A 32-bit app on 64-bit Windows may write under WOW6432Node, while the rule is checking the native 64-bit location.

Step 3: check install context before changing detection

The install context changes what the installer and detection script can see.

• System/device context: use machine-wide paths and HKLM. Do not depend on a signed-in user, mapped drive, profile folder, or that user’s HKCU.
• User context: user-profile paths and HKCU may be appropriate, but the app must be assigned and configured for the intended user scenario.

A frequent false diagnosis is “the detection rule is broken” when the app was installed per-user but the deployment is evaluated in system context. The reverse also happens: a device-targeted app expects a machine-wide installation, but the installer writes only to the current user profile.

Test a detection script in the same context used by the deployment. Microsoft documents the Intune Management Extension log location and identifies AppActionProcessor.log as the place to review detection and applicability checks.

Step 4: read the client logs in the right order

The standard log directory is:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Focus on:

Log	Evidence to look for
IntuneManagementExtension.log	check-in, policy request, policy processing, and reporting
AppWorkload.log	app check-in, install, applicability, detection, and reporting
AppActionProcessor.log	detection and applicability evaluation
AgentExecutor.log	PowerShell installer or detection-script execution

Search the logs for the app name, app ID, detection terms, and return codes:

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

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

A useful evidence chain is:

install command completed successfully
-> detection evaluated
-> expected artifact not found
-> app reported failed

That points to a detection, context, path, version, or registry-view correction. If the chain instead shows download or command failure before detection, fix the package or install command.

Microsoft also recommends excluding the Intune Management Extension content directories from antimalware scanning so content can install and execute correctly. On x64 clients, the documented locations include C:\Program Files (x86)\Microsoft Intune Management Extension\Content and C:\Windows\IMECache.

The verified fixes

If detection is wrong

Change the rule to a stable artifact that exists after a successful install. Use the actual file path, correct registry view, current MSI product code, or a short detection script. Avoid a temporary setup file, a shortcut, or a version equality check that the vendor changes between builds.

See the narrower Intune Win32 detection error 0x87D1041C guide when the status explicitly identifies detection failure.

If context is wrong

Make install behavior and detection agree. A required device app normally needs a machine-wide installation and machine-visible detection. A per-user app needs a user-scoped assignment and a rule that is valid for each intended profile. Do not “fix” a system-context deployment by hard-coding one employee’s C:\Users\... path.

If the policy is stale

After changing the app rule, sync the device and verify that the updated policy was evaluated. On a controlled test device, you can restart the extension service:

Restart-Service IntuneManagementExtension -Force

Then watch the new AppWorkload.log entries. A local test is not complete until the device reports the updated rule and the admin center reflects the new state.

If installation really failed

Follow the installer’s return code and logs. Check for missing content, a pending reboot, silent-install switches that are not supported by the vendor, insufficient permissions, or antimalware interference. Do not declare success because a partial executable or old version remains on disk.

Prevention checklist

• Test install, uninstall, and detection on a clean Windows VM.
• Write down the install context, detection artifact, registry view, product code, and expected version.
• Test PowerShell detection as SYSTEM when the app is deployed in system context.
• Keep install commands silent; Microsoft does not support interactive Win32 app installation.
• Pilot new packages and detection changes before broad required assignment.
• Capture IntuneManagementExtension.log, AppWorkload.log, and AppActionProcessor.log with each incident.
• Treat “installed but failed” as an evidence problem first, not automatically a packaging problem.

Bottom line

When an Intune Win32 app is present on Windows but marked Failed, prove the deployment in sequence: install command, context, detection artifact, client policy, and reporting. The fastest fix is usually the smallest one that makes the configured detection rule match the artifact the installer actually created.

The Intune App Failure Analyzer can help organize the initial evidence in your browser. It accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs, but it does not replace validation on the affected device.

References

• Microsoft Learn: Add and assign Win32 apps to Microsoft Intune
• Microsoft Learn: Troubleshoot Win32 apps in Microsoft Intune
• Microsoft Learn: Intune Management Extension for Windows