This blog will discuss a strange Windows Autopilot failure that appeared on newly installed Windows 11 24H2 devices that had been updated with the July update. Even after a clean install and update, the device threw a 8018000a enrollment error. What followed was a deeper investigation into why the Enrollment Status Page (ESP) failed and how a third-party component from BeyondTrust EPM had silently caused the issue.
Introduction
The July Windows 11 24H2 build is now available, and most companies have already begun updating their Windows images or deployment pipelines to support it. In many environments, devices are fully upgraded to the latest version of 24H2 before any Autopilot enrollment begins. Some use OSDCloud to apply the latest build. Others manually upgrade or integrate the upgrade through their existing provisioning workflows. Either way, the goal is the same: start Autopilot from a clean, up-to-date base. (Until Microsoft finally releases the Windows Quality Update during OOBE, we need to do it manually.)
So, when someone approached me about a strange Autopilot failure on a freshly upgraded device, I was interested. The setup was standard. The device had been wiped, reimaged, upgraded to 24H2, and then handed over to Autopilot. Yet during the flow, it failed in a way that made no immediate sense. The error was 8018000a, the one that usually means “this device is already enrolled.”
So that explanation did not make sense at first. The device had just been installed and upgraded. It wasn’t registered in Intune or Entra ID, and there were no signs of any previous MDM/Intune activity. Still, Windows was acting as if the device had already been enrolled.
The Symptom: 8018000a
The Autopilot enrollment kicked off as usual. The device reached the Enrollment Status Page and started pulling policies. But then something went really wrong. Without any clear warning, the device dropped out of the ESP flow and returned to the initial OOBE screen. When the user attempted to continue, Autopilot attempted to start again, and it was at this point that the 8018000a error appeared. The message was clear: “This device is already enrolled.”
It felt like we were dealing with some leftovers or a reused system. However, it was a brand-new, clean build. So where did that enrollment state come from?
Why That 8018000a Error Usually Makes Sense
In most cases, this type of error occurs when enrollment registry keys are still present on the machine. For example, if the device was previously enrolled into Intune and was not fully reset, some artifacts may remain. These could include registry keys under the MDM enrollment path or the Intune MDM device certificate stored in the system certificate store.
When that happens, the fix is well known. You can remove the following:
- Registry keys under HKLM\SOFTWARE\Microsoft\Enrollments
- The corresponding enterprise-mgt Scheduled tasks.
- The Microsoft Intune MDM certificate from the LocalMachine store
The Call4Cloud script covers exactly that scenario. Delete the leftover registry keys and tasks, reboot the system, and Autopilot enrollment typically proceeds without any issues.
But in this case, that explanation did not hold up. The device was 100% clean. It had just been upgraded to 24H2 (with the July build) and had not been enrolled before. So the presence of the enrollment keys and certificate was unexpected.
Zooming Out: What Actually Happened
Looking at the bigger picture, here is what likely happened. Windows Autopilot kicked off as usual. The Enrollment Status Page loaded. Then something crashed during the process. Instead of completing or showing an error, the system quietly returned to the beginning of OOBE.
The user assumed they could just log in again and resume the flow. However, by that time, the MDM enrollment had already been successful behind the scenes. The device had received its Intune MDM certificate, and the registry already contained the enrollment information.
So when the Autopilot process restarted, it tried to perform MDM enrollment again. That triggered a conflict. The device was already enrolled, at least as far as the system was concerned, so Windows blocked the second attempt. And it did so with error 8018000a.
What the Logs Revealed
To determine the actual cause of the failure, we examined the Application event log more closely. It was then that the issue became 100% clear and obvious. The Application Event log showed a crash in wwahost.exe, the host process for modern UWP apps.
The faulting module was PGHook.dll, which comes from BeyondTrust Endpoint Privilege Management, previously known as Avecto Privilege Guard.
That was the missing piece.
Why This Completely Breaks Autopilot with error: 8018000a
During Autopilot, the OOBE experience and the Enrollment Status Page are both powered by CloudExperienceHost.
This component is implemented as a UWP app, which means it runs inside wwahost.exe.
If PGHook.dll injects into that process and causes it to crash, the entire Windows Autopilot experience breaks without warning. With it, the Enrollment Status Page (ESP) disappears and the user is sent back to the beginning of OOBE. But because enrollment already occurred before the crash, the system cannot proceed a second time.
There is no fallback, no recovery. The user just hits the 8018000a wall.
What is a Hook Exclusion?
BeyondTrust Endpoint Privilege Management uses a hooking mechanism to monitor and control how applications run. This involves injecting a DLL (PGHook.dll) into processes like wwahost.exe to intercept API calls and apply policy.
A hook exclusion tells the EPM client to still inject the hook, but keep it dormant. The process is left untouched and allowed to run normally. This is useful when certain applications or system components become unstable due to that injection.
In this case, excluding wwahost.exe ensures that the CloudExperienceHost running inside it is not affected during Autopilot. That prevents the Enrollment Status Page from crashing.
The 8018000a Fix for Now
The only known workaround at this point is to prevent PGHook from injecting into wwahost.exe during Autopilot.
Option 1: Manual registry exclusion (testing only)
This can be done by manually creating the following registry values on the device: [HKEY_LOCAL_MACHINE\SOFTWARE\Avecto\Privilege Guard Client]
“HookExclusions”=multi-string: wwahost.exe
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avecto\Privilege Guard Client]
“HookExclusions”=multi-string: wwahost.exe
When you don’t want to do this manually, you can also export this registry key on a working device and upload it to Registry to PowerShell converter. Which will give you a nice PowerShell script which you can upload to Intune. (PowerShell scripts are executed before Apps. With it, the registry key to exclude wwahost.exe is already present on the device the moment the BeyondTrust agent gets installed.
Option 2: Policy-based exclusion via ManagedHookExclusions to prevent 8018000a
In a production environment, use the Advanced Agent Settings section of your BeyondTrust policy to deploy the exclusion consistently.
Add an entry for:
- Name: ManagedHookExclusions
- Value: C:\Windows\System32\wwahost.exe
Make sure this setting applies to both 32-bit and 64-bit configurations.
Microsoft / BeyondTrust: Their Response.
It appears that BeyondTrust is indeed aware of this issue, but the latest update released this morning didn’t resolve it. For now, BeyondTrust seems to have published a KB on how to deal with this issue.
BeyondTrust
The KB lists three possible workarounds:
- Change return code 3010 from “Soft Reboot” to “Success” in the Intune Win32 app
- Remove the app from ESP
- Exclude the
wwahostprocess from the PG Hook
We have already applied workaround 3 (Add An Exclusion), which is, by far, the most logical fix.
Looking at the other two… workaround 2 avoids the problem by not installing the BeyondTrust agent during ESP. Sure, that means wwahost won’t get broken, but it also means your security agent never gets installed. Not really a solution if you care about security.
Workaround 1 sounds weird, though.
The BeyondTrust agent doesn’t actually trigger a reboot. It just breaks wwahost. So changing the return code from 3010 to Success might clean up the ESP result, but it doesn’t really solve the underlying issue.
Microsoft
It’s obvious that we also passed our findings to the Microsoft team responsible for Enrollment. So we need to have a bit of patience.
Final Thoughts
If you are using (Avecto) BeyondTrust Endpoint Privilege Management and you are seeing unexpected Autopilot or ESP failures on Windows 11 24H2, it is worth checking for PGHook activity.
A crash in wwahost.exe during Autopilot is not random. It disrupts the ESP flow, leaves the device in a partially enrolled state, and ensures that the next login attempt fails with error code 8018000a.
Until Microsoft or BeyondTrust provides an update to address this behavior, excluding wwahost.exe from hook injection is currently the only effective workaround.
If you are preparing your environment for 24H2, keep this in mind, especially if you rely on Privilege Guard or similar tools that inject into core system processes.