I disabled power management and also disabled scheduled jobs from iDrive backup. After two or three days no outages. After a couple of more days of no outages I will reintroduce the backup engine to see what happens. It is suspicious that this outage always occurs overnight when I am not actively using the machine, which is when both power management and backups would kick in. I have also turned off the WiFi.
Yes, that is what I was referring to. More specifically, I was referring to the fact that both connections would use the same gateway, which can sometimes run into problems.
That said, at least on my router, there is no real separation in address space for wired versus non-wired. The addresses that I’ve seen assigned by DHCP is just the next one available, with no respect to whether the newest connection is Wi-Fi or wired.
(That said, I always wind up using the router to assign a specific IP to a specific MAC address. Linux/Android support for SMB works better with fixed IP addresses rather than trying to use network names. Things that I struggle with just work if I do it that way.)
Any update on what was causing the issue, I’m assuming iDrive? I’m having the exact same issues on a Gigabyte z490 and have spent way too many hours trying to find a solution.
Here’s a slightly different wrinkle that may be relevant.
I have had a series of Microsoft Surface devices under Win 8 and now Win10. My latest is a Pro7. They normally connect to Wi-Fi. After enough sleep / wake cycles (10 to 20 typically), that connection quits working. The connect attempt hangs with a message “checking network properties”. Which after a couple minutes will time out. Any further reconnect attempts have the same outcome.
A reboot is always a 100% cure.
Since these devices are all 100% MSFT hardware, all are running the factory installed OS + all the current auto-installed updates, this happens predictably on different models of Surface, but has happened to every one I own(ed), I conclude that whatever is busted is in the Windows networking stack, not in my hardware.
I also conclude tentatively that it’s not fixable by diddling with settings. Since all the relevant settings are box stock.
it just does that.
The issue occurred with iDrive disabled, I’m sorry to say.
I have tried a lot of stuff and the incidents have become less frequent but still have not stopped completely.
That is what Gigabyte would have me believe. But if that’s true, why doesn’t every Windows machine have this problem?
Darn good question. How many machines are left running but are sleep/wake/sleep enough times between reboots or airplane mode on/off/on/off enough times between reboots?
Because nothing is crashing (that we can see at least), we do not know that MSFT’s crash logging system is even telling them about this problem. The network doesn’t connect, the user reboots, and the Windows Error Reporting infrastructure is non the wiser.
I wonder if a reboot would be a preemptive strike. It did not occur to me to reboot frequently to see if that fixes it. But I hate rebooting because I have so much stuff open at once.
FWIW I have this exact same problem with an ASUS Z490 motherboard. I think the common element is the piece of garbage Intel I225-V NIC that has known hardware issues and cannot be fixed short of replacing with the V2 NIC. Mine crashes from iDrive and randomly as well. Google the IPG issue this card has and press your mobo manufacturer for a replacement board with an updated NIC. Why on earth Intel was trying to press their luck with this 2.5GB standard is beyond me.
Welcome to the Straight Dope!
Thanks for that update. My problem has disappeared as mysteriously as it began. I had tweaked a few things as mentioned earlier but I never did get a positive diagnosis. I’ll be surprised if Gigabyte will send me a new board just because I complain about the NIC but I guess it can’t hurt to try. They strenuously denied it was their problem when I contacted them at first.