So, when I was trying to compile the new router firmware today (I'll talk about this later...), I discovered that the memory was insufficient; upon closer inspection, it only has 16GB? And it says there's only one memory stick? I clearly bought two 16GB sticks...
Upon checking the BIOS, wow, 48GB of RAM... one of the RAM sticks had actually become 32GB. Of course, the RAM didn't just increase for no reason; Windows cleverly detected this issue and only used the other stick...
Using CPU-Z to read memory information, the good news is that the other memory module can still be read; the bad news is that the data is slightly messed up, for example, it might show as 32GB, the serial number might be messed up, the brand might be a strange brand, and so on...
Actually, SPD information corruption isn't exactly news; I'd known about these SPDs for a while. The reason was probably from messing around with OpenRGB shortly after I bought them. Essentially, it's a race condition: OpenRGB attempts to control the memory's RGB (selecting the RGB controller address and writing it), while another program, such as HWINFO64, might try to access the memory SPD (selecting the SPD address and reading it). If these two are mixed up, it might become "selecting the SPD address and writing," which could corrupt the SPD…
I only remembered that this thing seemed to have corrupted the XMP profile and memory information, but it was still basically usable. This time, upon closer inspection, quite a few parts are corrupted…
Of course, we were lucky, since there was still one almost identical memory module that was usable. However, the other SPD was also damaged, but luckily, the critical parts weren't damaged...
For the repair, I mainly used the SPD RW tool. Initially, I thought it could only be used with Arduino, so I looked for other tools, such as the Thaiphoon Burner, but it not only didn't sell but also went out of business and I couldn't buy it… However, I later discovered that SPD RW can directly run SMBus, so I used it to read both sides first, and then compared it with the DDR5 SPD format data, and another similar memory SPD posted by someone, basically correcting the first half of the SPD (the second half is XMP data). After that, write the modified SPD back and reboot, and the remaining 16GB will be back...
The rest of the things, including
Try to get the XMP data back as well. This will probably only be possible by finding other people's SPD dumps online; the XMP data I've seen these days is mostly unreliable.
I donated some money to the author of SPD RW, which saved me the trouble of RMA/buying a new memory stick.
Actually, the CRC is still wrong... I do have the original CRC, so at least I can verify if all the data is correct.
You'll probably have to look for the memory serial number on the sticker on the memory module...
Anyway, it's salvaged for now... This incident teaches us that OpenRGB memory lighting control is extremely dangerous. If you're going to use it, you absolutely must remember to enable SPD write protection in the BIOS... I guess I somehow turned it off before, and then it broke down...
Oh, by the way, Thaiphoon Burner is a piece of junk; the free version not being able to write isn't a big deal, but this thing has an SPD dump collection, and they actually sell it for an extra dollar...