Intune Win32 App Stuck in Pending Install: Troubleshooting Guide

Start on the device itself, not the portal. The portal shows a last-known state from the device's most recent check-in and can lag by hours.

Step 1: Verify IME is running

Get-Service -Name IntuneManagementExtension | Select-Object Name, Status, StartType

Expected output: Status: Running. If stopped or disabled, that is your primary cause. Jump to Fixes.

Step 2: Check device join state

dsregcmd /status

Look for AzureAdJoined: YES and MDMEnrolled: YES. If either is NO, the device may not be receiving Intune policies. For hybrid-joined devices, also check DomainJoined: YES. See the Intune Device Enrollment Failure Troubleshooting Guide if enrollment itself is broken.

Step 3: Read the IME log

The IME log at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log is the authoritative source of truth for Win32 app processing. Open it in CMTrace (from the MECM toolkit) or any text editor and search for the app name or its Intune app ID.

Key log entries to find:

• [Win32App] Waiting for content download -- IME found the assignment but content download is stalled
• [Win32App] Detection criteria returned: false -- the detection rule did not match after install
• [Win32App] Skipping app install due to dependency -- a dependency app is not installed
• [Win32App] Successfully installed with a later [Win32App] Detection result: false -- install succeeded but detection is broken
• Error downloading content with a hash value -- ContentVersion mismatch or incomplete upload

Step 4: Test the detection rule manually

If the log shows detection returning false, test the detection rule directly on the device:

• File detection: check the exact path and version in Explorer or PowerShell
• Registry detection: use reg query or Get-ItemProperty to check the exact key/value
• MSI product code: run Get-WmiObject -Class Win32_Product | Where-Object {$_.IdentifyingNumber -eq "{PRODUCT-CODE}"} or use the Apps & Features list
• PowerShell detection script: run the script manually in an elevated PowerShell session and check the exit code and output

Step 5: Check the Intune portal troubleshooting blade

In the Intune portal, go to Troubleshoot + support > Troubleshoot. Select the user, then under Assignments check the app. The portal will show if the device is in scope, what the last reported status is, and when it last synced. Cross-reference with the IME log timestamp.

IME service stopped or crashed

# Restart IME service (run as administrator)
Restart-Service -Name IntuneManagementExtension -Force

# Verify it started
Get-Service -Name IntuneManagementExtension

If the service crashes immediately after restart, check Event Viewer under Application for IME-related errors. A corrupted IME installation may require re-enrollment or re-installing the agent via a support escalation.

Force a policy sync

After any fix, trigger a sync to speed up reprocessing:

# Trigger Intune sync via scheduled task (runs as SYSTEM)
Get-ScheduledTask | Where-Object {$_.TaskName -eq "PushLaunch"} | Start-ScheduledTask

Alternatively, open the Company Portal app on the device, go to Settings, and click Sync. Or in the Intune portal: Devices > [Device] > Sync.

Device not in assignment group

1. In the Intune portal, go to Apps > [App] > Properties > Assignments
2. Confirm the correct group is listed under Required or Available
3. Navigate to Groups > [Group] > Members and verify the device or user is a member
4. For dynamic groups, check the dynamic membership rule is evaluating correctly -- use Dynamic membership rules > Validate rules to test a specific device or user

Detection rule mismatch

If the app installed but detection fails:

1. Edit the app in the Intune portal (Apps > [App] > Properties > Detection rules)
2. Correct the file path, registry key, version value, or MSI product code
3. Save and wait for the next policy sync, or force a sync after saving

For PowerShell detection scripts, test locally to confirm the script exits with code 0 and writes the expected output to stdout. A script that throws an exception or exits with a non-zero code returns false regardless of content.

ContentVersion mismatch

If the IME log shows hash failures or download errors:

1. Delete the existing Win32 app from the Intune portal
2. Re-prepare the .intunewin package with the latest version of the Win32 Content Prep Tool
3. Re-upload as a new app and re-assign
4. Do not replace the content on an existing app entry if the original upload was corrupt -- create a new app entry

Dependency or supersedence chain broken

1. In the Intune portal, go to Apps > [App] > Properties > Dependencies
2. Verify each dependency app is itself in an Installed state on the device
3. Install dependency apps manually or investigate why they are also stuck
4. For supersedence, verify the older version's detection rule is not still returning true if you expect the new version to replace it

After applying a fix and triggering a sync, allow 5-10 minutes and then verify:

In the Intune portal:

1. Go to Apps > [App] > Device install status (or User install status)
2. Find the target device and confirm the status changes from Pending Install to Installed
3. If the status is Failed, click the device name to see the error code

On the device: Check the IME log for a fresh entry showing successful install and detection:

[Win32App] Successfully installed app: [AppName]
[Win32App] Detection result: true

Confirm the app is present:

# For MSI-based apps
Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -like "*AppName*"}

# For file-based detection
Test-Path "C:Program FilesYourAppyourapp.exe"

# Check installed programs via registry (faster than Win32_Product)
Get-ItemProperty HKLM:SoftwareMicrosoftWindowsCurrentVersionUninstall* |
  Where-Object {$_.DisplayName -like "*AppName*"} |
  Select-Object DisplayName, DisplayVersion

Open a Microsoft Intune support ticket when:

• The IME log shows repeated ContentVersion mismatch errors after re-uploading the app package cleanly
• The IME service crashes immediately after restart with no clear error in Event Viewer
• The Intune troubleshooting portal shows the device as Not targeted even though group membership is confirmed correct and the dynamic rule validates successfully
• Multiple devices across different network locations all show Pending Install for the same app with no detection or download failures in the IME log (indicates a backend Intune service issue)
• The app was successfully deployed before and no changes were made -- this suggests a backend ContentVersion desync in the Intune service

Information to gather before contacting support:

• Device name, Entra ID object ID, and Intune device ID (from the portal URL when viewing the device)
• The full IME log from C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\ (last 3-4 log files if they have rolled over)
• App ID from the Intune portal URL (when viewing the app properties)
• Screenshot of the Device install status page for the affected device
• Output of dsregcmd /status from the device

For compliance-related blocks (device shows non-compliant and Conditional Access is preventing Intune sync), see the Microsoft Intune Compliance Policy Troubleshooting Guide first -- a Conditional Access block will prevent policy delivery entirely and show up as Pending Install across all assigned apps simultaneously.