Warning: Hotpatching on ARM64 Will Fail Unless You Do This First

Let’s talk about something that hit a little too close to home recently: Hotpatching on ARM64 devices — and more importantly, why it breaks things if you don’t disable CHPE first.

I’m writing this post because — well, you guessed it — one of my lovely colleagues enabled Hotpatch on my ARM64 test device. And yes… it completely broke everything.

No, seriously. This wasn’t the first time. I already had to restage the entire device once after a previous Hotpatch test went sideways. Apps crashed, installs failed, event logs filled with cryptic errors — the works.

And since I’d really like to avoid a third time, I decided to take matters into my own hands.

So I built a proper Intune remediation that:

• Detects if its a ARM64 Device and CHPE is still enabled
• Disables it automatically
• And warns the user (me) with a friendly popup to reboot — before everything goes to hell again

The best part? I’ve assigned it to the same pilot group that’s testing Hotpatch. So next time someone decides to “test something quickly” on my device again, at least I’m already covered.

Ah yes… the joy of being in the pilot group. Always an adventure, right? 😄

And here’s a helpful tip I learned while investigating all this:

If your system is already unstable because Hotpatching was enabled with CHPE still active — simply setting the registry key to disable CHPE and rebooting will usually fix everything.

No need to wipe and reinstall. That registry key is your reset button.

So even if you’re reading this after things have gone wrong, you’re not out of luck. Just apply the fix and breathe easy.

Now, let’s walk through how it all works — and how to deploy the fix automatically with Intune.

So, what is CHPE?

CHPE stands for Compiled Hybrid Portable Executable. It’s a Microsoft technology that helps improve performance on ARM64 devices by optimizing how they run traditional x86 apps.

Basically, when an app was originally built for x86 (like many Windows apps are), it normally has to run in emulation mode on ARM devices. That emulation is functional, but slower. CHPE tries to fix this by creating hybrid binaries — files that include both x86 and native ARM64 code — so performance is much better than emulation alone.

The operating system uses these hybrid CHPE binaries whenever possible to speed things up. You’ll find them on the device under this folder:
C:\Windows\SyChpe32

Why is CHPE a problem for Hotpatching?

Here’s the issue: the Hotpatching system can’t work with CHPE binaries.

Hotpatching relies on being able to update specific parts of the Windows OS in memory without rebooting. But CHPE binaries can’t be safely patched that way. So if CHPE is enabled, any attempt to apply a hotpatch that affects those binaries will just fail silently.

That’s why Microsoft requires CHPE to be disabled before you can rely on Hotpatching on ARM64 devices.

To disable CHPE, you only need to set one registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
HotPatchRestrictions = 1 (DWORD)

What happens if you enable Hotpatch without disabling CHPE?

From Microsoft’s official documentation, you’re told that CHPE must be disabled before Hotpatching will work on ARM64 devices. But in practice, what happens if you forget or skip that step?

💥 In short: things start breaking — fast and unpredictably.

Here’s what I’ve experienced firsthand on ARM64 devices where Hotpatch was enabled while CHPE was still active:

• Random app crashes, even from trusted, enterprise-grade apps
• Inability to install or uninstall software, particularly MSI-based applications
• The Windows Installer Service can stop responding or throw errors
• Event Viewer fills with obscure errors tied to the Hotpatch loader

For example, you might see this in Event Viewer:

Or this when installing a VPN client or similar app:

These kinds of issues can be extremely difficult to troubleshoot if you’re not aware of the CHPE/Hotpatch conflict. Because there’s no obvious alert or warning — Hotpatch is technically enabled, but silently fails behind the scenes, sometimes corrupting normal system operations.

⚠️ If you’re seeing strange installer issues or random process crashes on ARM64 after enabling Hotpatch, check that CHPE is disabled first. It’s likely the root cause.

That’s exactly why I built the Intune remediation script — not just to apply the registry setting, but also to proactively warn the user to reboot, ensuring that the system fully switches over to x86-only emulation mode and avoids this unstable state.

What happens when CHPE is disabled?

Disabling CHPE does have some consequences. Mainly, you lose performance benefits for x86 apps that were being optimized with those hybrid binaries. That means:

• Some apps may run slower
• There’s a small chance of compatibility quirks if an app relied on CHPE behavior

However, it’s worth noting that:

• Many modern apps now include native ARM64 builds anyway
• The performance hit is generally acceptable for most workloads
• You gain much better update flexibility and security with Hotpatching

If you’re considering rolling this out broadly, I highly recommend testing it on a few pilot devices first.

How to properly disable CHPE with Intune (and prompt users to reboot)

Now that we understand why CHPE must be disabled before enabling Hotpatching on ARM64 devices, let’s go into how you can do this in a scalable, automated, and user-friendly way — using Microsoft Intune remediations.

I’ve created a complete script package that includes:

1. A detection script – to verify whether CHPE is already disabled
2. A remediation script – to apply the required registry change and notify the user with a popup (even though the script runs as SYSTEM)

📦 You can find the full script package here:
👉 github.com/MG-Cloudflow/Intune-Hotpatch-ARM64-Remediation

🕵️‍♂️ Detection Script – “Should I fix this?”

The detection script checks two key things:

• Is the device running on an ARM64 processor?
• Is the required registry key (HotPatchRestrictions) already set to 1?

If the answer is no to either of those, it marks the device as non-compliant, which tells Intune to run the remediation script.

Here’s what’s happening behind the scenes:

$cpuArch = (Get-CimInstance Win32_Processor).Architecture
$registryPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management"
$registryName = "HotPatchRestrictions"

if ($cpuArch -eq 12) {
    try {
        $value = Get-ItemPropertyValue -Path $registryPath -Name $registryName -ErrorAction Stop
        if ($value -eq 1) {
            exit 0  # Already set correctly
        } else {
            exit 1  # Wrong value
        }
    } catch {
        exit 1  # Key not found or unreadable
    }
} else {
    exit 0  # Not ARM64 – no action needed
}

It’s lightweight, fast, and ensures that your remediation script only runs where it’s actually needed.

🛠 Remediation Script – “Fix it and notify the user”

The remediation script does two things:

• Sets the required registry value to disable CHPE:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
HotPatchRestrictions = 1

• Notifies the logged-in user that a reboot is required to complete the change, using a scheduled task.

Here’s why the scheduled task approach matters:

Since Intune remediations run in the SYSTEM context, anything like a message box or toast notification would not appear to the user unless we explicitly run that part of the code in the user’s session.

We solve this by creating a scheduled task that runs a small PowerShell popup script as the logged-in user and triggers it immediately.

Here’s a simplified breakdown of what happens:

# Set the HotPatchRestrictions registry key
Set-ItemProperty -Path $registryPath -Name "HotPatchRestrictions" -Value 1 -Type DWord

# Write a PowerShell script to show a MessageBox
$popupScript = @'
Add-Type -AssemblyName PresentationFramework
[System.Windows.MessageBox]::Show(
    "To complete the configuration for Windows Hotpatch updates, your device needs to reboot. Please save your work and restart as soon as possible.",
    "Windows Hotpatch Configuration",
    "OK",
    "Information"
) | Out-Null
'@

# Save the popup script to disk
Set-Content -Path "$env:ProgramData\HotpatchReminder.ps1" -Value $popupScript -Force

# Create a one-time scheduled task that runs as the logged-in user
Register-ScheduledTask -TaskName "NotifyUser-RebootForHotpatch" `
    -Action (New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File `"$env:ProgramData\HotpatchReminder.ps1`"") `
    -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(1)) `
    -User $loggedInUser -RunLevel Limited -Force

# Run the task immediately after creating it
Start-ScheduledTask -TaskName "NotifyUser-RebootForHotpatch"

📌 Important: If no user is logged in, the popup is skipped — but the registry setting is still applied. The device will then use the correct CHPE mode after its next reboot.

Deploying in Intune: Step-by-Step

• Open Microsoft Intune Admin Center
• Go to Devices > Remediations
• Click + Create script package
• Upload the detection and remediation scripts
• Set script settings:
  • ✅ Run in 64-bit PowerShell
  • ❌ Do not run using logged-in credentials (the popup handles user session)

• Assign to a group that contains To your Windows Hot Patch Devices
• Choose a schedule (daily or weekly is fine)

From there, Intune will automatically evaluate each device and apply the fix where needed — and your users will get a clear and professional reboot reminder, without you lifting another finger.

Final Thoughts

Hotpatching is great. ARM64 is great. But they don’t work together unless you disable CHPE first.

If you’re managing a mixed device environment or piloting Hotpatch, I highly recommend putting this remediation in place — before you end up with broken app installs, mysterious Event Viewer errors, or the dreaded full device reset.

Yes, disabling CHPE comes with trade-offs.

You may notice slower performance for some x86 apps, especially if they previously benefited from CHPE acceleration. In some edge cases, certain workloads might behave a little differently or take a bit longer to launch. It’s not the end of the world, but it’s definitely worth keeping an eye on — especially if you support users who rely on older, x86-only software.

I’ll be doing more performance testing in the coming weeks to better understand the real-world impact of disabling CHPE, especially across different types of workloads and app stacks. I’ll update this blog post once I have more concrete numbers and test results to share.

And if you’re also living life on the bleeding edge in a pilot group — I salute you.
It’s not easy being first… but at least we get the blog content out of it, right? 😉