Fix Autopilot.dll WIL Error 0x80070491 in Event Viewer

If you keep seeing Autopilot.dll WIL error was reported. HRESULT: 0x80070491 in Event Viewer, do not assume you found the root cause of a broken Intune or Autopilot deployment. In many environments this event shows up for years on otherwise usable Windows devices. The real job is to decide whether you are looking at background Autopilot noise or evidence tied to an active enrollment, pre-provisioning, reset, or device reuse problem.

That distinction matters because admins lose hours on the wrong fix path here. They start repairing Windows images, clearing logs, or reinstalling management components when the actual issue is stale device state, a missing Enrollment Status Page assignment, a reused pre-provisioned device record, or a separate enrollment failure that only happens to sit next to the 0x80070491 event.

Microsoft Learn gives you the right clues even though it does not publish a dedicated support article for this exact HRESULT. The current Autopilot troubleshooting FAQ tells admins to use the Autopilot diagnostics page and the ModernDeployment-Diagnostics-Provider > Autopilot log. The pre-provisioning article says an Enrollment Status Page (ESP) profile must be targeted to the device. The known issues page warns that reused self-deploying and pre-provisioned devices can fail unless old records are deleted. Microsoft Q&A threads from 2023 and again in 2025 show the same Autopilot.dll WIL error was reported message repeating over time, which is a strong sign that the event by itself is not a complete diagnosis.

This runbook is for Desktop Engineers and Intune admins who need to decide whether 0x80070491 is harmless telemetry noise or part of a real Autopilot failure.

Quick Fix checklist

Use this order before you rebuild the endpoint:

Confirm whether the device currently has an Autopilot, ESP, or Intune enrollment problem that users can actually reproduce.
Open Event Viewer > Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot and check what happened immediately before and after the 0x80070491 entries.
If the device is in OOBE, pre-provisioning, Autopilot Reset, or Enrollment Status Page, enable and open the Autopilot diagnostics page with CTRL + SHIFT + D if available.
Check whether the device was recently reused, reset, resealed, or re-imported. Microsoft documents record reuse issues for self-deploying and pre-provisioned devices.
Verify that the intended Autopilot deployment profile and ESP profile are both targeted to the device.
If this is a pre-provisioned device, confirm the Intune-side records were deleted before reuse. Microsoft says these devices cannot automatically re-enroll after the initial deployment without cleanup.
Collect mdmdiagnosticstool.exe output before retrying.
Treat the event as secondary unless you can tie it to a real enrollment symptom such as ESP timeout, MDM registration failure, or profile mismatch.

That sequence keeps you from escalating a noisy event log while missing the actual enrollment break.

What this error usually means in practice

The hard part with Autopilot.dll WIL error was reported is not finding the text. The hard part is proving whether it matters.

Two facts are worth keeping in view:

Microsoft Q&A threads from both 2023 and 2025 show admins and users seeing the same message repeatedly over long periods.
Microsoft Learn’s official Autopilot docs focus on surrounding evidence such as diagnostics, event IDs, profile targeting, pre-provision prerequisites, and reuse state. They do not point to one universal hotfix for 0x80070491 alone.

That usually means one of three situations is true:

1. It is background noise and not the outage

This is the most common case. The event appears in the Autopilot log, but the device is already enrolled, users can sign in, policy sync works, and there is no active Autopilot deployment in progress. In that situation, clearing the log does not fix anything because nothing functional is actually broken.

The device has a genuine Autopilot problem, but 0x80070491 is only one nearby event. The actual root cause is more likely to be:

missing or delayed profile assignment
ESP targeting issues
a reused device record after pre-provisioning or self-deploying mode
stale Intune or Microsoft Entra device objects
a separate MDM enrollment failure
TPM attestation or device readiness issues during pre-provisioning

This is why reading only the one error line leads to bad remediation.

3. It is tied to a device lifecycle edge case

Microsoft’s current documentation still calls out lifecycle traps around Autopilot reuse. Pre-provisioned devices do not just roll cleanly into another enrollment. Devices used in self-deploying or pre-provisioned mode may need the old Intune-created device record removed first. If you see 0x80070491 on a device that was recently wiped, resealed, reset, or moved between test cycles, suspect stale service-side state before you suspect Windows corruption.

Where to check before you touch the image

Start with evidence that can confirm or rule out a real Autopilot incident.

Event Viewer path

Microsoft’s Autopilot FAQ tells you exactly where to look:

Event Viewer > Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot

Do not stop at the 0x80070491 line. Review the surrounding events at the same timestamp and ask:

Was the device in OOBE, ESP, pre-provisioning, or Autopilot Reset?
Do you also see profile assignment, TPM attestation, serial number mismatch, or enrollment failures?
Did the event happen right after a device reset or reuse attempt?
Is the device otherwise completing policy sync and user sign-in?

Autopilot diagnostics page

If the device is still in an active Autopilot flow, enable the diagnostics page in the ESP profile and use CTRL + SHIFT + D to open it. Microsoft says this page can expose more useful deployment details than the single Event Viewer message.

Use it to confirm:

profile assignment state
device preparation progress
join state
app and policy phase timing
visible deployment failures that map to the user’s actual symptom

MDM diagnostics package

Before another retry, collect diagnostics:

mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"

That gives you a CAB or ZIP artifact you can compare across good and bad devices. If you are supporting a batch of laptops, compare one failed unit and one successful unit from the same Autopilot profile.

Intune and Microsoft Entra object state

If the device was reused, verify the service-side records and not just the local machine:

Intune admin center > Devices > Windows > Enrollment > Windows Autopilot > Devices

Also compare the managed device and Microsoft Entra device object. Microsoft’s stale device guidance is still relevant here. Disable or remove stale objects carefully and avoid deleting the active production object for a device that is still in use.

Fix workflow when 0x80070491 happens during a real Autopilot problem

If users are blocked and the error lines up with an actual deployment failure, work this sequence.

Fix 1: Prove the device has the right profile chain

For any device still entering Autopilot, confirm:

the Autopilot record exists for the correct serial number
the right deployment profile is assigned
the intended Enrollment Status Page profile is also assigned
any dynamic group used for assignment has finished evaluating

Microsoft’s pre-provisioning guidance is explicit that ESP must be targeted to the device. If you skip that check, you can waste time on the event log while the real failure is assignment scope.

Fix 2: Handle reused pre-provisioned devices properly

This is one of the highest-value checks for this error pattern.

Microsoft’s pre-provisioning article says a device cannot automatically re-enroll through Windows Autopilot after an initial pre-provisioned deployment. The current troubleshooting FAQ also says reused self-deploying and pre-provisioned devices are affected by a change in the Intune experience and the old device record created by Intune must be deleted.

So if this device was:

pre-provisioned and then reset
resealed for another user
used on a bench repeatedly
moved through test and production cycles

then verify cleanup first. Do not just wipe it again.

Practical workflow:

Record the serial number and current Autopilot profile assignment.
Check for the existing Autopilot device record.
Check for the Intune managed device record tied to the previous run.
Check for stale Microsoft Entra device objects.
Remove only the stale records you can prove belong to the earlier deployment.
Wait for the cleanup to settle.
Retry on one pilot device.

That is much more likely to resolve the incident than clearing Event Viewer.

Fix 3: Review known issues that can mimic the same symptom

Microsoft’s known issues page keeps changing, and that matters. Current examples include TPM attestation failures on some TPM platforms and ESP behavior changes after Autopilot Reset.

If your 0x80070491 case appears during pre-provisioning or self-deploying mode, compare it against the current known issues page before you declare a one-off tenant problem. This is especially important when multiple new devices from the same hardware family start failing at once.

Fix 4: Validate the enrollment path, not just the device

If the device is failing with real enrollment symptoms, pull in the broader Intune enrollment guidance too. Microsoft still documents separate Windows enrollment failures such as:

device already enrolled state
MDM enrollment restrictions
ESP timeouts
Autopilot enrollment failures with their own HRESULT values

A useful field test is to ask whether the same user or same device succeeds on a clean pilot profile or different network path. If yes, your issue is likely in assignment, restrictions, or lifecycle state rather than a broken OS image.

PowerShell checks that help in the field

Use a few low-risk checks before you reimage anything.

Check join and registration state

dsregcmd /status

Review whether the device already shows the expected Entra join state and whether the current object identity matches the record you think should be enrolled.

Get-WinEvent -LogName 'Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot' -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Do not search for 0x80070491 only. Compare the last several events as a sequence.

Capture current enrollment evidence

mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"

When you escalate, attach the package and the exact timestamp of the Autopilot.dll WIL error was reported event.

Limitations and caveats

You should not promise one universal fix for this HRESULT. Microsoft has not published a dedicated Learn article that says 0x80070491 always means one specific failure. The evidence available today points the other way: the same event can appear on working systems, and real Autopilot incidents still need to be diagnosed through profile assignment, diagnostics, device lifecycle state, and known issues.

You also should not mass-delete Autopilot or Entra objects because one event viewer line looked suspicious. Microsoft’s stale device guidance recommends planning cleanup carefully and using a grace period where appropriate, because deleting the wrong object can create a second outage.

Finally, avoid the trap of calling every repeated Autopilot.dll WIL error was reported event a Windows corruption problem. If the device is already healthy from the user’s point of view, document the noise and move on. If the device is actually blocked, use the event as a clue, not the conclusion.

Conclusion

Autopilot.dll WIL error was reported. HRESULT: 0x80070491 is usually valuable only when you place it in context. On its own, it is often just noisy evidence that the Autopilot component logged something. In a real enterprise incident, the meaningful checks are profile targeting, ESP assignment, device reuse cleanup, known issues, and the diagnostics package that shows what the device was doing at the time.

If you tie 0x80070491 to a real Autopilot outage, follow the lifecycle checks first. If you cannot tie it to an outage, stop treating the event as the problem. That shift alone saves a lot of wasted rebuilds.