Question Windows 11 fried my pc

[econcepts]

well, this is odd - I have several older PC's with GA-78LMT-USB3 main boards in them. one had a FX-4100 (4 core) and the other had an FX-6100 (six core). I installed windows 11 on my main PC (just vanilla) and imaged it. I loaded the image on the first PC and it seemed to work fine. Played with it all day - at the end of the day it had downloaded an update so I let it update and restart. After saying to hold on it was updating (or whatever that message was), it rebooted but the screen stayed black. Waited for hours, nothing, so I held down the power button, it shut down. Pushed the power button, it came back on, but no beeps, just a black screen. Tried a different, PS, CPU, removing the memory, clear CMOS, removing the battery, removing all the cables. Determined it must be the main board. Now bear in mind that these PC have been running windows 10 just fine for many years. I chucked the mainboard and set the case aside. Booted up the next one to windows 10. Played with it for an hour, it works flawlessly. I set aside an image of windows 10 and loaded the same image of windows 11 on it. Seemed to work perfectly, even activated with a digital license, and no uninstalled devices in device manager. played with it for hours after which it wanted to update, which I did with the exact same unfortunate result. Different PC, power supply, main board, CPU, memory, hdd, case but same model motherboard just one was revision 4.1 (blue board) and one was revision 5 (black board). Two for two on two perfectly reliable, long running PC. Both dead - will not beep or post at all. I think windows 11 murdered them both. Any ideas, I might have missed?

 

[TerryLaze]

I have confirmed that both motherboards have damaged main bios chips that can no longer be flashed.

Have you checked if there is a blind flash procedure for that mobo?
It should be possible to be flashed that way since that's probably how they got destroyed in the first place.

 

[JohnBonhamsGhost]

The backup bios chips are working properly and contain valid images. Since Gigabyte boards only boot from the main bios, the boards are hosed

if these boards were unable to POST due to damaged "main" BIOS, how are you examining the "backup" to ensure it is still intact?

and if you can get that far along why can't you replace the main with the existing intact backup?

 

[johnbl]

if these boards were unable to POST due to damaged "main" BIOS, how are you examining the "backup" to ensure it is still intact?

and if you can get that far along why can't you replace the main with the existing intact backup?

I think he powered the chip with a eeprom reader, read out the contents for the main bios and backup bios. Found that the main bios had a corrupted cell. (file compare from main bios copy to backup bios copy)
Since the gigabyte bios recover just copies the backup bios to the main bios the bad cell that would not program still prevents boot. Only thing you could do for this it to remove the surface mount primary bios and replace it with the same chip. Main question was how the primary bios got corrupted. These new bios chips can be written to almost 10 million times before they fail. ( I remember 50k times versions in the old days) it sounds like a lot but a bad program can do a lot of writes to a single location in a very short time period and the chip can fail.
You can buy replacement bios chips from ebay for $10 to $15 but you would still have to de-solder the old surface mount chip and solder the new one on to it. (or cut its power and make a jumper socket/chip over the old chip)

Only really worth while if you really, really, really had to get the board to boot.
For example, had to recover data from a machine and the data was on a special motherboard raid array. That could not be moved to another machine because of the version of the raid chips on the motherboard.

I think the main point was to find out how it happened to his bios in the first place to prevent future issues.

Microsoft windows can now do firmware updates, it can be risky if the program is not written correctly. IE write all of the updates to a single cell and burn out the cell would be bad.

 

[hotaru.hino]

Microsoft windows can now do firmware updates, it can be risky if the program is not written correctly.

Linux can also do firmware updates. However in the laptop I use Linux on that does this, Linux only stages the update. That is, it doesn't actually do the update, it sets some flag and when the system reboots, it realizes there's a firmware update and then updates the firmware. Not sure how Windows does it, but I can't imagine it being different.

I'd also put the OS firmware updater on low on the list of suspects. If there was a problem with the OS, considering that firmware updates can now be pushed on system builder computers, then it should've been a pretty widespread issue at some point.

 

[TerryLaze]

considering that firmware updates can now be pushed on system builder computers, then it should've been a pretty widespread issue at some point.

He installed windows on one system and then used this installed windows to boot a different system, two of them actually and both got bricked.
This is not something many people do for it to become widespread.

 

[hotaru.hino]

He installed windows on one system and then used this installed windows to boot a different system, two of them actually and both got bricked.
This is not something many people do for it to become widespread.

I'm not referring to what OP did. I'm referring to the quoted text implying that the mechanism to push firmware updates via the OS can be a problem and that's why OP's system was bricked.