Intune Win32 Detection Script Uses the Wrong Registry View: Fix 32-Bit PowerShell

A Win32 installer can complete successfully while Intune continues to report the app as not detected. One easy-to-miss cause is registry-view mismatch: the detection script reads the 32-bit view while the installer wrote to the 64-bit view, or the reverse.

This is not the same problem as a bad installer. It is an evidence problem. The app can be present, the install command can return success, and the detection script can still exit as if nothing was installed.

Use this runbook when a custom PowerShell detection rule works in an administrator console but fails from the Intune Management Extension, especially when the command invokes powershell.exe on 64-bit Windows.

Quick Fix checklist

1. Confirm the Intune app status says detection or applicability failed after the install command ran.
2. Record whether the app is configured for System or User install behavior.
3. Check the exact install command. Microsoft documents that calling powershell.exe from a Win32 app command launches 32-bit PowerShell; use %SystemRoot%\\Sysnative\\WindowsPowerShell\\v1.0\\powershell.exe when 64-bit PowerShell is required.
4. Collect IntuneManagementExtension.log, AppWorkload.log, and AppActionProcessor.log from C:\\ProgramData\\Microsoft\\IntuneManagementExtension\\Logs.
5. Run the detection logic in both registry views and compare the result with the Intune rule.
6. Test the script in the same install context as the app. A script that depends on HKCU, mapped drives, or an interactive user can give a false negative under SYSTEM.
7. Make the script return exit code 0 only when the expected evidence is present; return a nonzero code otherwise.
8. Re-evaluate the existing app after correcting detection. Repackage only if the install command itself is proven to be wrong.

Why the obvious diagnosis can be wrong

The first instinct is usually to rebuild the .intunewin file or change the silent install switches. That is premature when the installer already placed the application on disk.

A detection script runs in a process with a specific bitness and security context. On a 64-bit Windows device, a 32-bit PowerShell process can see redirected registry locations differently from a 64-bit process. A script that finds the uninstall entry when run from one console may not find it when the Intune Management Extension runs the packaged command.

The other common trap is assuming that the signed-in administrator’s view represents the deployment. A device-targeted System app is evaluated as the local system account. A user-targeted app is evaluated in the user’s context. The correct question is not “does the key exist for me?” It is “does the key exist in the view and context used by this detection rule?”

Evidence to inspect first

Microsoft’s current Win32 troubleshooting guidance identifies these client logs under C:\\ProgramData\\Microsoft\\IntuneManagementExtension\\Logs:

Search for the app name, app ID, Detection, NotDetected, and the script name:

$LogRoot = 'C:\\ProgramData\\Microsoft\\IntuneManagementExtension\\Logs'
Get-ChildItem $LogRoot -Filter '*.log' |
  Select-String -Pattern 'Contoso','Detection','NotDetected','AppWorkload','AppActionProcessor' -SimpleMatch |
  Select-Object Path, LineNumber, Line

Replace Contoso with a distinctive part of the real app name. The useful sequence is normally the install result followed by the detection result. If the install completed and detection returns not detected, stay focused on the rule and its execution context.

Compare both registry views

For an installed MSI or vendor registration, inspect both common uninstall roots:

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

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

If the entry exists only under WOW6432Node, the application registered in the 32-bit view. That does not automatically mean the detection rule is correct: the script still needs to run in the intended bitness and query the intended path.

For a specific vendor key, make the view explicit rather than relying on whichever PowerShell process happens to launch the script:

$KeyPath = 'SOFTWARE\\Contoso\\Product'

$Base64 = [Microsoft.Win32.RegistryKey]::OpenBaseKey(
  [Microsoft.Win32.RegistryHive]::LocalMachine,
  [Microsoft.Win32.RegistryView]::Registry64
)

$Base32 = [Microsoft.Win32.RegistryKey]::OpenBaseKey(
  [Microsoft.Win32.RegistryHive]::LocalMachine,
  [Microsoft.Win32.RegistryView]::Registry32
)

foreach ($item in @(@('64-bit', $Base64), @('32-bit', $Base32))) {
  $key = $item[1].OpenSubKey($KeyPath)
  [pscustomobject]@{
    View = $item[0]
    Present = $null -ne $key
    Version = if ($key) { $key.GetValue('Version') }
  }
  if ($key) { $key.Dispose() }
}
$Base64.Dispose()
$Base32.Dispose()

Use the view that matches the application’s documented registration. Do not make the detector “pass” by accepting any unrelated key that happens to exist.

Fix the command bitness when it matters

Microsoft’s Win32 app documentation warns that calling powershell.exe in an install or uninstall command launches a 32-bit PowerShell instance. To force 64-bit Windows PowerShell, use Sysnative from a 32-bit process:

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File .\Install.ps1

That change is appropriate only when the installer or script requires 64-bit execution. If the app is intentionally 32-bit, keep the deployment consistent and query the 32-bit registry view explicitly. The reliable fix is consistency between installer, detection script, and declared install context, not a random switch until the admin center turns green.

Check System versus User context

For a device-targeted System app, avoid detection rules that depend on a particular user’s profile. HKCU:\\Software\\Contoso, %APPDATA%, mapped drives, and desktop shortcuts can all point at the wrong evidence for a machine-wide deployment.

For a genuinely per-user app, use user targeting and validate the rule in that user’s context. If the installer needs administrator rights but the assigned user is standard, Microsoft notes that the deployment can fail before detection becomes the real issue.

The related HKLM versus HKCU detection guide covers the hive choice in more detail. For the complete client-side timeline, see how to read Intune Management Extension and AppWorkload logs.

Use the free beta analyzer before changing the package

The free Intune App Failure Analyzer is browser-based and client-side. It does not replace validation on the device, but it gives you a structured place to review the evidence you already have. It accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs.

Paste the actual command and rule into the analyzer, then compare its output with the local registry checks and the log sequence. Do not treat a generated interpretation as proof of an installed state; the device and Intune logs remain authoritative.

Prevention checklist

• Declare the intended 32-bit or 64-bit behavior in the package notes.
• Use an explicit registry view when detection depends on a registry key.
• Keep install behavior, assignment targeting, and detection context aligned.
• Test detection as SYSTEM for device-targeted apps.
• Avoid user-profile paths for machine-wide detection.
• Capture a known-good AppWorkload.log sequence during pilot testing.
• Re-test detection after vendor upgrades that change MSI product codes or registry paths.
• Keep the detection rule narrow enough to prove the required app, but stable enough not to break on harmless metadata changes.

Microsoft sources

• Add and assign Win32 apps to Microsoft Intune
• Troubleshoot Win32 apps in Microsoft Intune
• Intune Win32 app detection rules: HKLM vs HKCU
• Intune Win32 app detection failed: 0x87D1041C