Win32 Application Installation Issues — Day 5 of the Microsoft Intune Real-Time Troubleshooting Series
Day 5 of the Microsoft Intune Real-Time Troubleshooting Series
Welcome to Day 5 of the Microsoft Intune Real-Time Troubleshooting Series — 15 days, 15 real-world scenarios, 15 practical solutions.
Day 1 was a device that would not enroll; Day 2, a user locked out of the Company Portal; Day 3, a device judged noncompliant; Day 4, settings that would not land. Today the device is enrolled, signed in, compliant, and taking its policies — and still the app will not install. The Company Portal says Install failed, or Install pending since yesterday. Or, most confusing of all, the app is sitting right there on the desktop — installed and working — while Intune insists it failed.
A Win32 app install is a chain with three links: the package has to reach the device, the installer has to run clean, and Intune’s detection rule has to find the result. Each link fails differently, reports a different code, and lives in a different log.
1. Real-World Scenario
It is Tuesday morning, and the operations team has shipped a required update: FieldOps 3.1, the line-of-business app every field technician uses, packaged as a Win32 app and assigned as Required to 600 Windows 11 laptops. The plan is simple: Intune pushes the new package, the installer runs silently, and by lunchtime everyone is on 3.1.
By 9 a.m. the admin center tells three different stories at once: about 180 devices show Install failed with error 0x80070643; about 90 have sat on Install pending since the assignment went out; and about 40 show Install failed with error 0x87D1041C — even though the technicians on those machines are already running FieldOps 3.1, and the app opens fine.
The tickets disagree: some users never saw the app arrive, some watched an installer window flash and vanish, and some are asking why IT says an app they are actively using has failed to install.
Nobody can say yet whether the package is broken, the installer is broken, or Intune is wrong about all three groups.
2. Root Cause Analysis
A Win32 app install fails in a small number of places, and they fail in a predictable order of likelihood. Work through them in this sequence before touching the device.
1. The detection rule is wrong — the app installed, Intune says it failed. The most common cause. Detection — not the installer’s exit code — is the final judge of “installed.” If the rule looks for the wrong file path, version, or MSI product code, the install succeeds and Intune still reports 0x87D1041C (“The application was not detected after installation completed successfully”). Here, the 40 “failed but working” devices are exactly this: the detection rule checks for C:\Program Files\FieldOps\fieldops.exe version 3.1, but the new installer puts the executable in C:\Program Files\FieldOps\bin\fieldops.exe. The app is there. The rule is looking in the wrong place.
2. The installer itself failed — MSI error 1603. 0x80070643 is the HRESULT wrapper around Windows Installer error 1603, “Fatal error during installation.” It is deliberately generic: it means the installer gave up, and nothing more. The 180 devices in this group need the installer’s own verbose log to say why. Searching for 0x80070643 without that log is a dead end.
3. The install command is not actually silent. Some installers accept a silent switch and then show a prompt anyway — a license agreement, a “close these applications” dialog, a restart question. A required install runs with no user watching, so the prompt sits unseen. The tell is 0x87D300C9 (“Unmonitored process in progress, may time out”): the installer was still running when the agent stopped watching it. Almost always a hidden prompt, not a slow network.
4. Another installation is already in progress. Error 1618 (0x80070652) means Windows Installer is busy — Windows Update, another app, or an Office setup is holding the installer. Intune maps 1618 to Retry by default (three attempts, five minutes apart), so a lone 1618 usually clears itself.
5. The content never arrived. 0x87D30065 (“Failed to retrieve content information”) means the Intune Management Extension never got the package details it needed, and nothing was installed. The download itself can also stall: the .intunewin package downloads over HTTPS and is cached under C:\Program Files (x86)\Microsoft Intune Management Extension\Content. A proxy, a firewall rule, or a Delivery Optimization problem leaves the device stuck on Install pending.
6. The install ran in the wrong context. Win32 apps install as System by default, or in the signed-in user’s context if you choose user install behavior. A per-user installer run as System writes its files into the System profile, where the user never sees them — and a detection rule that looks in the user’s profile finds nothing. Conversely, a machine-wide installer run as User fails for lack of rights, typically 0x80070005 (“Access is denied”). Install behavior and detection rule must agree about whose machine this is.
7. The device does not meet the requirements. Win32 apps need Windows 10 version 1607 or later, and the app’s requirements page gates on OS architecture and minimum OS version. A device that does not meet them shows Not applicable — the app was never attempted. Any additional requirement rules you added can also silently exclude exactly the machines in the tickets.
8. The retry cooldown is hiding your fix. After three consecutive failures, the Intune Management Extension puts the app on the Global Re-evaluation Schedule (GRS) — a roughly 24-hour cooldown. During that window the device ignores the app entirely, and changing the app in the admin center does not reset the cooldown. You can fix the detection rule and re-upload the package, and the device will still ignore the app until the window expires or you clear the state on the device.
9. The Intune Management Extension itself is the problem. Win32 apps and PowerShell scripts are delivered by the Intune Management Extension (IME), installed automatically the first time a script or Win32 app is assigned. If the service is stopped, stuck, or running an old version, nothing in this lane works — and the device’s app status goes quiet rather than red. Also remember the hard limit: the IME only installs Win32 apps on corporate-owned devices. A personally owned device never gets them, however correct the assignment looks.
3. Step-by-Step Troubleshooting
Work in this order: find which stage failed, then fix that stage.
1. Read the exact status and error code in the admin center. Open the app (Apps > Windows, select FieldOps 3.1) and look at Device install status. Note the status and the error code on the failed devices. 0x80070643, 0x87D1041C, 0x87D30065, and 0x87D300C9 each point at a different stage.
2. Translate the code before searching for it. Win32 error codes arrive wrapped as an HRESULT: 0x8007 plus the code in hex, so 0x80070643 is just installer exit code 1603 and 0x80070652 is 1618. Decode it first, because the installer’s documentation speaks in exit codes, not HRESULTs. Then map the code to the stage: content (0x87D30065), install (0x80070643, 0x80070652, 0x87D300C9), or detection (0x87D1041C).
3. Check the Troubleshoot pane. In Troubleshooting + support > Troubleshoot, select the user and the device, with assignments set to Managed apps. It shows whether the device actually received the assignment, whether the IME is healthy, and when the device last checked in. If the assignment never arrived, the fix is assignment, not the installer.
4. Test the install command as SYSTEM. The install runs as System by default, and most install failures only reproduce in that context. On a test machine, run the exact install command from the app’s Program page under the System account (PsExec -s from Sysinternals does this). If it fails there, the command is wrong — fix the command, not Intune.
5. Re-run the installer with a verbose log. For an MSI, run msiexec /i "FieldOps.msi" /qn /norestart /l*v "%TEMP%\FieldOps-install.log" and search for “Return value 3” to find the exact custom action or step that failed. The verbose log is the only place a 1603 ever explains itself.
6. Read AppWorkload.log. On the device, open C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log in CMTrace (or OneTrace) and search for [Win32App]. On newer IME builds this file records every step: content download, unpack, install command, exit code, and detection result. On older builds the same detail is in IntuneManagementExtension.log. Read the stage before the code. If the device is remote, use Collect logs on the app’s Installation details pane instead — the IME logs land in the device’s Device diagnostics section.
7. Check whether the content actually downloaded. Look in C:\Program Files (x86)\Microsoft Intune Management Extension\Content for the app’s cached package. If the folder is empty or the download is partial, the failure is delivery, not installation — check the proxy, the firewall, and Delivery Optimization.
8. Verify the detection rule against reality. On a device where the app is installed but Intune says failed, check what the rule looks for — the file path and version, the MSI product code, or the registry value — against what is actually on the disk. A path that moved between versions, a wrong version operator, or a product code copied from the old package are the three usual suspects.
9. Check the GRS cooldown before re-testing a fix. If the app failed three times, the device is in its roughly 24-hour Global Re-evaluation Schedule window and will ignore the app no matter what you changed in the portal. On a test device only, stop the IntuneManagementExtension service and delete the app’s state under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\<user SID> including its GRS key, and start the service again. Clearing the state resets the timer — it does not fix the underlying failure.
10. Confirm the install behavior matches the installer. Open the app’s Program page and check Install behavior: System or User. A per-user installer must run as User; a machine-wide installer must run as System. If they disagree, change the behavior to match the installer — and change the detection rule to look where that context actually installs.
11. Check the IME itself. Confirm the IntuneManagementExtension service is running and check its version — an old IME misses fixes for known Win32 issues. Restarting the service forces the IME to re-check for app and script assignments immediately. If the service will not start, or the Logs folder is missing entirely, the IME was never installed: confirm the device is corporate-owned and enrolled, then trigger a sync.
4. PowerShell Commands
Each of these is a real command an admin runs on the device or against the tenant. Run the device-side ones in an elevated prompt where noted.
# Decode the HRESULT from the portal into the installer's exit code (0x80070643 -> 1603)
[int]0x80070643 -band 0xFFFF# Confirm the Intune Management Extension service is running (elevated prompt)
Get-Service IntuneManagementExtension | Select-Object Name, Status, StartType# Restart the IME to force an immediate re-check for app and script assignments (elevated prompt)
Restart-Service IntuneManagementExtension# List the IME log files, newest first — AppWorkload.log is the Win32 install log on newer builds
Get-ChildItem 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs' |
Sort-Object LastWriteTime -Descending | Select-Object Name, Length, LastWriteTime# Search AppWorkload.log for the failure lines (run in the Logs folder)
Select-String -Path 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log' -Pattern 'error|failed|0x87D' |
Select-Object -Last 20 LineNumber, Line# Check whether the app content actually downloaded to the device
Get-ChildItem 'C:\Program Files (x86)\Microsoft Intune Management Extension\Content' -Recurse -File |
Measure-Object -Property Length -Sum | Select-Object Count, @{Name='TotalMB'; Expression={[math]::Round($_.Sum / 1MB, 1)}}# Check whether the app is actually installed (never use Win32_Product — it triggers a repair on every MSI)
Get-Package -Name '*FieldOps*' | Select-Object Name, Version, ProviderName# Verify the detection rule's target: does the file exist, and what version is it really?
Test-Path 'C:\Program Files\FieldOps\bin\fieldops.exe'
(Get-Item 'C:\Program Files\FieldOps\bin\fieldops.exe').VersionInfo.FileVersion# Check the MSI registration: product code, version, and uninstall string
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -like '*FieldOps*' } |
Select-Object DisplayName, DisplayVersion, PSChildName, UninstallString# List the IME's per-user Win32 app state, including GRS cooldown keys (elevated prompt)
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps' -Recurse -Depth 2 |
Select-Object Name# From the admin side: list the devices reporting Install failed on this app (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes 'DeviceManagementApps.Read.All'
$appId = '<app-id-from-the-admin-center>'
Invoke-MgGraphRequest -Method GET -Uri "deviceManagement/mobileApps/$appId/deviceStatuses" |
Select-Object -ExpandProperty value |
Where-Object { $_.installState -eq 'failed' } |
Select-Object deviceName, userPrincipalName, installState, errorCode# Run the MSI with a verbose log to find the real reason behind a 1603 (elevated prompt)
msiexec /i "FieldOps.msi" /qn /norestart /l*v "%TEMP%\FieldOps-install.log"5. Important Log Locations
| Location | What it tells you |
|---|---|
| C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log | The Win32 app log on newer IME builds: content download, install command, exit code, and detection result. Read this first. |
| C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log | The main IME log: agent check-ins, policy requests, processing, and reporting. On older IME builds, the Win32 install detail lives here. |
| C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log | PowerShell script execution — the install and uninstall scripts, and any detection script the app uses. |
| C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppActionProcessor.log | The action processor’s view of app assignments — what the IME was told to do with each app. |
| C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\Win32AppInventory.log | The installed-MSI inventory the IME collects — what the device believes is installed, independent of your detection rule. |
| %TEMP%\FieldOps-install.log | The verbose MSI log from msiexec /l*v — the only place a 1603 (0x80070643) explains itself. Search for “Return value 3”. |
| C:\Program Files (x86)\Microsoft Intune Management Extension\Content | The downloaded .intunewin content cache. Empty or partial content here means a delivery failure (0x87D30065). |
| HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\<user SID> | Per-user Win32 app state, including the GRS keys that hold the roughly 24-hour retry cooldown. |
| Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin | The MDM channel log. Enrollment and configuration profiles — not Win32 app installs. If you are reading this log for an app failure, you are in the wrong log. |
6. Practical Resolution
Back to the 600 laptops: three groups, three causes, one app.
The 40 “failed but working” devices are a detection-rule miss. The installer moved the executable to a bin subfolder in 3.1, but the rule still looks in the old path. The fix: correct the detection rule to C:\Program Files\FieldOps\bin\fieldops.exe with version greater than or equal to 3.1. Those devices flip to Installed on the next detection pass — no reinstall needed.
The 180 devices with 0x80070643 need the verbose log. On a sample machine, msiexec /l*v shows the install failing on a custom action that checks for a running FieldOps process — and 3.0 is still running, because the old version was never closed. The fix: close the old version before the new one installs. A re-test as SYSTEM confirms the command now runs clean.
The 90 devices stuck on Install pending never got the content. Their AppWorkload.log shows 0x87D30065, and the Content folder is empty. The branch offices those machines sit in route through a proxy that blocks the Intune content endpoint. The fix is a proxy allowlist change, not an app change.
The fix, in order:
- Correct the detection rule to the real installed path and version; confirm the 40 devices flip to Installed.
- Fix the install command so the old version is closed before the new one installs; verify it as SYSTEM on a test machine.
- Fix the proxy allowlist for the content endpoint; confirm the pending devices download and install.
- On the test devices that hit three failures, clear the GRS state so the corrected app is picked up immediately, not after the 24-hour cooldown.
- Add a pre-flight step to the runbook: package the app, install it as SYSTEM on a clean test machine, and confirm the detection rule matches the real installed artifact before any required Win32 app ships fleet-wide.
7. Interview Questions
Q1: A Win32 app shows Install failed with error 0x87D1041C, but the app is installed and working on the device. What happened?
The install succeeded and the detection rule failed. Detection — not the installer exit code — is the final judge of “installed,” so Intune reports 0x87D1041C. Fix the detection rule to match the real installed artifact — the correct file path, version operator, or MSI product code — and remember the GRS cooldown: after three failures the device ignores the app for roughly 24 hours unless you clear the state.
Q2: What does error 0x80070643 mean, and how do you find the real reason behind it?
It is the HRESULT wrapper around Windows Installer error 1603, “Fatal error during installation.” It is deliberately generic, with no further information. Decode it first ([int]0x80070643 -band 0xFFFF gives 1603), then re-run the installer with a verbose log — msiexec /i ... /l*v "%TEMP%\app-install.log" — and search for “Return value 3” to find the exact step that failed. Test the command as SYSTEM, the context Intune runs it in.
Q3: What is the difference between System and User install behavior, and why does it matter?
System runs the installer as the System account, machine-wide; User runs it in the signed-in user’s context. A per-user installer run as System writes into the System profile, where the user never sees it; a machine-wide installer run as User fails for lack of rights (0x80070005). Install behavior, installer, and detection rule must all agree about whose machine the app lands on.
Q4: You fixed the detection rule, but the devices still show Install failed. Why?
The Global Re-evaluation Schedule (GRS). After three consecutive failures the IME puts the app on a roughly 24-hour cooldown. On a test device, stop the IntuneManagementExtension service, delete the app’s state under HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\<user SID> including its GRS key, and start the service again.
Q5: Where do Win32 app installation failures get logged, and which file do you open first?
On the device, in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Open AppWorkload.log first on newer IME builds — it records the download, install, exit code, and detection result step by step. On older builds the same detail is in IntuneManagementExtension.log. Read them with CMTrace or OneTrace. The MDM event log (DeviceManagement-Enterprise-Diagnostics-Provider) does not cover Win32 installs — that is the wrong log for this problem.
Q6: A required install shows 0x87D300C9. What is happening on the device?
The installer was still running — usually waiting on a prompt nobody can see — when the agent stopped watching it. A required install runs with no user watching, so the prompt sits unseen forever. Fix the install command with the correct silent switches and verify it by running it as SYSTEM on a test machine, confirming no window appears.
Day 5 done. Tomorrow, Day 6: Intune Management Extension Troubleshooting — when the agent that installs your apps and runs your scripts is itself the problem.
Follow the series here on ongoingideas.com — one scenario a day, for 15 days.
Missed the start of the series? Begin with Day 1: Windows Device Not Enrolling into Intune, then Day 2: Company Portal Login Failures, then Day 3: Device Compliance Issues, then Day 4: Configuration Profile Failures.