Registry detection rules that silently fail: wrong hive, wrong syntax

Your app installed, but Intune insists it didn't — and during Autopilot that false negative can fail an entire build. Two invisible causes account for most of these: WOW64 registry redirection and PowerShell drive syntax pasted into the Key path field.

The problem

You package a Win32 app, assign it in Intune, and the installation itself succeeds — the installer returns success and the software is demonstrably on the machine. Yet Intune reports the app as Failed or Not detected. Sometimes you get the mirror image: the app was removed long ago, but a stale key in the wrong registry view keeps the detection rule matching, so Intune reports it installed on machines where it isn't.

The most painful place to hit this is Windows Autopilot. If the app is on the Enrollment Status Page (ESP) blocking list, a false not detected fails the whole provisioning run. The person unboxing the device sees a generic app-installation failure with nothing pointing at the actual cause — a detection rule that could never have matched.

Anyone who writes registry-based detection rules for Win32 apps eventually hits one or both of these, because neither produces an error anywhere in the portal.

Why it happens

1. WOW64 registry redirection (the 32/64-bit toggle)

The Intune Management Extension (IME) — the agent that evaluates Win32 detection rules on the device — runs as a 32-bit process. On 64-bit Windows, when a 32-bit process reads HKLM\SOFTWARE, the operating system transparently redirects the read to HKLM\SOFTWARE\WOW6432Node. That is standard WOW64 behaviour, not an Intune bug.

The detection rule's Associated with a 32-bit app on 64-bit clients toggle controls which registry view the IME queries: Yes searches the 32-bit view (the WOW6432Node branch), No searches the native 64-bit view. If the toggle doesn't match where the installer actually writes its keys, the rule reads a view in which the key simply does not exist — and reports not detected with no warning of any kind.

2. PowerShell PSDrive syntax in the Key path field

The Key path field expects a raw registry path with a root such as HKEY_LOCAL_MACHINE\, HKLM\ or HKEY_CURRENT_USER\. Admins who live in PowerShell habitually paste the PSDrive form instead — HKCU:\Software\Vendor\App or HKLM:\SOFTWARE\Vendor\App. The colon-drive syntax is a PowerShell provider path, not a registry path. The portal accepts it without validation, no error is ever raised, and the rule never matches anything.

A related trap worth knowing: detection runs in the context of the evaluating process. For an app deployed in system context — which is everything during the device phase of ESP, when no user is signed in — an HKEY_CURRENT_USER rule cannot see your end user's hive. Prefer HKLM (or a file/MSI rule) for anything that must be detected during device ESP.

The fix

1. Fix the path syntax first — it's the 30-second check.

   Pasted (never matches)	Correct
   HKCU:\Software\Vendor\App	HKEY_CURRENT_USER\Software\Vendor\App
   HKLM:\SOFTWARE\Vendor\App	HKEY_LOCAL_MACHINE\SOFTWARE\Vendor\App or HKLM\SOFTWARE\Vendor\App

2. Establish where the app really writes. On a machine with the app installed, query both registry views. The /reg: switch pins the view regardless of the bitness of the calling process:

   reg query "HKLM\SOFTWARE\Vendor\App" /reg:64
reg query "HKLM\SOFTWARE\Vendor\App" /reg:32

   Whichever returns the key tells you the truth: a hit on /reg:32 means the key lives under WOW6432Node; a hit on /reg:64 means it's in the native 64-bit view. In regedit, that's the difference between SOFTWARE\WOW6432Node\... and SOFTWARE\....

3. Set the toggle to match. Key under WOW6432Node → Associated with a 32-bit app on 64-bit clients = Yes. Key in the native 64-bit view → No.

4. Verify against the ground truth, not the portal. On the client, open C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log and search for Detection (newer agent versions put Win32 app activity in AppWorkload.log in the same folder). The log shows each rule as evaluated and its result; portal status can lag well behind.

5. If you use a custom detection script, pin the registry view explicitly. Don't rely on the bitness of the host process — read via reg.exe query ... /reg:64 or .NET's RegistryView.Registry64 so the script behaves identically wherever it runs.

6. Test before ESP, not during it. Prove detection on an ordinary enrolled device before adding the app to the ESP blocking list — a rule that can never match will fail every build it blocks.

How Decolla handles it

Decolla provisions Windows devices over your own Intune and Autopilot tenant, drawing on its Library — a curated catalogue of 260+ pre-built, industry-tested policies, scripts and fixes across 21 sections. Application items in the Library ship with detection rules validated before they enter the catalogue: exercised against both the 32-bit and 64-bit registry views, with path syntax checked — so a rule that can never match doesn't reach a production build.

Every deployment starts as a written, itemised plan: each item states its delivery method and reversibility class (automatic, reversible, or flagged irreversible), and you approve the plan before anything runs in your tenant. Anything Decolla deploys can be rolled back per item — rollback covers Decolla's own changes, not third-party state.

To be clear about the limits: if you hand-package a bespoke app of your own, Decolla doesn't write that detection rule for you — the checklist above is still yours to run. Decolla is currently pre-launch, with a waitlist open at decolla.app.

Sources

• MSNugget — Fix Intune app detection failures caused by 32-bit vs 64-bit context
• Dharwadkar — Intune HKCU registry detection rule syntax
• Microsoft Learn — Add, assign, and manage Win32 apps in Microsoft Intune