If you’re seeing Windows Update error 0x80072ee7, your PC can’t resolve the Microsoft update servers’ names to IP addresses. In plain English: Windows can reach the internet, but the DNS lookup (the phonebook that translates names like download.windowsupdate.com to addresses) is failing. This guide explains why the 0x80072EE7 DNS error appears, how to verify the root cause, and the exact steps to fix it for Windows Update (and, often, Microsoft Store and Defender updates) without guesswork. We go beyond generic advice with reproducible tests, commands, and enterprise-specific notes.
Why it matters: unresolved update endpoints block security patches, driver updates, Store apps, and Defender signatures—leaving your system vulnerable. Follow along from quick checks to advanced diagnostics; you’ll likely resolve 0x80072ee7 in under an hour.
Understanding the Error
What 0x80072EE7 technically means
- Error name: WININET_E_NAME_NOT_RESOLVED (0x80072EE7)
- Meaning: The server name or address could not be resolved. DNS did not return an IP address for the hostname Windows Update is trying to use.
- Where it appears: Windows Update, Microsoft Store, Defender updates, activation, and sometimes Office updates—especially on networks with custom DNS, VPNs, proxies, or WSUS.
Typical scenarios that trigger 0x80072EE7
- Misconfigured DNS server (router/ISP or custom resolver) or intermittent DNS outage
- Incorrect proxy settings (WinHTTP or system proxy) or stale WPAD auto-config
- VPN or security software intercepting DNS or HTTPS
- Hosts file entries blocking Microsoft domains
- Group Policy/registry forcing WSUS server that’s unreachable or misnamed
- Corrupted TCP/IP stack, Winsock, or DNS Client cache
- Clock/time drift causing TLS failures that look like DNS problems
- Enterprise content filtering (e.g., Pi‑hole, ad blockers, DNS filtering) blocking update endpoints
- Rarely, damaged system files or broken Windows Update components
Quick Reference Table
| Cause | Symptom | Recommended Fix |
|—|—|—|
| Bad DNS servers or DNS outage | nslookup to Microsoft update hosts fails; browsing mostly works but updates don’t | Set reliable DNS (1.1.1.1/8.8.8.8), ipconfig /flushdns, Clear-DnsClientCache |
| Wrong proxy/WinHTTP proxy | netsh winhttp show proxy shows a proxy; updates fail; browser may work | netsh winhttp reset proxy; disable system proxy; disconnect VPN |
| Hosts file entries | Microsoft domains mapped to 0.0.0.0/127.0.0.1 | Clean hosts file (remove blocks), then flush DNS |
| WSUS policy misconfigured | Windows Update only tries intranet server; error persists on all networks | Remove UseWUServer policy (GP or registry), gpupdate, reboot |
| Corrupt TCP/IP/Winsock | Random name resolution/connectivity oddities | netsh winsock reset; netsh int ip reset; reboot |
| Time/date incorrect | TLS handshake errors; Store/Update fails | Sync time (w32time), correct time zone, enable Windows Time service |
| Update components corrupted | Windows Update error persists after DNS fixes | Reset SoftwareDistribution/Catroot2; re-register services |
| Security software filtering | Updates fail on VPN/corporate networks only | Disable/exclude filtering; whitelist Microsoft endpoints |
| Router/ISP blocking | All PCs on network fail updates | Change DNS in router/PC; contact ISP; test via mobile hotspot |
| System file corruption | DISM/SFC find issues | Run SFC, DISM; consider in-place repair install |
Common Causes
- DNS issues
- ISP DNS outages or buggy router DNS
- Encrypted DNS/DoH misconfiguration in browser/router that doesn’t apply to system services
- DNS filtering (Pi-hole, AdGuard Home) blocking Microsoft update domains
- Proxy/VPN
- Incorrect system proxy or WinHTTP proxy
- Stale PAC/WPAD auto-detection
- VPN client forcing DNS through unreachable resolvers
- Policy/WSUS
- UseWUServer is enabled but WSUS hostname cannot be resolved
- Old corporate policies lingering on repurposed devices
- Hosts file
- entries blocking Microsoft domains (e.g., windowsupdate.com, microsoft.com, tlu.dl.delivery.mp.microsoft.com)
- Network stack corruption
- Broken Winsock catalog or IP stack after malware, cleanup tools, or third-party network drivers
- Time service
- Significant clock drift causing certificate validation failures
- Security software/network filtering
- SSL inspection or DNS manipulation by security suites, captive portals, or enterprise gateways
- Windows Update component corruption
- Damaged SoftwareDistribution/Catroot2 stores, misregistered services
- System file corruption
- Underlying OS issues affecting networking and update services
Preliminary Checks
Before you change anything major, do these quick, safe steps.
-
Boot to Safe Mode with Networking
- Press Shift while selecting Restart > Troubleshoot > Advanced options > Startup Settings > Restart > press 5 for Safe Mode with Networking.
- Purpose: isolate third-party services/VPNs/security software that may interfere.
-
Back up important data
- Always recommended before registry edits or repair installs.
-
Check date, time, and time zone
- Settings > Time & language > Date & time > Sync now. Ensure the time zone is correct.
-
Run basic health checks
- Open an elevated Command Prompt.
Commands:
sfc /scannowDISM /Online /Cleanup-Image /RestoreHealth
chkdsk C: /scan
- If SFC or DISM reports repairs, reboot and test Windows Update again.
Step-by-Step Troubleshooting
Follow these from easiest to most targeted. Test Windows Update after each major step.
- Verify baseline internet and captive portal
- Try browsing to https://www.microsoft.com and http://www.msftconnecttest.com/redirect
- If the second URL redirects to a login page, sign in to the captive portal.
- If general internet is down, fix that first (router/ISP).
- Test DNS resolution to Microsoft update endpoints
-
Use Command Prompt:
nslookup download.windowsupdate.comnslookup fe2.update.microsoft.com
nslookup tlu.dl.delivery.mp.microsoft.com
-
Use PowerShell:
Resolve-DnsName download.windowsupdate.com
Resolve-DnsName fe2.update.microsoft.com
Resolve-DnsName tlu.dl.delivery.mp.microsoft.com -
If these fail (Non-existent domain/timeout), it’s a DNS issue. Proceed to step 3.
- Set reliable DNS servers and flush caches
-
Change adapter DNS to known-good resolvers:
- Cloudflare: 1.1.1.1 and 1.0.0.1
- Google: 8.8.8.8 and 8.8.4.4
- Quad9: 9.9.9.9 and 149.112.112.112
-
PowerShell (set for all adapters):
$adapters = Get-DnsClientServerAddress -AddressFamily IPv4
foreach ($a in $adapters) { Set-DnsClientServerAddress -InterfaceIndex $a.InterfaceIndex -ServerAddresses 1.1.1.1,1.0.0.1 } -
Then clear caches:
ipconfig /flushdns
PowerShell: Clear-DnsClientCache -
Re-test nslookup/Resolve-DnsName and Windows Update.
- Remove wrong proxies and disconnect VPNs
-
Check WinHTTP proxy (used by Windows Update):
netsh winhttp show proxy -
If anything is configured, reset it:
netsh winhttp reset proxy -
Also disable system proxy:
Settings > Network & Internet > Proxy > turn off “Use a proxy server.” -
Disconnect VPNs and close VPN clients; reboot and test again.
- Reset the network stack (Winsock/TCP-IP)
-
Command Prompt (Admin):
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns -
Reboot and test.
- Inspect and clean the hosts file
- Location: C:\Windows\System32\drivers\etc\hosts
- Open Notepad as Administrator > File > Open > navigate to the path above > set file type to All Files > open hosts.
- Remove any lines referencing microsoft.com, windowsupdate.com, microsoftonline.com, tlu.dl.delivery.mp.microsoft.com, update.microsoft.com, or similar—especially if mapped to 0.0.0.0 or 127.0.0.1.
- The default hosts file is essentially empty (only comments). Save, then:
ipconfig /flushdns
- Confirm required services are running
-
Open Services (services.msc) and ensure:
- DNS Client (Dnscache): Running, Automatic
- Background Intelligent Transfer Service (BITS): Running, Manual/Automatic (Delayed Start)
- Windows Update (wuauserv): Running, Manual (Trigger Start)
- Cryptographic Services (CryptSvc): Running, Automatic
-
If any are stopped, start them and set the startup type as above.
- Remove misconfigured WSUS settings (home users or ex-corporate PCs)
-
If this is a personal PC, it should not be forced to use WSUS. Check:
-
Local Group Policy Editor (if available): gpedit.msc
- Computer Configuration > Administrative Templates > Windows Components > Windows Update
- Turn off “Specify intranet Microsoft update service location” or set to Not Configured.
- Computer Configuration > Administrative Templates > Windows Components > Windows Update
-
Registry (when gpedit is not available):
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU -
To clear WSUS policy via registry:
reg delete “HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate” /f -
Then:
gpupdate /force
net stop wuauserv
net start wuauserv
-
-
Enterprise note: If you are on a corporate domain, don’t remove WSUS policy—contact IT. 0x80072ee7 could mean the WSUS server name can’t be resolved by your corporate DNS.
- Reset Windows Update components
-
Command Prompt (Admin):
net stop wuauserv
net stop bits
net stop cryptsvcren %systemroot%\SoftwareDistribution SoftwareDistribution.old
ren %systemroot%\System32\catroot2 catroot2.oldnet start cryptsvc
net start bits
net start wuauserv -
Optional: re-register DLLs (mostly legacy, but harmless):
regsvr32 /s wuapi.dll
regsvr32 /s wuaueng.dll
regsvr32 /s wups.dll
regsvr32 /s wups2.dll
regsvr32 /s wuwebv.dll
regsvr32 /s wucltux.dll
- Test connectivity to update endpoints and ports
-
PowerShell:
Test-NetConnection download.windowsupdate.com -Port 443
Test-NetConnection tlu.dl.delivery.mp.microsoft.com -Port 443 -
curl (Windows 10+):
curl -I https://download.windowsupdate.com -
Success indicates HTTPS connectivity is fine. If DNS is still failing, revisit steps 3 and 5 or try a different network (mobile hotspot) to rule out router/ISP.
- Turn off filtering that may block Microsoft
- Temporarily disable third-party firewalls/security suites and DNS filtering (Pi-hole/AdGuard).
- If using Pi-hole, whitelist the following examples:
- windowsupdate.microsoft.com
- update.microsoft.com
- download.windowsupdate.com
- tlu.dl.delivery.mp.microsoft.com
- *.dl.delivery.mp.microsoft.com
- fe2.update.microsoft.com
- *.microsoft.com
- On the PC, you can also reset Windows Defender Firewall:
netsh advfirewall reset
- Repair system files again and check CBS log if needed
-
If the problem persists after networking fixes, repeat:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth -
Review CBS.log for persistent corruption:
notepad C:\Windows\Logs\CBS\CBS.log
- Fix Microsoft Store-related 0x80072ee7 (if Store is also affected)
-
Reset Store cache:
wsreset.exe -
Or via Settings > Apps > Installed apps > Microsoft Store > Advanced options > Reset.
-
Verify time/date and proxy/DNS settings as above—Store uses the same underlying networking stack.
- As a last resort: In-place repair upgrade
- Download the latest Windows ISO (from Microsoft).
- Run setup.exe > choose Keep personal files and apps.
- This refreshes Windows while preserving data and most apps, repairing system components that could affect Update.
Diagnostic Logs (instead of minidumps)
0x80072ee7 is not a BSOD, so minidump analysis does not apply. Use these built-in logs instead:
-
WindowsUpdate log
- PowerShell:
Get-WindowsUpdateLog - This generates a readable WindowsUpdate.log on your desktop. Search for NameResolution, WININET_E_NAME_NOT_RESOLVED, or specific hostnames.
- PowerShell:
-
Event Viewer
- Applications and Services Logs > Microsoft > Windows >
- WindowsUpdateClient > Operational
- Windows > Windows Networking Diagnostics
- DNS Client Events
- WinHTTP Web Proxy Auto-Discovery Service
- Look for DNS failure events, proxy discovery issues, or repeated retries.
- Applications and Services Logs > Microsoft > Windows >
-
Netsh trace (captures network diagnostics)
- Command Prompt (Admin):
netsh trace start capture=yes scenario=internetclient
Reproduce the update check
netsh trace stop - Analyze the generated ETL with Microsoft Message Analyzer (legacy) or Wireshark (with ETW support) to confirm DNS failures/timeouts.
- Command Prompt (Admin):
-
Name resolution testing in PowerShell
- Resolve-DnsName
-Server -NoHostsFile - Helps bypass hosts file and test specific DNS servers directly.
- Resolve-DnsName
Advanced Diagnostics
Use these when the basics don’t identify the problem.
-
Test alternate networks
- Connect the PC to a mobile hotspot. If updates work, the issue is your router/ISP DNS or network filtering.
-
Check WinHTTP vs. WinINET proxy mismatch
- Browsers often use WinINET proxy settings; Windows Update uses WinHTTP. Ensure both are clear if no proxy is required.
- Commands:
netsh winhttp show proxy
netsh winhttp reset proxy
-
Inspect DNS client configuration deeply
- PowerShell:
Get-DnsClient
Get-DnsClientServerAddress
Get-DnsClientGlobalSetting - Confirm no unusual suffixes or connection-specific DNS that point to unreachable servers.
- PowerShell:
-
Disable DNS over HTTPS in your browser/router (temporarily)
- DoH can mask DNS issues in browsers while system services still fail. Ensure the system-wide resolver is healthy.
-
Review Group Policy for network/proxy settings
- gpedit.msc:
- Computer Configuration > Administrative Templates > Network > Network Isolation
- Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Connections > “Disable changing proxy settings”
- Computer Configuration > Administrative Templates > Network > Network Connections > “Prohibit use of Internet Connection Sharing” (rare interactions)
- gpedit.msc:
-
Event Viewer deep dive
- DNS Client Events: Event IDs 1014 (Name resolution for the name
timed out). - WindowsUpdateClient: event clues around failed endpoint access and retry logic.
- DNS Client Events: Event IDs 1014 (Name resolution for the name
-
Packet capture
- Use Wireshark to capture UDP/TCP to port 53 and HTTPS to 443 while checking for DNS queries and responses for Microsoft domains. Look for NXDOMAIN or SERVFAIL.
Post-Fix Checklist
- Run Windows Update
- Settings > Windows Update > Check for updates. Confirm downloads and installs proceed without 0x80072ee7.
- Event Viewer cleanliness
- No recurring DNS Client event 1014 or WindowsUpdateClient errors during the update check.
- Re-run health checks (optional)
- sfc /scannow and DISM to ensure stability.
- Confirm Store and Defender updates
- Open Microsoft Store > Library > Get updates.
- Windows Security > Virus & threat protection > Check for updates.
- Re-enable security software
- If you disabled firewalls/VPNs during troubleshooting, re-enable and confirm updates still work. If not, add exclusions/whitelists.
When to Seek Professional Help
- Enterprise/Domain-joined devices
- If Group Policy enforces WSUS or proxy settings, contact your IT department. Do not remove corporate policies.
- Router/ISP issues
- If multiple devices on your network can’t update Windows and DNS tests fail, contact your ISP or replace the router. Consider using trusted public DNS.
- Persistent DNS failures
- If alternate networks work but your main network doesn’t, engage a network professional to inspect DNS, proxy, and firewall configurations.
- Suspected malware or rootkits
- If hosts file or network stack repeatedly breaks, run offline antivirus scans or consult a technician.
- Hardware/network adapter issues
- Consistent failures tied to one NIC may require driver updates or replacement hardware.
Prevention Tips
- Use reliable DNS
- Prefer reputable providers (Cloudflare, Google, Quad9) or a well-maintained local resolver.
- Avoid aggressive “tweaking” tools
- Tools that modify Winsock, proxy, or hosts can cause outages. Document changes you make so you can revert.
- Keep time in sync
- Ensure Windows Time is running and time zone is correct to prevent TLS issues.
- Maintain driver hygiene
- Keep NIC drivers updated from the OEM. Avoid problematic NDIS filter drivers unless necessary.
- Regular backups and restore points
- Protect yourself from corruption and enable fast recovery.
- Monitor network gear
- Keep router firmware updated. Reboot occasionally. Replace aging hardware.
- Whitelist Microsoft update endpoints
- If you run DNS filtering, whitelist Microsoft update domains to prevent accidental blocking.
Conclusion
Windows Update error 0x80072ee7 almost always traces back to DNS or related network plumbing: a bad resolver, a wrong proxy, a blocked endpoint, or a corrupted stack. By verifying name resolution, switching to dependable DNS, clearing proxies, resetting Winsock/IP, cleaning the hosts file, and, if needed, resetting Windows Update components or WSUS policies, you can restore updates quickly and safely. Stay methodical, test after each step, and you’ll resolve most 0x80072ee7 cases without wiping your PC.
FAQ
What does Windows Update error 0x80072ee7 mean?
It means “The server name or address could not be resolved.” In short, DNS failed to map an update hostname (like download.windowsupdate.com) to an IP address. Fixing DNS, proxies, or hosts entries usually resolves it.
Can a wrong proxy cause 0x80072ee7 even if my browser works?
Yes. Windows Update uses WinHTTP, which may have a different proxy configuration than your browser (WinINET). Run netsh winhttp show proxy and netsh winhttp reset proxy to clear it.
Should I disable IPv6 to fix 0x80072ee7?
Only as a temporary test. Some networks with broken IPv6 DNS can cause issues. You can disable IPv6 on your adapter to test, but the long-term fix is correcting DNS. Modern Windows prefers IPv6 when available.
I’m on a work PC—how do I fix this without breaking policy?
Do not remove Group Policies. Contact IT. Error 0x80072ee7 on corporate devices often indicates a WSUS or proxy/DNS issue that your admin must correct.
Will resetting Windows Update components delete my data?
No. Renaming SoftwareDistribution and Catroot2 only resets update caches and catalogs. Your personal files and apps remain intact. If you perform an in-place repair upgrade, choose “Keep personal files and apps” to preserve data.
You’ve got this. Work through the checks, verify DNS and proxy settings, reset the network stack, and updates should flow again. If you get stuck, testing on a different network or asking your network/IT provider often quickly pinpoints the culprit.