How to Read Intune Management Extension and AppWorkload Logs for Win32 App Failures

When an Intune Win32 app shows Failed, the admin center gives you the outcome, not always the boundary where the deployment broke. The installer may have returned an error, the app may have been considered not applicable, detection may have missed an installed app, or the client may have reported an older result.

The fastest way to stop guessing is to read the Intune Management Extension (IME) logs in sequence. This guide explains what each relevant log can prove, where to find it, and how to connect the entries into a verified fix.

Quick Fix checklist

1. Capture the app name, assignment, install intent, reported status, and error code from Intune.
2. On the affected Windows device, open C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
3. Start with AppWorkload.log and search for the app name or app ID.
4. Check AppActionProcessor.log for applicability and detection decisions.
5. Check AgentExecutor.log when the install command or detection script runs PowerShell.
6. Use IntuneManagementExtension.log to confirm policy retrieval, processing, check-in, and reporting.
7. Compare the log evidence with the actual install command, context, detection rule, and registry view.
8. Sync one test device and confirm the new result before changing assignments or rebuilding the package.

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

Where the logs are

Microsoft documents the standard IME log directory as:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

The folder is protected system data, so collect the files with suitable administrative access. Microsoft also recommends tools such as CMTrace for easier reading, but Notepad, PowerShell, or another text viewer is enough for a targeted search.

Do not start with only the last line in a log. A reporting error can be downstream of a detection failure, and a detection failure can be downstream of an incorrect install context.

What each log proves

Log	Use it to answer
AppWorkload.log	Did the IME receive, evaluate, install, detect, and report the Win32 app?
AppActionProcessor.log	What applicability and detection checks did the client perform?
AgentExecutor.log	What happened when a PowerShell install or detection script executed?
IntuneManagementExtension.log	Did the client check in, retrieve policy, process it, and report status?

Microsoft identifies AppWorkload.log as the main workload log for Win32 app deployment activity. It is the best starting point because it commonly connects the app check-in, install attempt, applicability, detection, and reporting stages.

The reading order that avoids false diagnoses

1. Start with AppWorkload.log

Search for a distinctive app name, the app ID, or a package identifier. PowerShell can search all four logs:

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

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

Replace Contoso with a string that actually appears in your app policy or installer. A broad search for failed alone usually creates noise.

In AppWorkload.log, identify the sequence around the same app:

policy or app received
  -> applicability evaluated
  -> content or install command processed
  -> installer result recorded
  -> detection evaluated
  -> state reported

The exact wording varies by IME version. Treat the sequence as the evidence model, not as a requirement that every line use the same phrase.

2. Classify the first failed boundary

The first failed boundary is more useful than the final Intune label.

• No policy or app activity: investigate check-in, IME health, assignment, filters, and policy timing.
• Not applicable: investigate requirements, architecture, OS version, detection or applicability logic, and assignment scope.
• Download or extraction failure: investigate content availability, connectivity, storage, and package integrity.
• Install command failure: investigate the command line, silent switches, exit code, dependencies, and execution identity.
• Install succeeds but detection is not detected: investigate the detection rule, path, value, registry hive, registry view, and install context.
• Client shows success but portal is stale: investigate reporting and allow a fresh sync before reassigning.

The obvious diagnosis is often wrong because Failed does not mean “the installer never ran.” An executable on disk is also not enough proof: it may be a leftover file, a per-user install, or an artifact that does not match the configured detection rule.

3. Use AppActionProcessor.log for detection and applicability

If AppWorkload.log shows an install attempt followed by a failed or not-detected state, inspect AppActionProcessor.log around the same timestamp. Compare the log decision with the exact rule configured in Intune:

• file or folder path;
• MSI product code;
• registry hive, key, value, and data type;
• 32-bit registry setting on 64-bit Windows;
• detection script result and execution context.

For a System-context app, a rule that expects a key in a signed-in user’s HKCU is a design warning. For a User-context app, a machine-wide HKLM marker may not prove the intended user installation. Read the rule and the installer as one contract.

Related: HKLM vs. HKCU Detection Rules in Intune Win32 Apps.

4. Use AgentExecutor.log for scripts

When the install command or detection method launches PowerShell, AgentExecutor.log helps separate a script problem from an Intune detection problem. Check:

• the script path and command-line arguments;
• whether the expected identity and environment were available;
• the script exit code;
• errors from missing paths, permissions, quoting, or unavailable user-profile data.

A script that works in an interactive PowerShell window can still fail under IME because the deployment identity, working directory, environment variables, and mapped drives are different. Reproduce the check in the same context before changing the rule.

5. Use IntuneManagementExtension.log for check-in and reporting

Return to IntuneManagementExtension.log after classifying the app result. Use it to confirm whether the device checked in, received policy, processed the policy revision, and attempted to report the result.

If the workload logs show a clear detection failure, fixing check-in settings will not repair the detection rule. If there is no corresponding workload activity after a policy change, a sync and policy retrieval investigation comes first.

A compact evidence worksheet

Record one row for each test attempt:

Field	Value to capture
Device and timestamp	Local time and time zone
App identity	App name and Intune app ID
Assignment	User/device target and intent
Context	System or User
Installer result	Command, exit code, and relevant log line
Detection result	Detected, not detected, or script error
Installed evidence	Exact file, MSI, registry key, or value
Registry view	Native 64-bit or 32-bit, when relevant
Report state	Client result and portal result after sync

This prevents a common troubleshooting mistake: comparing a portal result from one policy revision with device evidence from another attempt.

Verified fixes by failure boundary

Use the boundary to choose the smallest fix:

• Assignment or check-in: correct scope, filters, licensing, IME health, or sync timing.
• Applicability: correct requirements and assignment logic; do not force an incompatible device to install.
• Installer: correct the silent command, dependency order, content, or return-code handling.
• Detection: correct the artifact, path, hive, registry view, version comparison, or script output.
• Reporting: sync the device, confirm the policy revision, and compare a fresh client result with the portal.

Avoid changing several layers at once. If you rebuild the package, change the command, and rewrite detection simultaneously, you lose the evidence that identifies the original fault.

Prevention checklist

• Keep a package worksheet containing the install command, context, detection artifact, and expected exit codes.
• Test System-context packages as SYSTEM, not only as a local administrator.
• Test User-context packages with a standard user when that is the production scenario.
• Validate 32-bit and 64-bit registry views on representative hardware.
• Make detection idempotent and tied to a stable version or product identity.
• Capture AppWorkload.log and AppActionProcessor.log during pilot deployments.
• After changing a rule, sync one device and verify the new policy revision before broad reassignment.
• Remove sensitive identifiers from logs before sharing them outside the organization.

Microsoft sources

1. Troubleshoot Win32 app issues - Microsoft Intune
2. Intune Management Extension for Windows
3. Troubleshooting Win32 app installations with Intune

Related: The Intune Win32 App Installed but Says Failed and System vs. User Install Context in Intune Win32 Apps.