From the article:

> I opened the system and reseated everything, including the SSD. No change. I even tested the SSD in another machine to rule it out, and it’s fine too.

But that doesn't mean it's not bad RAM, a bad SSD controller, who knows what... there are only a few of these boxes in the wild regardless, so it's unlikely it can be debugged :(

Considering the number of x86 machines I've come across in fleet deployments that were put into various states of brickdom from Windows Update, I would not be at all surprised if it was a bad update-rollback sequence.

Laptops seem particularly susceptible to whatever (anti) magic Microsoft utilise for their update rollback process, but it happens to every device class seemingly at random. Besides the run of the mill "corrupt files at random in System32", which is common and simple enough to fix with a clean install, I've had a few cases where it appears an attempt at rolling back a BIOS update has been interrupted by the rollback manager and left those machines hard bricked. They could only be recovered by flashing a clean BIOS image with an external programmer and clip (or hand soldering leads), after which they ran without issue.

As much as it's valid to question the unconditional anti-Microsoft mentality, they are still far from infallible and from my experience they are getting notably more unreliable in recent years.

>Almost certainly a soft hardware failure, likely the SSD.

If you actually read the article, you'd know it wasn't. Besides, Windows updates can and do deliver firmware/bios updates.

Considering that when the problems started, many people online were having a similar issue I think it's unlikely it was a hardware failure.