The install reports success. The exit code is 0. And Intune still marks the app as not installed — forever retrying, forever failing compliance. Nine times out of ten, the cause is not the installer at all. It is WOW6432Node: the registry redirection layer that silently moves every 32-bit write on a 64-bit endpoint into a different hive path than the one your detection rule is reading.
This is one of the quietest failure modes in Intune Win32 app deployment, because nothing in the install log looks wrong. The registry key really did get written. It just did not land where you — or your detection rule — expected. Here is exactly why that happens, where it breaks, and how to stop debugging it per app.
Fast Verdict Matrix
| Registry Behavior | Legacy EXE Behavior | Native MSI Behavior |
|---|---|---|
| Where writes land | A 32-bit installer (or a 32-bit bootstrapper wrapping a 64-bit payload) gets silently redirected by WOW64 to HKLM\SOFTWARE\WOW6432Node. Which bitness the installer actually is often is not documented anywhere. | The MSI's Template Summary stream declares its platform explicitly (Intel vs x64), so msiexec.exe always writes to the correct, predictable view — no guessing. |
| Detection rule stability | Registry-path detection rules break the moment a vendor update flips 32-bit/64-bit builds, or the admin who wrote the rule tested against the wrong view. | MSI product-code detection ({GUID}) ignores bitness and registry view entirely — it queries the Windows Installer database directly, not a hive path. |
| Uninstall key location | Uninstall entries also split across HKLM\...\Uninstall and HKLM\...\WOW6432Node\...\Uninstall. Scripts that search only one path silently miss half the installed base. | Windows Installer registers the uninstall entry consistently based on the MSI's declared platform, and Intune's own MSI detection type never has to search for it. |
The Rule of Thumb
- Never trust a registry-path detection rule you have not verified in both views. Check
HKLM\SOFTWARE\...andHKLM\SOFTWARE\WOW6432Node\...before you save the rule, not after the first deployment failure comes in. - The redirection is decided by the process, not the OS or the package format you think you're using. A 32-bit
msiexec.exe(rare, but it exists on some legacy tooling) or a 32-bit bootstrapper stub will get redirected even if the payload it eventually runs is 64-bit.
The Fix: Stop Guessing the View
The usual workaround is a PowerShell wrapper — PSAppDeployToolkit or a hand-rolled script — that checks both registry views explicitly with Get-ItemProperty calls against each path, or forces a specific view with the .NET RegistryView enum. That works, but it means writing, testing, and maintaining that dual-path check for every app in your catalog, and re-verifying it every time a vendor ships a new build that might have changed bitness.
InstallMage removes the guesswork instead of scripting around it. Converting an EXE to a native MSI means the output package declares its platform explicitly, and InstallMage generates the detection rule as an MSI product code — not a registry path — so there is no WOW6432Node ambiguity to check for in the first place. You get one detection method that works regardless of bitness, instead of one PSADT registry check per app that needs re-verifying every release.
Deep Dive
How WOW64 Registry Redirection Actually Works
On 64-bit Windows, the registry has two parallel views under HKEY_LOCAL_MACHINE\SOFTWARE: the native 64-bit view, and a 32-bit view that lives physically at HKLM\SOFTWARE\WOW6432Node. This is not a quirk of any specific installer — it is a core part of the WOW64 (Windows-on-Windows 64-bit) subsystem that lets 32-bit processes run unmodified on 64-bit Windows.
The redirection decision is made by the OS based on the bitness of the process doing the writing, not by any flag in the installer's own code. A 32-bit process that calls RegCreateKeyEx or RegSetValueEx against HKLM\SOFTWARE\... gets transparently redirected by the WOW64 registry redirector to the equivalent path under WOW6432Node. The process never sees the redirection happen — as far as it is concerned, it wrote exactly where it asked to. That is precisely what makes this so easy to miss during packaging: nothing errors, nothing logs a warning, and a manual test run under an admin PowerShell session (usually 64-bit by default) can look completely fine while the actual SYSTEM-context Intune deployment — running whatever bitness process the installer bundle actually launches — writes somewhere else entirely.
This same rule applies to file system paths (Program Files vs Program Files (x86)) and to a smaller set of other redirected locations, but the registry case is the one that breaks Intune deployments most often, because it is the one detection rules query directly.
Where It Breaks: Detection Rules That Read the Wrong View
An Intune Win32 app's registry detection rule targets one specific path. If that path is HKLM\SOFTWARE\Vendor\App and the installer that actually ran was 32-bit, the key exists — just not there. It is sitting at HKLM\SOFTWARE\WOW6432Node\Vendor\App instead. Intune's detection check queries the path exactly as configured; it does not walk both views looking for a match. The result: Intune reports the app as not installed, on every device, forever — even though the install succeeded and the software runs fine.
This produces one of the most confusing support tickets in Intune administration, because the symptoms look like a failed install (perpetual retry, non-compliant status) when the actual install was completely successful. The fastest way to confirm it: open regedit on an affected endpoint and check both paths manually. If the key is present under WOW6432Node but the detection rule points at the native 64-bit path (or vice versa), that is the entire bug.
The fix that does not break again next release: stop using a registry path at all where an alternative exists. For MSI-based apps, an MSI product-code detection rule queries the Windows Installer database directly and is completely immune to this problem, because it does not touch the registry view at all. See the detection rule comparison guide for when registry, file, and script-based rules each make sense.
Where It Breaks: Installer Writes and Broken Uninstall Strings
Redirection does not just affect what Intune reads back — it affects what the installer itself can do mid-install. An installer that explicitly targets the 64-bit view with the KEY_WOW64_64KEY access flag while running as a 32-bit process can hit an access-denied failure if the reflected key already exists with different permissions, which is one of the less obvious root causes behind 0x80070005 (ERROR_ACCESS_DENIED) during Win32 app deployment — covered in more depth in the Intune status error codes guide.
The same split happens to uninstall entries. Add/Remove Programs data — and the UninstallString a cleanup script depends on — gets registered under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\... for 64-bit entries and HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\... for 32-bit ones. A removal or upgrade script that enumerates only one path will silently skip every device where the app landed in the other view — the uninstall string is not broken, it is just not where the script looked. This is a common, quiet source of "ghost" installs that supersedence and cleanup automation never actually reach.
To audit a fleet for this, enumerate both uninstall paths and compare against your app inventory rather than assuming a single bitness. Native MSI packages sidestep the ambiguity because Windows Installer already tracks the product consistently regardless of which uninstall registry path a script happens to check.
Frequently Asked Questions
What is WOW6432Node and why does it exist?
WOW6432Node is the registry path where the WOW64 subsystem transparently redirects registry writes made by 32-bit processes on 64-bit Windows. It exists so 32-bit applications can run unmodified on 64-bit systems without their registry reads and writes colliding with native 64-bit software that might use the same key names.
How do I write an Intune detection rule that works regardless of 32-bit or 64-bit?
For MSI-based apps, use an MSI product-code detection rule instead of a registry path — it queries the Windows Installer database directly and is unaffected by WOW64 redirection. If you must use a registry rule for a non-MSI app, check both HKLM\SOFTWARE\... and HKLM\SOFTWARE\WOW6432Node\... manually on a test endpoint before saving the rule, and re-verify after any vendor update that might change the installer's bitness.
Why does my registry write succeed manually but fail through Intune?
Manual testing is usually done from a 64-bit interactive session, while the actual SYSTEM-context Intune install may launch a 32-bit process that gets redirected to a different view — or hits an access-denied conflict if it also tries to force the 64-bit view explicitly. Reproduce the exact install command under NT AUTHORITY\SYSTEM with PsExec, then check the registry key in both views immediately after, rather than trusting a manual admin-session test.
WOW6432Node does not cause install failures — it causes detection failures and silent uninstall gaps, which are harder to diagnose because the exit code looks clean. Checking both registry views before shipping a detection rule catches most of it. Removing registry-path detection entirely, by converting to native MSI with product-code detection, removes the failure mode for good. For the broader set of Win32 app packaging mistakes this one belongs to, see the Intune Win32 app packaging mistakes guide.