So, it turns out that I was wrong about the motherboard being the cause of my recent Windows hibernate issues. The failure to resume on hibernate still occurred after that, although perhaps more rarely. There's always the possibility that there's some strange problem common to the chipset (both boards are based on Intel's H87 chipset). However, since I've not seen anyone other reporting of this, I'm going to assume it's another piece of hardware to blame.
I spent several hours running memtest86+ on the RAM and it didn't show up any problems. I also couldn't find any reports of the graphics card (Radeon 7870) or the Catalyst drivers causing hibernate issues, so my suspicion has moved to the solid state drive. (Apart from the CPU itself and the DVD drive, there's nothing else in the PC!) Because of this, I needed to return the SSD and this, of course, meant that I had to ensure that any data on it was wiped completely.
I'd previously written about using DBAN to wipe drives. What I learned this week is that using the ATA Secure Erase function is the best way to go. This is particularly the case for SSDs due to the way in which they write data.
How to use hdparm to do this is well explained here: an easy way is to access hdparm is via a Linux boot CD.
The important things to remember are to make sure that you've selected the correct drive (the safest way is to only have the drive connected which you want to be wiped) and that you might have to "unfreeze" your drive by power cycling it to allow you to execute the hdparm commands successfully.
For the SSD I was using, the secure erase took about 45 seconds. If you worry about whether the manufacturer has implemented this function correctly, you might also want to write over the drive with random data twice using shred or dd.