When a Win32 app fails in Intune, the portal gives you a status and maybe an error code. The real story is on the device, in the Intune Management Extension (IME) logs. Almost every failure comes down to one of eight causes.
Where to look
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.logAppWorkload.log covers download, install, and detection for each app. Open it with CMTrace or any log viewer that highlights errors, and search for the app's ID (the GUID in the portal URL).
To force the IME to re-check apps right away:
Restart-Service -Name IntuneManagementExtension1. The detection rule never matches
Error: 0x87D1041C, "The application was not detected after installation completed successfully."
The installer ran and exited cleanly, but your detection rule doesn't match what it actually installed. Check the rule against reality on a test machine:
- MSI product code changes between versions. Detect on the new code.
- File or folder paths differ between 32-bit and 64-bit installs.
- Registry detection on a 64-bit client: the IME runs as a 32-bit process, so tick Associated with a 32-bit app on 64-bit clients only when the app really writes to the 32-bit registry view.
2. The install command isn't silent
If the installer waits for a click, the install runs until timeout in a session nobody can see. Test your exact command line from a SYSTEM context first:
# PsExec from Sysinternals opens a SYSTEM shell for testing
psexec.exe -i -s powershell.exe3. Wrong install context
- System context installs for the whole machine, and can't reach the user's profile or mapped drives.
- User context installs as the signed-in user, who may not have admin rights.
Per-user installers deployed in System context "succeed" into the wrong profile, then fail detection.
4. Return codes aren't mapped
Many installers return 3010 (success, reboot required) or custom codes. If a code isn't in the app's Return codes list, Intune treats it as a failure. Add the vendor's documented codes.
5. Requirements aren't met
If a requirement rule isn't met (OS version, architecture, disk space, or a custom script), the app shows Not applicable instead of failing. Check that the rule reflects your real fleet.
6. Dependencies and supersedence
Dependencies install first. If one fails, the parent never starts, and the error shows up on the dependency, not the app you're watching. Supersedence can uninstall the old version before the new one installs, so test the uninstall command too.
7. The download never finishes
Large packages over slow or metered links can stall. Look for download progress in AppWorkload.log. Delivery Optimization settings, VPN split tunneling, and proxy rules all affect this.
8. The package itself is bad
- Built with an outdated Win32 Content Prep Tool. Always use the current
IntuneWinAppUtil.exe. - The setup file name in the install command doesn't match the file inside the package. It's case-sensitive for some installers.
- The source folder contained the output of a previous packaging run, which bloats or breaks the package.
When it's every app, not one
If most apps are failing, stop troubleshooting apps. Check that the IME is installed and running, that the device's clock is correct, and that nothing (security software, proxy, SSL inspection) is interfering with downloads from Microsoft's content delivery network.