Fix Intune Win32 App Detection Failed 0x87D1041C

Intune Win32 app error 0x87D1041C usually lands after the installer already ran. The device may have the application in Programs and Features, the shortcut may exist, and the user may be able to launch it. Intune still reports the deployment as failed because the Win32 detection rule did not return an installed state.

That distinction matters during an outage. If you treat 0x87D1041C like a normal installer failure, you will keep rebuilding packages that were never the problem. The right fix is to prove whether the Intune Management Extension can see the same evidence your detection rule expects.

Use this runbook when the Intune admin center shows a Win32 app as failed, install completed, not detected, or 0x87D1041C after deployment.

Quick Fix checklist

Work in this order:

1. Open the affected app in Intune and confirm the device install status shows detection failure, not only install command failure.
2. On one affected device, collect IntuneManagementExtension.log, AppWorkload.log, and AppActionProcessor.log from C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
3. Search the logs for the app name, app ID, detection rule, Detection state, Detected, NotDetected, and 0x87D1041C.
4. Manually verify the detection evidence on the device: file path, registry key, MSI product code, or custom PowerShell output.
5. If the app installs per-user, check whether the detection rule is looking under the wrong user profile or the wrong registry hive.
6. If the app is 32-bit on 64-bit Windows, check registry redirection under HKLM:\SOFTWARE\WOW6432Node.
7. If using a PowerShell detection script, make it return installed only through a clean exit code and output pattern. Test it as SYSTEM.
8. Update only the detection rule first. Do not republish a new installer unless logs prove the install command failed.
9. Sync the device or restart the Microsoft Intune Management Extension service to re-evaluate the app.
10. Watch the device status move from failed to installed before broad redeployment.

Root Cause

0x87D1041C is a detection problem. The Win32 app workflow has two separate steps:

• Run the install command.
• Run the detection rule to decide whether the app is present.

The install command can finish successfully while detection still fails. Intune then cannot mark the app installed, so the deployment reports failure even if the binary is present.

Common root causes include:

• The file detection rule checks the wrong path or filename.
• The registry detection rule checks HKLM:\SOFTWARE while the app writes to HKLM:\SOFTWARE\WOW6432Node.
• The MSI product code in Intune does not match the installed MSI product code.
• The vendor installer changes version numbers, but the detection rule still checks an old version.
• The app installs in the user’s profile, but the rule checks a machine-wide location.
• A PowerShell detection script writes output but exits with the wrong code.
• The script works in an admin console but fails under the Intune Management Extension SYSTEM context.
• The detection script uses current-user registry paths, mapped drives, network shares, or environment variables that do not exist for SYSTEM.
• Antivirus or endpoint protection scans the Intune content cache and interrupts staging or post-install files.

Microsoft’s Win32 app troubleshooting guidance points admins to the Intune Management Extension logs and lists AppActionProcessor.log and AppWorkload.log as key files for detection, applicability, and install processing. Microsoft’s Win32 app creation guidance also separates MSI, file, registry, and custom script detection rules, which is where most 0x87D1041C fixes happen.

Logs and where to check

Start in the Intune admin center:

Intune admin center > Apps > Windows > select the Win32 app > Monitor > Device install status

Open the affected device and confirm the failure details. If the install status says the app was not detected after installation, move to the client.

On the Windows device, collect logs from:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Focus on these files:

Log file	Why it matters
IntuneManagementExtension.log	Policy check-in, app policy processing, service behavior
AppWorkload.log	App install, applicability, detection, and reporting flow
AppActionProcessor.log	Detection and applicability checks for app actions
AgentExecutor.log	PowerShell execution details when scripts are involved

Search for the app name and the app ID. Then search for detection language:

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = '0x87D1041C','Detection','NotDetected','Detected','AppActionProcessor','AppWorkload'

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

If the logs are large, pull a short window around the app name:

$AppName = 'Contoso VPN Client'
Get-ChildItem 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs' -Filter '*.log' |
  ForEach-Object {
    Select-String -Path $_.FullName -Pattern $AppName -Context 5,10
  }

A detection issue often reads like this in plain English:

Install command completed.
Detection rule evaluated.
Application was not detected.
Reporting enforcement state as failed.

That means the next step is not a new .intunewin package. The next step is to validate the rule.

Validate file detection rules

If your detection rule checks a file, confirm the exact path from a local SYSTEM-safe command. Do not trust a shortcut, Start menu entry, or vendor display name.

$ExpectedFile = 'C:\Program Files\Contoso\VPN\ContosoVPN.exe'

if (Test-Path $ExpectedFile) {
  Get-Item $ExpectedFile | Select-Object FullName, Length, LastWriteTime, VersionInfo
} else {
  Write-Host "Missing: $ExpectedFile"
}

If Intune checks a file version, compare the installed version to the rule:

$File = 'C:\Program Files\Contoso\VPN\ContosoVPN.exe'
[System.Diagnostics.FileVersionInfo]::GetVersionInfo($File) |
  Select-Object FileVersion, ProductVersion, OriginalFilename

Fix patterns:

• Use the real installed path, not the path inside the installer package.
• Avoid version equals checks when vendors ship minor hotfixes without notice.
• Prefer greater than or equal to for stable products where the vendor follows versioning.
• Check the binary that always exists after install, not a temporary setup file.
• For per-user installs, avoid C:\Users\SomeUser in a fleet-wide detection rule.

Validate registry detection rules

Registry detection failures are common with 32-bit apps on 64-bit Windows. Check both native and redirected locations.

$Paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

Get-ItemProperty $Paths -ErrorAction SilentlyContinue |
  Where-Object DisplayName -like '*Contoso*' |
  Select-Object DisplayName, DisplayVersion, Publisher, PSChildName, InstallLocation

If Intune checks a specific key or value, query it directly:

$Key = 'HKLM:\SOFTWARE\WOW6432Node\Contoso\VPN'
Get-ItemProperty -Path $Key -ErrorAction SilentlyContinue |
  Select-Object Version, InstallPath

Fix patterns:

• Match the correct registry view for 32-bit vs 64-bit apps.
• Use the uninstall key only if the vendor writes it consistently.
• Do not check HKCU for a required device-targeted app unless the install is truly user-scoped and the deployment logic accounts for user context.
• Avoid display name only when multiple editions share a similar name.

Validate MSI product code detection

If the Win32 app wraps an MSI, confirm the installed product code. The product code is not the same thing as the upgrade code.

$UninstallRoots = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

Get-ItemProperty $UninstallRoots -ErrorAction SilentlyContinue |
  Where-Object DisplayName -like '*Contoso*' |
  Select-Object DisplayName, DisplayVersion, PSChildName

PSChildName is often the MSI product code when the app registered through Windows Installer. Compare it to the product code in the Intune detection rule.

Fix patterns:

• If the vendor changes MSI product code with every major version, update detection during each package revision.
• If multiple related MSI packages install, detect the one that proves the final application is present.
• Do not copy product codes from an old package unless you verified the current installer.

Fix PowerShell detection scripts

A PowerShell detection script should be simple. It must answer one question: is the app installed on this device right now?

Use a predictable pattern:

$Path = 'C:\Program Files\Contoso\VPN\ContosoVPN.exe'
$MinimumVersion = [version]'5.4.0.0'

if (-not (Test-Path $Path)) {
  exit 1
}

$ActualVersion = [version]([System.Diagnostics.FileVersionInfo]::GetVersionInfo($Path).FileVersion)

if ($ActualVersion -ge $MinimumVersion) {
  Write-Output "Installed"
  exit 0
}

exit 1

Test the script locally before uploading it to Intune:

powershell.exe -ExecutionPolicy Bypass -File .\Detect-ContosoVPN.ps1
$LASTEXITCODE

Then test as SYSTEM. PsExec is common in lab environments:

psexec.exe -i -s powershell.exe

Inside the SYSTEM PowerShell window, run the detection script again. If it fails there, Intune will likely fail too.

Avoid these detection script mistakes:

• Returning exit 0 for both installed and not installed paths.
• Writing success text before a later command throws an error.
• Checking a mapped drive.
• Reading HKCU while running in system context.
• Using a relative path that depends on the current working directory.
• Calling a vendor executable that needs user interaction.

Force a safe re-evaluation

After fixing the detection rule, do not wipe the app immediately. First force Intune to re-check the device.

From the client:

Restart-Service IntuneManagementExtension -Force

Then trigger a device sync from the Company Portal or Intune admin center:

Intune admin center > Devices > Windows > select device > Sync

Watch logs again:

Get-Content 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log' -Tail 200 -Wait

If detection succeeds, the device status should eventually change to installed. If it stays failed, confirm whether the device received the updated app policy. A stale policy can make you think the new detection rule failed when the client has not evaluated it yet.

When the installer really did fail

Do not ignore the install command. Detection failure is common, but some apps fail both install and detection.

Check for these clues:

• The installer process returned a nonzero exit code.
• The expected install directory does not exist.
• The app is missing from both uninstall registry locations.
• AppWorkload.log shows download, extraction, or install command errors before detection starts.
• Endpoint protection quarantined files under C:\Windows\IMECache or the Intune Management Extension content folder.

Microsoft recommends excluding the Intune Management Extension content folders from antimalware scanning for proper Win32 app installation and execution. If multiple Win32 apps suddenly fail across the same device group, check Defender or third-party AV policy changes before repackaging every app.

Prevention

Prevent repeat 0x87D1041C incidents with a packaging checklist:

• Build every Win32 app with a detection rule that matches the real installed artifact.
• Test install, uninstall, and detection on a clean VM before assigning to production users.
• Test PowerShell detection as SYSTEM, not only as a local administrator.
• Document whether the app is machine-scoped or user-scoped.
• Record the MSI product code, file path, version, registry key, install command, uninstall command, and return codes in the package notes.
• Use pilot groups before broad required deployment.
• Keep a saved copy of the detection script in source control with the package version.
• Avoid fragile detection based on Start menu shortcuts, desktop shortcuts, temporary files, or vendor names alone.
• Monitor the first wave in Device install status before adding more devices.

Admin takeaway

For Intune Win32 app 0x87D1041C, stop chasing the installer until logs prove it failed. In most cases, the app installed and the detection rule could not prove it. Match the rule to a stable file, registry value, MSI product code, or clean PowerShell script, then force the Intune Management Extension to re-evaluate.

Once the device reports installed, keep the fixed rule with the package notes. The next time the vendor updates paths, versions, or product codes, you will know exactly what to validate before production assignment.

References

• Microsoft Learn: Troubleshoot Win32 apps in Microsoft Intune
• Microsoft Learn: Add and assign Win32 apps to Microsoft Intune
• Microsoft Learn: Collect diagnostics from a Windows device