Speccy corrupting SPD info?

I've put XP on a neighbour's old Toshiba Tecra 8200 laptop and it's just killed a third SODIMM. Symptoms are it's running fine for hours until you restart it, when it either doesn't see the module or fails to boot if it's just the one module installed. The original Toshiba 128MB module was the first to die.

The common factor in two out of the three deaths was Speccy being run at some time in the session immediatley before it died - the third time there were two modules fitted so it wasn't clear exactly when the module failed. Nothing clever or tricky is being run - no memory testers or the like.

Which makes me wonder if Speccy is corrupting the module's SPD info.

I can't say exactly which version was being run as the laptop is dead ATM as I've run out of modules, but it's probably the latest, downloaded directly to the laptop a week or so back.

So is it possible for Speccy to corrupt the SPD data?

<edit> Perhaps I should rephrase that to say: So is it possible that running Speccy is somehow causing the SPD data to be corrupted?

Graham

Answering my own question, it looks like the Tecra 8200 has an issue with reading the SPD data that the BIOS avoids.

According to www.techsupportforum.com/forums/f25/memory-failure-after-memory-write-benchm

ark-7435.html (watch the wrap) the defunct system info prog AIDA32 kills SODIMMs in exactly the same way.

I certainly won't be running Speccy or any other prog that reads the SPD data.

Graham

so is the bug in the MB then?

Could be. An SMBus controller bug that the BIOS knows about and avoids/works around when it reads the SPD, or possibly one in the Windows XP SMBus driver. I used the XP in-box drivers and not the Toshiba ones, which include a "Common Module" driver so it's possible that this deals with the issue.

But now I've figured out what seems to be happening, albeit at a cost of three SODIMMs, and more importantly how to avoid it happening again, I'll leave it at that as it's a freebie job for a neighbour.