When packaging Microsoft Edge or the Edge WebView2 Runtime for Intune deployment, the obvious detection rule is the one almost every PowerShell template uses: scan HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* for the DisplayName, and mark the app installed if it shows up at the right version. We use that pattern across thousands of detection scripts inside Pckgr for ordinary apps, and most of the time it works fine.

Both Edge and its WebView2 counterpart have a quirk that trips that pattern up, so we had to do a deep dive to figure out the solution. Here’s what we found.

Scenario

A customer hit this recently. They configured an Update Only deployment in Pckgr for WebView2 x86, expecting it would only run on devices that already had the x86 build. The detection rule was the standard registry pattern: if DisplayName matches and DisplayVersion is at or above the target build, mark the app as installed. That rule can’t tell x86 from x64, so on devices already running x64 WebView2 the x86 update ran on top, and a handful of apps that depend on WebView2 stopped behaving.

Once we’d traced the cause, we wanted a detection rule that wouldn’t let this happen on WebView2 or Edge again. Both apps share the same DisplayName-doesn’t-reveal-architecture quirk, so the fix needed to work for both.

The Issue

The Uninstall registry hive often has no consistency on how applications are displayed. The DisplayName and DisplayVersion values tell you Edge or WebView2 is installed and at what version. They don’t reliably tell you the architecture of the msedge.exe or msedgewebview2.exe you’d actually be launching.

If you’ve spent time writing Intune detection rules, you already know how inconsistent this layer is. Vendors pick their own DisplayName conventions, sometimes appending “(64-bit)” and sometimes not. To make things even more confusing, 64-bit applications do not always register in the standard 64-bit uninstall location. In many cases, perfectly legitimate 64-bit apps still appear under the WOW6432Node registry path, especially when vendors use 32-bit installers, bootstrapper-based setups, or legacy packaging frameworks.

Why this becomes a problem

For most apps this doesn’t matter. You install the right architecture, the registry reflects it, the detection passes. Edge and WebView2 are different because:

• The same DisplayName is used across x86 and x64 builds.
• Updates can swap architectures without changing the registry shape.
• Apps that embed WebView2 (Teams, the new Outlook, Office add-ins, plenty of third-party apps) fail when the architecture they expect isn’t the one on the device.
• Intune Requirement rules need a reliable way to say “this device needs the x64 update, not the x86 one”.

A registry-only detection script can mark either app as compliant when the binary on disk is the wrong architecture, and the deployment never self-corrects.

How to confirm

Thanks to the power of the internet, we found out about the PE header trick. Every Windows PE binary carries a Machine field in its header that names the architecture it was compiled for. Two values matter:

• 0x014c is x86 (IMAGE_FILE_MACHINE_I386)
• 0x8664 is x64 (IMAGE_FILE_MACHINE_AMD64)

You can read this directly from the binary without parsing the whole PE structure. Open the file, seek to offset 0x3C to read the PE header offset, jump there plus 4 bytes, then read the next two bytes. This is the key to confirming the correct architecture installed matches what was already on the device.

For Edge, we resolve msedge.exe from the install location:

${env:ProgramFiles(x86)}\Microsoft\Edge\Application\msedge.exe

WebView2 is trickier because the install layout includes a version named subfolder, and that version changes every time the Evergreen Runtime updates. Hardcoding the full path isn’t viable. The script searches under the install root for an x86 WebView2:

${env:ProgramFiles(x86)}\Microsoft\EdgeWebView\Application

It recurses for msedgewebview2.exe, sorts the matching paths descending, and takes the first one. Under current WebView2 version naming that resolves to the latest version folder on the device. From there the PE header check is identical to the Edge one.

The script only returns success when the registry confirms the app is installed and the binary on disk matches the architecture we packaged for. The same logic works as an Intune Requirement rule.

Sample Requirement Script

# Get the Application properties
$AppProperties = Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object { $_.DisplayName -like 'Microsoft Edge WebView2 Runtime*' }
# Check registry detection first
if ($AppProperties) {
    $webViewRoot = "${env:ProgramFiles(x86)}\Microsoft\EdgeWebView\Application"
    $exe = Get-ChildItem -Path $webViewRoot -Filter "msedgewebview2.exe" -Recurse -ErrorAction SilentlyContinue |
        Sort-Object FullName -Descending |
        Select-Object -First 1
    if (!$exe) {
        Write-Host "Application found, but WebView2 executable not found"
        exit 1
    }
    $fs = [System.IO.File]::OpenRead($exe.FullName)
    $br = New-Object System.IO.BinaryReader($fs)
    try {
        $fs.Seek(0x3C, [System.IO.SeekOrigin]::Begin) | Out-Null
        $peOffset = $br.ReadInt32()
        $fs.Seek($peOffset + 4, [System.IO.SeekOrigin]::Begin) | Out-Null
        $machine = $br.ReadUInt16()
        if ($machine -eq 0x014c) {
            Write-Host "Application Found"
            exit 0
        }
        else {
            Write-Host "Application found, but WebView2 is not x86"
            exit 1
        }
    }
    finally {
        $br.Close()
        $fs.Close()
    }
}
else {
    exit 1
}

What to do next

If you’ve packaged Edge or WebView2 yourself in Intune and your detection rule is registry-only, you might want to consider using the PE header trick.

Inside Pckgr, our Edge and WebView2 detection templates now combine the registry version check with the PE header architecture check, so detection only succeeds when the deployed binary matches both the version and the architecture you asked for.