Recent searches
Search options
A few months ago, with seemingly no reason (no hardware changes or incidents) my wife's gaming PC started pausing for 60 seconds+ before POSTing with the VGA fault light on. I tried everything, swapping GPUs, updating / resetting BIOS, replacing the CMOS battery, re-seating RAM and even the CPU itself, nothing worked. But it always POSTed, eventually. It's like it was memory training every time.
A few days ago it just stopped doing it, POSTing immediately like it hasn't done in months. WTAF
It makes me wonder whether Windows updates could cause / resolve something like this. I always assume the BIOS/POST sequence is too isolated for that to be the case, but with UEFI there's much more access from the OS - to the extent that updating a BIOS can now trigger a process in Windows on next boot (like asking you to install motherboard software). And I remember that Windows malware that could exploit your BIOS boot image. So perhaps it's possible?
Either way this has broken my mental model of troubleshooting a PC, I've never seen anything like it. I'm used to POST problems being hardware related, or BIOS settings related, not just randomly appearing after working fine for a couple of years, and then fixing themselves after a few months. 
@sinbad Modern PCs are soooo complex it's a wonder they boot at all.
@sinbad Had any USB devices changed? I've had very long bios times when I have certain USB devices plugged in while booting. (Mainly certain flash drives)
@kojack Nope, she did get some new Steelseries headphones with a dongle 2 months earlier but it was fine. And I tried booting without anything except a keyboard attached and it was the same
@sinbad So... I USED to have ONE computer with Windows, for work purposes
A random day I inadvertently turned on this PC and, completely unattended, Windows decided to:
- update itself
- reboot the machine
- initiate an UEFI update
Except for me the UEFI update failed and bricked the entire computer (it was an ASUS mini-PC that has no sort of dual BIOS or recovery mechanism)
So it's very possible that Windows is messing with UEFI software entirely unprompted
I don't have Windows anymore smh
@sinbad I was like a month or two from the warranty expiring. In the end got sent an entire new PC but... yeah.... Absolute nonsense
@sinbad I have a Dell at work and I occasionally see a bios update in the Windows Update list. Not sure which other brands would want to pay to be included in Windows Update.
@jkaniarz SteelSeries include driver updates in the Windows Update list, that's the first time I've seen a 3rd party who told me to go there for drivers. This is an MSI board and looking at their tech support their *laptops* do have BIOS updates via Windows update. I had to update the BIOS itself manually, not that it made any difference. It's like there's something in the higher layers of the BIOS/UEFI or something that Windows can affect
@sinbad definitely possible. Windows installs its own boot loader regardless of whether you're on EUFI or BIOS, hence why with a dual boot you have to install Windows before anything else, otherwise it just replaces the loader your other O/S installs with a loader that doesn't let you boot to anything else. So it makes sense that it'd be able to change that software at any point.
60 seconds though, doesn't sound like it'd be a malicious thing. Could be sanity checking something? Or clock skew?
@dev_ric seemed most like memory training but it shouldn’t be doing it all the time, especially at stock speeds. But, it’s magically fixed now 
@sinbad yeah, and if I remember rightly, DOS/Windows at least tells you when it's doing memcheck stuff?
Sure this isn't the first time she's booted that device since the clocks changed a couple weeks ago? And sure it didn't start happening after the previous change? If it's set to GMT instead of BST then that'd be causing a skew for 6 months every year, and I've seen those cause short boot hangs waiting for a time dependant daemon to give up and return execution. Granted not normally so early.
@dev_ric No, it doesn't line up with that (started early July, fixed itself early Dec). It's before the POST so Windows has no involvement. The only thing it could have done is to modify the UEFI settings somehow so that on next POST it does something different; it's not actively involved at that point
@sinbad before Windows doesn't necessarily mean before Microsoft code though. As far as I understand it, UEFI is fast because rather than probing the drives for an MBR and handing over to that, it just executes an EFI at a pre-configured location but the actual EFI can be anything. I mean... Obviously its purpose is to spin up everything else and hand over to the 'real' O/S, but programmatically it's just an executable like anything else. So if Windows dumps its own EFI for boot, it gets control
@sinbad not that I don't trust Microsoft or anything 
@dev_ric ugh, can we go back to old skool BIOSes please. So yeah this is probably what caused it, but it definitely wasn't BST related
@sinbad BIOS and IDEs with actual physical jumpers to define their boot order. Everything just worked with those!
Bit problematic if you want more than 4 drives mind 