HKLM vs. HKCU Detection Rules in Intune Win32 Apps: Fix False Failed States

A Win32 app can be installed and usable while Intune still reports Failed. One of the most common reasons is a registry detection rule looking in the wrong hive: HKLM for a per-user install, or HKCU for a machine-wide deployment.

The registry path is not a cosmetic detail. It tells Intune which installation boundary the rule is trying to prove. If the installer writes to one hive and the detection rule checks the other, the rule returns not detected even when the application is on the device.

This guide shows how to choose the hive, verify the registry view, and correct the smallest layer that is actually wrong.

Quick Fix checklist

1. Confirm the app’s Install behavior is System or User.
2. Identify whether the installer writes machine-wide or into a user profile.
3. Record the exact registry key, value name, data type, and comparison configured in Intune.
4. Check both native and 32-bit registry views on a 64-bit test device.
5. Query the hive under the identity used by the deployment, not only from an administrator’s interactive profile.
6. Compare the installed value with the detection rule’s comparison and expected data.
7. Change the detection rule only after the installer output is proven.
8. Sync one test device and confirm a fresh AppWorkload.log detection result before broad redeployment.

For a second opinion on the evidence, use the free Intune App Failure Analyzer. It is browser-based and client-side: the page states that logs stay in the browser and are not uploaded or stored. It accepts an error code, install command, detection rule, install context, registry view, or IME/AppWorkload log. Use its result to organize triage, then verify the proposed fix on the device.

HKLM or HKCU? Start with the install boundary

Use HKLM when the application is installed for the device or all users. Typical machine-wide installers write to locations such as:

• HKLM:\SOFTWARE\Vendor\Product
• HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
• HKLM:\SOFTWARE\WOW6432Node\... for a 32-bit application on 64-bit Windows

Use HKCU only when the application is intentionally installed for a particular user and its installer writes to that user’s profile hive. A user-scoped application may place its configuration under:

• HKCU:\Software\Vendor\Product
• a per-user uninstall key under the user’s profile
• a user-specific installation directory such as %LOCALAPPDATA%

Microsoft describes Intune Win32 System context as applying to all users of a Windows device and User context as applying to a particular user.[1] Choose the detection hive from the installer’s real behavior, not from the fact that the application has a graphical interface.

A desktop application can have a user interface and still be installed machine-wide. Conversely, an installer launched by an administrator can still create only a per-user installation.

Why the obvious diagnosis can be wrong

When the admin center shows a failed Win32 app, it is tempting to assume that the installer did not run. That is not enough evidence. The install command and the detection rule are separate parts of the workflow.

A typical false failure looks like this:

install command runs successfully
-> installer writes HKLM or HKCU
-> Intune evaluates the configured detection rule
-> rule checks the other hive or another registry view
-> app is reported as not detected

The reverse can also happen: an app writes a key to HKCU for the interactive user, but a System-context deployment evaluates detection as SYSTEM. The key exists for Alice, but it is not evidence in the SYSTEM user’s hive.

Do not create a duplicate marker in the other hive just to make the app appear installed. First make the deployment context, installer behavior, and detection rule describe the same scope.

Step 1: inspect the Win32 app configuration

In the Intune admin center, open Apps > All apps, select the Windows app (Win32), and record:

• Install behavior: System or User.
• Assignments: user or device groups and the install intent.
• Install command: whether it is silent and whether it assumes a signed-in user.
• Detection rules: registry key path, value name, data type, operator, expected value, and 32-bit registry setting.
• Return codes and restart behavior.

Microsoft’s Win32 app configuration separates the registry key path, value name, comparison type, and the option to search the 32-bit registry on 64-bit clients.[1] A rule can therefore be wrong in more than one way: the hive can be wrong, the key can be wrong, or the rule can be searching the wrong view.

Do not infer the hive from the assignment alone. A user assignment does not guarantee that the vendor installer writes to HKCU, and a device assignment does not repair a per-user installer.

Step 2: prove where the installer wrote

Replace the example vendor and product names with the values from your package. Check machine-wide uninstall evidence first:

$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, PSChildName, InstallLocation

Then check a known machine-wide application key:

Get-ItemProperty 'HKLM:\SOFTWARE\Contoso\Client' `
  -ErrorAction SilentlyContinue |
  Select-Object Version, InstallPath

For a user-scoped deployment, run the check as the intended user:

Get-ItemProperty 'HKCU:\SOFTWARE\Contoso\Client' `
  -ErrorAction SilentlyContinue |
  Select-Object Version, InstallPath

These commands prove what the current identity can see. They do not by themselves prove what the Intune Management Extension saw during deployment. That is why context and log evidence must be checked next.

Step 3: check the 32-bit and 64-bit registry views

On 64-bit Windows, a 32-bit application and a 64-bit application can use different views of redirected registry locations. Microsoft exposes a Win32-app setting to search the 32-bit registry on 64-bit clients; the detection rule must match the view in which the installer wrote.[1]

Use .NET registry APIs when you need to make the view explicit:

$Hive = [Microsoft.Win32.RegistryHive]::LocalMachine
$View = [Microsoft.Win32.RegistryView]::Registry32
$Base = [Microsoft.Win32.RegistryKey]::OpenBaseKey($Hive, $View)
$key = $Base.OpenSubKey('SOFTWARE\Contoso\Client')

if ($key) {
  [pscustomobject]@{
    View    = $View
    Version = $key.GetValue('Version')
    Path    = $key.GetValue('InstallPath')
  }
}

$Base.Dispose()

Repeat with [Microsoft.Win32.RegistryView]::Registry64 when appropriate. If the value exists only in the 32-bit view, configure the Intune rule to search the 32-bit registry for the 32-bit application. If it exists only in the native view, do not enable the 32-bit option merely because the device is 64-bit.

A path that appears as WOW6432Node in a native registry inspection is a clue, not a universal fix. Match the view to the installer and the detection setting.

Step 4: account for HKCU identity

HKCU is relative to the account performing the query. The same literal path can produce different results for Alice, a local administrator, and SYSTEM.

For a System-context app, an HKCU rule is usually a design warning. A device-wide deployment should use stable machine-visible evidence such as HKLM, C:\Program Files, or C:\ProgramData. Do not depend on the first user who signs in.

For a User-context app, confirm all of the following:

• the app is assigned to the intended user;
• the installer is designed to run without unsupported interaction;
• the key is created in that user’s hive;
• the detection rule is evaluated for that user’s deployment scenario;
• the rule does not hard-code another employee’s profile.

Microsoft notes that a user-targeted Win32 app requiring device administrator permissions can fail for a standard user.[2] That is an install-context problem, not evidence that changing HKCU to HKLM will make the package correct.

Step 5: read the client logs

The standard Intune Management Extension log directory is:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Microsoft identifies these logs as useful for Win32 troubleshooting:[2]

Log	What it can confirm
IntuneManagementExtension.log	Check-in, policy request, policy processing, and reporting
AppWorkload.log	App check-in, install, applicability, detection, and reporting
AppActionProcessor.log	Detection and applicability checks
AgentExecutor.log	PowerShell installer or detection-script execution

Search for the application name, detection terms, and the policy evaluation around the install attempt:

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = 'Contoso','Detection','NotDetected','Detected','return code'

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

The important question is not whether a registry key exists in an administrator’s session. It is whether the log shows the deployment evaluating the expected key under the expected context and view.

Verified fixes by failure pattern

The app is machine-wide but detection checks HKCU

Keep System context. Change detection to a stable HKLM key, MSI product code, or machine-wide file. If the installer writes to the 32-bit view, enable the corresponding 32-bit registry search option in Intune.

The app is per-user but detection checks HKLM

Keep User only if the installer and assignment are genuinely user-scoped. Change the rule to the actual HKCU path and test with an intended user on a clean profile. If the app should serve every user, repackage it for a machine-wide installation instead of making HKCU detection more complicated.

The hive is correct but the value is missing

Check the exact key path, value name, data type, and comparison operator. A string comparison against a numeric value, a renamed vendor key, or a version equality check can produce not detected even in the correct hive.

The key exists but only in one registry view

Confirm whether the installer is 32-bit or 64-bit. Query both views explicitly, then make the Intune 32-bit registry setting match the proven location.

The key exists for the user but not for System

Do not copy the key into HKLM as a workaround. Decide whether the package is supposed to be per-user or machine-wide. Then align install behavior, assignment, installer switches, and detection with that decision.

Related troubleshooting paths

If the app is visible but Intune reports Failed, start with The Intune Win32 App Installed but Says Failed. If the status includes 0x87D1041C, use Fix Intune Win32 App Detection Failed 0x87D1041C. For the broader deployment-scope decision, see System vs. User Install Context in Intune Win32 Apps.

Prevention checklist

• Document the installer’s actual hive and registry view beside the package.
• Keep System deployments machine-visible and User deployments profile-aware.
• Test registry detection on a clean 64-bit device in both relevant views.
• Test System detection under SYSTEM, not only in an administrator console.
• Test User detection with the intended user and assignment.
• Record the exact key, value, type, operator, and expected data.
• Capture AppWorkload.log and AppActionProcessor.log during pilot validation.
• Avoid creating synthetic registry markers solely to satisfy detection.

Bottom line

HKLM versus HKCU is a scope decision. Use HKLM for evidence that belongs to the device, and HKCU only for evidence that genuinely belongs to the assigned user’s installation. Then verify the registry view and deployment identity. When the installer, context, hive, view, and detection comparison agree, a false failed state has a concrete fix instead of another package rebuild.

References

• Microsoft Learn: Add and assign Win32 apps to Microsoft Intune
• Microsoft Learn: Troubleshoot Win32 apps in Microsoft Intune
• Intune App Failure Analyzer