If Windows Update keeps asking you to accept license terms and then loops back without installing anything, you may be dealing with error 0x8024002E (WU_E_EULAS_DECLINED). This is a Windows Update–specific error that indicates the End User License Agreement (EULA) for an update wasn’t accepted or couldn’t be recorded. Left unresolved, it can block security patches, cumulative updates, Microsoft Store app updates, and even feature upgrades. This guide goes well beyond generic advice to give you a step-by-step, deeply technical path to resolve the stuck consent loop in both home and enterprise environments (WSUS/SCCM/Intune), with safe recovery options and prevention tips.
Understanding the Error (H2)
What 0x8024002E (WU_E_EULAS_DECLINED) means (H3)
In plain language, Windows Update is telling you: “An update needs its license terms accepted, but they were declined or not registered.” This may happen because:
- You actually clicked “Decline” (intentional or accidental).
- The EULA prompt could not be shown due to UI corruption or policy.
- You’re in a managed environment (WSUS/ConfigMgr/Intune) where license terms must be accepted by an admin on the server first.
- A silent install attempted without the correct switches to accept terms.
- Windows Update components or the update database are corrupted and failing to record your acceptance.
Common scenarios where this appears (H3)
- Home/Pro PCs: The Settings app shows “Review and accept license terms” but accepting loops back to the same prompt (consent loop).
- Microsoft Store updates fail with 0x8024002E (Store leverages Windows Update components).
- Devices joined to a domain using WSUS/SCCM: Updates fail if the WSUS admin hasn’t accepted the license terms in the console or if deployment settings prevent EULA capture.
- Scripted installs using .msu packages via WUSA or PowerShell without the right switches (e.g., not using -AcceptAll or /quiet when required).
Quick Reference Table (H2)
| Cause | Symptom | Recommended Fix |
|---|---|---|
| Update requires EULA acceptance but UI can’t record it | “Accept license terms” loops; error 0x8024002E | Reset Windows Update components; use PowerShell PSWindowsUpdate with -AcceptAll; run WUSA with /quiet |
| WSUS/ConfigMgr license terms not accepted by admin | Managed clients fail to install approved updates | In WSUS, accept license terms in the console and re-approve; in ConfigMgr, verify deployment package and SUP health |
| Corrupt Windows Update datastore or catroot | Repeated prompts or stalled downloads | Stop WU services; clear SoftwareDistribution and catroot2; re-register WU components |
| Group Policy blocks UI/Internet WU | No EULA UI, or Settings app can’t complete consent | Review and adjust Windows Update GPOs; remove “Remove access to all Windows Update features” and “Do not connect to any Windows Update Internet locations” if not intended |
| Silent installs without EULA acceptance switches | WUSA or scripts fail with 0x8024002E | Use WUSA /quiet or PSWindowsUpdate -AcceptAll -Install |
| Store-specific cache corruption | Store app updates throw 0x8024002E | Run WSReset; sign out/in of Microsoft Store; reset Store app and update again |
Common Causes (H2)
- User interface loop or glitch
- The Windows Update UI fails to record the acceptance and re-prompts.
- Windows Update component corruption
- Damaged SoftwareDistribution or Catroot2 folders, or broken wuauserv/BITS/CryptSvc state.
- Group Policy/registry configuration
- Policies that suppress update UI or block connection to Microsoft endpoints.
- WSUS/ConfigMgr/Intune misconfiguration
- WSUS admin has not accepted license terms; approvals/downloads incomplete.
- SCCM deployment package or Software Update Point (SUP) health issues.
- Scripted/silent deployment switches
- WUSA or third-party tools missing “accept EULA” flags.
- PSWindowsUpdate used without -AcceptAll.
- Microsoft Store cache issues
- Store uses Windows Update components; cache corruption can cause EULA errors.
- System file corruption
- Damaged servicing stack or components handled by SFC/DISM.
- Network/proxy interference
- Corporate proxies or WinHTTP proxy misconfiguration blocking metadata.
Preliminary Checks (H2)
Boot into Safe Mode (H3)
If updates are stuck in a loop and you suspect UI or third-party interference:
- Windows 10/11:
- Hold Shift and click Restart from the Start menu (Power button menu).
- Troubleshoot > Advanced options > Startup Settings > Restart.
- Press 4 for Safe Mode or 5 for Safe Mode with Networking.
- Alternatively: Press Windows+R, type msconfig, go to Boot, check Safe boot (Minimal), apply, restart. Remember to undo this later.
Back up important data (H3)
Before deep system changes:
- Copy critical files to an external drive or cloud.
- Create a System Restore Point (Control Panel > System > System Protection > Create).
- If available, create a full system image backup.
Run basic health checks (H3)
Open an elevated Command Prompt (Run as administrator) and run:
- Check disk health (schedule if C: is in use):
chkdsk C: /scan
or to schedule on reboot:
chkdsk C: /f - System File Checker:
sfc /scannow - Deployment Image Servicing and Management:
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
If SFC/DISM report repairs, reboot and test Windows Update again.
Step-by-Step Troubleshooting (H2)
- Confirm basic prerequisites (H3)
- Sign in with an account that has local Administrator rights.
- Ensure date, time, and time zone are correct.
- Temporarily disable third-party antivirus or endpoint protection (if allowed) to rule out UI blocking—re-enable after testing.
- Verify key services are running:
- Background Intelligent Transfer Service (BITS)
- Windows Update (wuauserv)
- Cryptographic Services (CryptSvc)
Use:
sc query bits
sc query wuauserv
sc query cryptsvc
- Reset Windows Update components (H3)
This clears corrupt caches and re-registers components. In an elevated Command Prompt:
-
Stop services:
net stop wuauserv
net stop bits
net stop cryptsvc
net stop trustedinstaller -
Rename SoftwareDistribution and Catroot2:
ren %systemroot%\SoftwareDistribution SoftwareDistribution.old
ren %systemroot%\System32\catroot2 catroot2.old -
Re-register core Windows Update DLLs:
regsvr32 /s wuapi.dll
regsvr32 /s wuaueng.dll
regsvr32 /s wups.dll
regsvr32 /s wups2.dll
regsvr32 /s wuwebv.dll
regsvr32 /s wucltux.dll
regsvr32 /s atl.dll
regsvr32 /s urlmon.dll
regsvr32 /s msxml3.dll
regsvr32 /s qmgr.dll
regsvr32 /s qmgrprxy.dll
regsvr32 /s cryptdlg.dll -
Reset WinHTTP proxy (if using direct internet):
netsh winhttp reset proxy -
Start services:
net start trustedinstaller
net start cryptsvc
net start bits
net start wuauserv
Reboot and try Windows Update again. If the EULA prompt reappears, continue.
- Accept license terms via PowerShell (H3)
Sometimes the Settings app UI is the problem. Using the PSWindowsUpdate module can bypass the loop by explicitly accepting terms.
- Open PowerShell as Administrator and run:
Install-Module PSWindowsUpdate -Scope AllUsers -Force
Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force
Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -Install -Verbose
The -AcceptAll flag automatically accepts license terms for available updates. Reboot if prompted, then recheck Windows Update.
- Use WUSA with correct switches for specific KBs (H3)
If you have a .msu package for a failing update:
- In an elevated Command Prompt:
wusa C:\Path\To\Update.msu /quiet /norestart
The /quiet switch installs silently and typically accepts EULAs automatically. After installation, restart as needed.
- Review and adjust relevant Group Policies (H3)
On managed or previously managed devices, policies can block EULA UI or Microsoft endpoints.
- Run:
gpedit.msc
Check:
-
Computer Configuration > Administrative Templates > Windows Components > Windows Update:
- Do not connect to any Windows Update Internet locations: Set to Not Configured unless required.
- Configure Automatic Updates: Ensure it meets your intended behavior (try Not Configured for testing).
- Display options for update notifications: Allow notifications as needed.
-
User Configuration > Administrative Templates > Windows Components > Windows Update:
- Remove access to use all Windows Update features: Not Configured.
After changes:
gpupdate /force
Reboot and test again.
- Fix Microsoft Store–linked consent loops (H3)
If the 0x8024002E error occurs during Microsoft Store app updates:
- Reset Store cache:
wsreset.exe - Sign out and sign back in to the Microsoft Store.
- If still failing:
- Settings > Apps > Installed apps > Microsoft Store > Advanced options > Reset.
- Reopen Store and try updates again.
- WSUS: Accept license terms and re-approve (Enterprise) (H3)
For domain-joined clients using WSUS:
- On the WSUS server, open the WSUS Console.
- Check if the updates in question require license terms acceptance. When you first approve certain updates, WSUS prompts you to accept license terms. If skipped, clients can fail with WU_E_EULAS_DECLINED.
- For each affected update:
- Right-click > Approve, review License Terms, click I Accept.
- Ensure the update files are downloaded (check the “Files” tab or download status).
- Run WSUS synchronization if needed and verify no server-side errors.
- On clients, force detection:
wuauclt /detectnow
usoclient startscan
(Note: usoclient works on Win10/11; may require admin and interactive session.) - Review C:\Windows\WindowsUpdate.log (generated with Get-WindowsUpdateLog) for resolution.
- ConfigMgr (SCCM/MECM) client checks (Enterprise) (H3)
- On clients, check logs:
- C:\Windows\CCM\Logs\WUAHandler.log
- UpdatesDeployment.log
- WindowsUpdate.log (reconstructed)
- In the console:
- Verify Software Update Point health and sync status.
- Ensure deployment packages are distributed and content is available.
- Recreate affected deployments if metadata is stale.
- If a specific update is failing, redistribute its content and redeploy.
- Ensure SUP and WSUS integration are healthy (WSUS cleanup, SUP sync cycles).
- Repair corrupted servicing stack or components (H3)
If 0x8024002E persists alongside other update errors, repair Windows components:
- SFC and DISM (again):
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
If still stuck, perform an In-place Upgrade Repair:
- Download the latest Windows ISO from Microsoft.
- Mount ISO, run setup.exe.
- Choose Keep personal files and apps.
This refreshes Windows Update components without wiping data.
- Network/proxy/certificate sanity check (H3)
- If using a proxy:
netsh winhttp show proxy
If incorrect, reset or set correctly:
netsh winhttp reset proxy - Ensure TLS 1.2 is enabled and outbound access to Microsoft Update endpoints is allowed.
- Verify system date/time and root certificates are current.
- About minidumps (and what to collect instead) (H3)
This error is not a BSOD and won’t generate a minidump in C:\Windows\Minidump. Instead, collect and review:
- Reconstructed Windows Update logs:
PowerShell (Admin):
Get-WindowsUpdateLog
This creates WindowsUpdate.log on your Desktop. - Event Viewer:
Event Viewer > Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational
Look for 0x8024002E or “EULA” entries. - CBS logs:
C:\Windows\Logs\CBS\CBS.log (useful if component store causes failures). - Enterprise:
SCCM logs (WUAHandler.log, UpdatesDeployment.log), WSUS console status.
If you still want a driver/module perspective (e.g., if crashes accompany this issue), tools like WinDbg and BlueScreenView apply to BSOD analysis, not to WU_E_EULAS_DECLINED itself.
Advanced Diagnostics (H2)
Use Event Viewer to pinpoint the failure (H3)
- Navigate to Windows Update Client Operational log:
- Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational
- Filter by Event IDs commonly tied to update workflow (e.g., 19, 20, 31, 43) and search for 0x8024002E or “EULA.”
- Cross-reference timestamps with WindowsUpdate.log for alignment.
Rebuild Windows Update metadata more aggressively (H3)
- After clearing SoftwareDistribution, also reset Catroot2 (as shown earlier).
- Remove pending.xml if present and stuck (advanced; only if servicing stack indicates a stuck transaction). Make a backup first. Use with caution.
Re-register app provisioning (Store-related) (H3)
If Store updates are implicated and WSReset didn’t help:
PowerShell (Admin):
Get-AppxPackage -AllUsers Microsoft.WindowsStore | Reset-AppxPackage
Get-AppxPackage -AllUsers Microsoft.WindowsStore | Add-AppxPackage -Register -DisableDevelopmentMode “$($_.InstallLocation)\AppxManifest.xml”
Note: On modern Windows, Reset-AppxPackage is preferred; reregister only if needed.
Driver Verifier note (H3)
Driver Verifier is not applicable to this error. Use it only for diagnosing kernel-mode crashes. Enabling it unnecessarily can destabilize systems.
Post-Fix Checklist (H2)
- Run Windows Update
- Confirm no “Review and accept license terms” loop.
- Verify updates download and install successfully.
- Check Event Viewer
- WindowsUpdateClient Operational log is clean—no 0x8024002E entries after the fix.
- Validate system health
- Re-run sfc /scannow (no violations).
- DISM /Online /Cleanup-Image /CheckHealth (reports healthy).
- Microsoft Store
- Open Store > Library > Get updates and ensure apps update cleanly.
- Enterprise verification
- WSUS: Updates are approved with license terms accepted; synchronization green.
- ConfigMgr: WUAHandler.log no longer shows EULA-related errors; deployments succeed.
When to Seek Professional Help (H2)
- Persistent 0x8024002E after full component reset, SFC/DISM repairs, and EULA acceptance via PowerShell/WUSA.
- WSUS database corruption, synchronization failures, or content download failures on the server.
- SCCM SUP or policy distribution issues beyond client-side fixes.
- Repeated Store failures tied to user profile corruption (may require profile repair/migration).
- Suspected disk or hardware faults indicated by CHKDSK or SMART diagnostics.
IT admins may need to perform WSUS cleanup (server cleanup wizard, reindexing), SUP reinstallation, or in severe cases rebuild WSUS/SUP infrastructure.
Prevention Tips (H2)
- Keep Windows Update components healthy
- Regularly install servicing stack updates (SSU) and cumulative updates.
- Avoid abrupt power-offs during updates.
- Use proper switches for scripted installs
- WUSA: include /quiet for unattended installs requiring EULA acceptance.
- PSWindowsUpdate: use -AcceptAll with -Install.
- Maintain clear Group Policy configuration
- Don’t block Microsoft Update endpoints unless you fully manage updates via WSUS.
- Document and audit Windows Update–related GPOs.
- WSUS/ConfigMgr hygiene
- Accept license terms during approvals.
- Run WSUS cleanup routinely; monitor synchronization and content distribution.
- Backups and monitoring
- Create restore points and image backups before major updates.
- Monitor Event Viewer and WindowsUpdate.log for early signs of trouble.
Conclusion (H2)
Error 0x8024002E (WU_E_EULAS_DECLINED) means Windows couldn’t confirm acceptance of license terms for one or more updates. In most cases, you can fix the stuck consent loop by resetting Windows Update components, accepting EULAs through PowerShell or WUSA, checking Group Policies, and—if you’re in a managed environment—ensuring your WSUS/SCCM servers have license terms accepted and content properly synchronized. With the steps above, you should be able to restore normal update behavior quickly and safely. Don’t be discouraged—most Windows Update errors, including this one, are solvable with a methodical approach.
FAQ Section (H2)
Is 0x8024002E a BSOD stop code?
No. It’s a Windows Update error (WU_E_EULAS_DECLINED), not a blue screen. It indicates license terms for an update weren’t accepted or recorded.
Will resetting SoftwareDistribution delete my updates?
It deletes the local update cache and history view, but not the installed updates themselves. Windows will rebuild metadata and re-scan. Installed updates remain installed.
How can I accept EULAs silently for scripted installs?
Use the right switches:
- WUSA (for .msu): wusa Update.msu /quiet /norestart
- PSWindowsUpdate: Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -Install
These accept license terms automatically during unattended installation.
I’m using WSUS—why are clients still failing with 0x8024002E?
The WSUS admin likely hasn’t accepted the license terms for one or more updates in the console, or the content hasn’t downloaded. Open WSUS, approve the updates, accept terms where prompted, ensure files are downloaded, and resync. On clients, force a scan (usoclient startscan or wuauclt /detectnow).
Microsoft Store shows the same error—what should I do?
Run WSReset, sign out/in of the Store, and try again. If needed, reset the Store app from Settings > Apps. Because Store uses Windows Update components, also consider resetting Windows Update (clear SoftwareDistribution and Catroot2) and running SFC/DISM.
You’ve got this. Follow the steps in order, and you’ll break out of the EULA consent loop and get updates flowing again. If you hit a wall, don’t hesitate to escalate—most stubborn cases are resolved by a careful review of policies and server-side approvals or by performing an in-place repair.
