Intune Win32 app shows "Failed" after a successful install? It's usually the detection rule

Here's a ticket most Intune admins have seen. The installer ran and the app opens fine on the device, but Intune reports Failed. Or the app installs again every few hours. Or a Required app stays "Install pending" forever.

In most cases the installer is fine. The detection rule is wrong. This post covers why that happens, how detection differs from requirement rules, the mistakes that come up most, and where to look in the logs. Everything here is read-only troubleshooting. You don't need any special tooling.

Intune UI labels and log names change over time, so check them against current Microsoft docs.

---

1. How Intune decides "installed"

For a Win32 app, the Intune Management Extension (IME) on the device runs roughly this sequence:

1. Requirement rules. Is this device allowed to get the app (OS version, architecture, disk space, custom checks)? If not, the app shows Not applicable and nothing else happens.
2. Detection (before install). Is the app already there? If yes, the install is skipped and the app reports as installed.
3. Install. Runs your install command and reads the exit code against your return-code mapping.
4. Detection (after install). Runs the detection rule again. This step decides the final status.

That last step is the part people forget. A clean exit code 0 followed by a detection rule that comes back false means Intune reports the app as not detected after installation, and the status goes to Failed. A Required assignment then retries on its normal schedule, so you get the install loop.

Rule of thumb: exit code success + Failed status = look at detection first.

---

2. Detection rules vs requirement rules

These two get mixed up a lot:

	Requirement rule	Detection rule
Question it answers	"Should this device get the app?"	"Is the app on this device right now?"
When false	Not applicable (no install attempt)	Install attempted (before) or Failed (after)
Typical checks	OS build, x64, free disk, a prerequisite present	MSI product code, file + version, registry value, script
Common mistake	Using it to check "already installed"	Checking something the installer doesn't actually write

If a device shows Not applicable and you expected an install, check the requirement rules. If it shows Failed or keeps retrying, check the detection rule.

---

3. The detection mistakes that cause most loops

MSI product code

• The product code changes between versions. You upgrade the package, keep the old detection rule, and either the new version never detects or the old version detects as "good enough."
• The MSI is wrapped in an EXE bootstrapper that installs several MSIs, and you picked the wrong product code.
• Fix: read the product code from the exact MSI you're shipping, and update it whenever you change versions.

File or folder

• x86 vs x64 paths. A 32-bit app installs to C:\Program Files (x86)\... and your rule checks C:\Program Files\..., or the other way round. Check the "Associated with a 32-bit app on 64-bit clients" setting. It changes which path and registry view the IME checks.
• User-profile installs. The app writes to %LOCALAPPDATA% but the app is set to install in system context, so detection looks in the wrong profile.
• "File exists" with no version. It passes for an old version and leaves you thinking the upgrade worked. Use a version comparison (greater than or equal to the version you ship) where you can.
• Files that stay behind after uninstall. Logs, configs, or an updater folder. Detection stays true and uninstall looks like it failed.

Registry

• WOW6432Node. 32-bit installers write under HKLM\SOFTWARE\WOW6432Node\.... If the 32-bit setting doesn't match, the IME looks in the wrong view.
• HKCU vs HKLM. The IME runs system-context detection, so a value written per user under HKCU isn't where it looks.
• Value type and comparison. Comparing a version stored as a string with an integer or version operator gives results you didn't expect. Check the type in Registry Editor first.
• Uninstall GUID keys that change per version. Same problem as MSI product codes.

Custom detection script

• Detected means exit code 0 and output written to STDOUT. A script that exits 0 and prints nothing counts as not detected. A script that writes errors to STDERR also counts as not detected.
• Slow scripts (network calls, big searches) can time out.
• 32-bit vs 64-bit PowerShell. The script may run in a 32-bit host unless you set it to run as 64-bit, which changes what the registry and file system show it.
• Keep detection scripts read-only and fast. They should check state, never change it.

---

4. Test detection before you assign Required

Do this on a lab VM before you upload. It takes about ten minutes:

Step	Expected
Run your exact silent install command manually	Exit code is what you mapped as success
Check the detection target (file/registry/MSI)	Present, correct version
Run your exact uninstall command	Exit code success
Check the detection target again	Gone

If detection still matches after uninstall, or doesn't match after install, fix the rule before any Required assignment. Pilot the app as Available or on a small Required group of lab devices first.

---

5. Reading the IME logs (high level)

On the device, with authorization, the logs are in:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

Useful files (names vary by IME version):

• AppWorkload.log: newer builds put most Win32 app download, install, and detection activity here.
• IntuneManagementExtension.log: the main IME log. Older builds put Win32 app activity here too.
• AgentExecutor.log: what happened when PowerShell scripts ran, including custom detection and requirement scripts.

How to read them without getting lost:

1. Open the log in a log viewer that handles CMTrace-format logs (or just a text editor) and search for the app name or its app ID (the GUID from the Intune portal URL).
2. Find the requirement result. If it's "not applicable," stop here and fix requirements.
3. Find the install step and note the exit code. Compare it with your return-code mapping.
4. Find the detection after install result. If it's false following a successful exit code, your detection rule doesn't match what the installer wrote. Go back to section 3.
5. Check the vendor's own install log too (add a /log or /l*v switch to your install command). It tells you what was actually written, and where.

You can also gather these logs remotely with the Collect diagnostics device action in Intune where your tenant supports it. That's read-only. It doesn't change the device.

---

6. Quick triage table

Symptom	Most likely cause	First check
Failed, but the app works	Detection doesn't match the install	Detection target vs what the installer wrote
Reinstalls every few hours	Detection false after a successful install	Same, plus 32-bit setting and HKCU vs HKLM
Not applicable	Requirement rule	OS/arch/disk/custom requirement
Install pending forever	Device not checking in, or IME not getting the assignment	Device sync, assignment group
Uninstall "fails"	Detection still true after uninstall	Files or registry keys left behind
Upgrade never happens	Old version still satisfies detection	Add version comparison; update the MSI code

---

Want the full packaging workflow?

Detection is one piece. The Intune Win32 App Packaging Starter Pack from Admin Pack Studio ($39) covers the whole workflow: packaging basics and silent-switch research, detection truth tables for MSI/file/registry/script rules, install and uninstall commands with return codes and logging, six failure triage cards, and pilot-to-production gates including supersedence. It includes one read-only local evidence helper script that checks whether a file or registry path exists and records the file version, so you can design detection rules from real evidence. It doesn't install, uninstall, or change anything.

👉 https://cashflow4375.gumroad.com/l/cgnpzt

If your apps are fine and the real problem is enrollment or compliance, our Intune & M365 Admin Starter Pack covers that ($19 launch week, normally $29): https://cashflow4375.gumroad.com/l/joonf

---

Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant and devices. Pilot first, and check current Microsoft documentation for setting names and log locations.