Nobody has responded to this, but I’m just reporting back to say the problem has resolved itself. Beginning Thursday, November 30, I disabled IPv6 on the Netgear and left it that way in order to let Windows Update run normally. Beginning Wednesday, December 6 I re-enabled IPv6 in order to see if the problem was still present. Windows Update has worked normally ever since.
I’m pretty sure this was not a home network issue, even though it might sound like one given the workarounds I reported. I believe this because neither the appearance or disappearance of the issue corresponds to home network changes. The problem seems to be rooted in some external factor. My network experiments may have provided a workaround simply because they resulted in a different IP addresses. (i.e. IPv6 vs IPv4 when toggling IPv6 on and off, and two different IPv6 addresses when switching between the Netgear and the PACE). The different IPs may have in turn affected the server choice or the route.
I believe this is just a reminder of how fundamentally temperamental and unreliable the internet really is. It’s next to impossible to diagnose a failure or determine responsibility. Best not to become too dependent.
Beginning Tuesday November 21, I have been having trouble with Windows Update endlessly (almost) checking for updates. Along with this, most shutdowns hang on a “Task Host Window” that is in turn hung on Windows Update. This behavior began on the same date on three different machines, all running Windows 10 1709. My internet connection seems normal in all other respects.
In “Windows Update” settings, I usually see “Checking for Updates”, but may occasionally see a “Retry”, button or even a normal-looking “Check for Updates” button. However, in the latter case, the date of the last check will be an old date that pre-dates the most recent checks. On very rare occasions a check for updates will complete normally, showing that there is some residual connectivity. But, most of the time it’s hung.
Before going further, I need to explain a little about my network setup. My ISP is AT&T Uverse, and I have an AT&T supplied modem/router (a PACE 5268AC) that I have to use. I run my own router (a Netgear Nighthawk) cascaded behind it. The PACE does not have a bridge mode, so I am double NATing on IPv4. I have IPv6 enabled on both the PACE and Netgear, and the setup works fine on both IPv4 and IPv6 enabled sites. I have been running this setup for about two months. (I have run a similar setup, but with a Linksys router instead of the Netgear, for about two years.) Until November 21, I have had no problems with Windows Update.
I have discovered that if I connect any of the computers directly to the PACE, Windows Update immediately works normally on that computer. Furthermore, if I reconnect the computer behind the Netgear it continues to work normally! But it only works behind the Netgear for 24 hours, and then the same problem returns. This 24-hour lag until the failure returns is apparently due to information cached by Windows Update. If I stop the wuauserv process, (net stop wuauserv), erase everything under “Windows\Software distribution” and then restart wuauserv (net start wuauserv) then the failure shows up immediately.
The most obvious difference between the PACE setup and the Netgear is that the PACE uses AT&T DNS (and can’t be changed) and I used Google DNS (IPv4 and IPv6) on the Netgear. My initial theory was that AT&T was playing some games with DNS in order to redirect Windows Update traffic to preferred servers. I hoped to fix the problem simply by changing the Netgear to use AT&T’s DNS. But this didn’t work. I also tried to see if I could break the PACE, by using Google DNS when the PC is connected to the PACE. (I can’t change DNS on the PACE, so I changed DNS on the computer for this experiment.) But Windows Update continued to work normally in this mode.
The other thing I discovered, is that if I disable IPv6 on the Netgear, Windows Update works normally. If I re-enable IPv6 on the Netgear, Windows Update continues to work normally for 24 hours unless I reinitialize it. I can accomplish the same thing by toggling IPv6 off and back on again on the PC.
Back to the PACE vs the Netgear, the only other obvious difference is that the PACE allocates both a DHCPv6 type address and a SLAAC type address to each client. With the Netgear, it’s one or the other, but not both. I have not been able to impact the Windows Update problem by playing with IPv6 settings, and there really aren’t many setting to play with on the Netgear. I could be a firewall issue, but there’s nothing to play with, and I probably wouldn’t know what I was doing anyway. My setup continues to work normally on both IPv4 and IPv6 sites, except for Windows Update.
I last updated the Netgear’s firmware about three weeks before the problem appeared, so while the Netgear may be part of the problem, it wasn’t the triggering mechanism.
So, I am wondering if anyone has any idea what the triggering mechanism might be? It could be the PACE, which updates automatically, but there are no logs that tell me when that has happened. It could be a change to Windows Update, but I’ve searched for issues and I can’t say that I’ve found any recent upsurge in problems. It could be AT&T, especially if there is some mechanism for ISPs to direct Windows update traffic to preferred servers. I suspect that the problem has something to do with the process of determining the appropriate Windows update server, but I don’t really know much about how Windows Update works.
I can simply leave IPv6 turned off and hope the problem will be resolved in time. But I would be interested in any theories about what is happening here.