Why do some Win32 apps fail to install via Intune without any clear errors?

Hi,

This pattern is more common than it should be, and in most cases it isn’t the installer itself, it’s how the Intune Management Extension (IME, sometimes referred to as the Sidecar Agent) is orchestrating the install context. When you see “Unknown Error” with no obvious logs, I’d start by pulling the IME logs from C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, particularly IntuneManagementExtension.log and AgentExecutor.log, they usually contain more detail than Event Viewer.

A frequent root cause is context mismatch: Intune runs installs under SYSTEM by default, while your manual test likely runs under a user context, so dependencies (like user profiles, mapped drives, or permissions) can behave differently. I’d also double-check your detection rules, if they’re too strict or misaligned, Intune can report a failure even when the install actually succeeded.

Another angle is timing and environment readiness; on that 10% of devices, you may be hitting transient states (pending reboots, locked files, or security controls like AV/EDR blocking execution silently). Enabling verbose logging in your installer (if supported) and wrapping the install command in a logging script can help surface what Intune itself doesn’t expose.

If you want a more deterministic approach, consider testing the package using PsExec (SYSTEM context) locally to replicate Intune behavior more closely. That often reveals gaps that don’t show up in standard manual runs.

If this helped you move forward, feel free to hit “Accept Answer”

Jason

Silent Win32 app failures through Intune are usually due to how detection, context, or dependencies behave under the Intune Management Extension (Sidecar), not because the agent is “having a bad day.” The same .intunewin can succeed interactively but fail under system/user context, different permissions, or missing prerequisites.

A structured way to track and diagnose these failures:

1. Use Intune’s built‑in troubleshooting and diagnostics
   • In the Intune admin center, go to Troubleshoot + support → Managed Apps for the affected device and app to see:
     • Assignment status (required/available/uninstall)
     • When the app was created, modified, targeted, and delivered
     • The raw error code (even if the portal labels it “Unknown”)
   • For failing Win32 apps, open the app’s Installation details and select Collect diagnostics:
     1. Choose Collect diagnostics.
     2. Provide full paths to relevant log files (for example, under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs and any app‑specific logs) and select OK.
     3. After ~15–20 minutes, use Download diagnostics to pull the collected bundle.
   • This diagnostic collection is specifically designed for Win32 app install failures and can gather logs that are not obvious in Event Viewer or %TEMP%.
2. Read the Intune Management Extension logs on the client On an affected device, check the agent logs (best viewed with CMTrace):
   • Location: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
   • Key logs:
     • IntuneManagementExtension.log – overall agent activity, policy processing, and reporting.
     • AppWorkload.log – app check‑ins, install attempts, applicability, and detection logic.
     • AppActionProcessor.log – detection and applicability checks in detail. These logs typically show:
   • Whether the app was considered applicable.
   • The exact command line executed.
   • Exit codes from the installer.
   • Detection rule evaluation (for example, MSI product code, file/registry checks).
3. Check for “installed but not detected” scenarios Some “unknown” or confusing failures are actually detection issues, not install failures. For example:
   • Error 0x87D1041C indicates the app installed but Intune could not detect it (for example, user uninstalled it later, or a self‑updating MSI changed its product version outside Intune).
   • In such cases, the fix is to adjust detection rules or instruct users to reinstall from Company Portal. Required apps will reinstall on next check‑in.
4. Validate the installer in SYSTEM context Intune Win32 apps typically run in the system context. A package that works interactively under a user account can fail silently as SYSTEM if:
   • It expects user profile paths.
   • It needs UI or elevation that isn’t available in silent mode.
   • It depends on per‑user prerequisites.
   To simulate Intune’s behavior:
   1. Use PSExec on a test device: psexec -accepteula -s -i cmd.
   2. In the new SYSTEM command prompt, run the same install command used in the Win32 app (for example, setup.exe /silent or msiexec /i "MyApp.msi" /q).
   3. If it fails there, the problem is with the installer or command line under SYSTEM, not Intune.
5. Confirm prerequisites and architecture/dependency issues Some failures map to Windows app deployment errors like:
   • 0x80073CF3 – dependency/conflict/architecture mismatch.
   • 0x80073CF2 – invalid package data. Even if Intune surfaces these generically, the underlying cause can be:
   • Wrong architecture (x86 vs x64) on some machines.
   • Missing or conflicting dependencies.
   • A different version of the app already installed. Use the device logs and, if applicable, the AppXDeployment-Server event log for those specific codes.
6. Exclude Intune content/cache from antimalware scanning On some endpoints, aggressive antivirus scanning can interfere with content staging and execution for Win32 apps, leading to intermittent or opaque failures. Recommended exclusions:
   • On x64 clients:
     • C:\Program Files (x86)\Microsoft Intune Management Extension\Content
     • C:\Windows\IMECache
   • On x86 clients:
     • C:\Program Files\Microsoft Intune Management Extension\Content
     • C:\Windows\IMECache
7. Use Win32 app diagnostics consistently on the failing 10% For the subset of machines that fail:
   • Trigger Collect diagnostics for each failing device/app.
   • Compare AppWorkload.log and IntuneManagementExtension.log between a working and a failing machine.
   • Look for differences in:
     • Applicability checks (OS version, architecture).
     • Detection rule results.
     • Exit codes from the installer.

This approach turns “unknown error” into a concrete root cause by leveraging Intune’s Win32 diagnostics, the Sidecar logs, and SYSTEM‑context testing, rather than relying on temp/Event Viewer alone.

References:

• Troubleshooting Intune app installation issues
• Intune app installation error reference
• Troubleshooting Win32 app installations with Intune
• Troubleshoot Win32 App Issues
• Application installation common error codes reference
• Troubleshooting packaging, deployment, and query of Windows apps