This gets a bit complex, but bear with me. SSDs will always have a write limit, sometimes called a write endurance, where segments or blocks will only be able to endure so many write commands before becoming useless. The architects of the write controllers for SSD design know this and allow for it by overbuilding the size of the device and leaving relocatable blocks for use later on to remap the drive when a block becomes expired. Standard drives do the same basic thing, but in this case you need to use an aftermarket util like chkdsk, or fsck in the UNIX world.
The SSD write profile is such that certain disk space gets written many, many times in the life of the device. The FAT is one example, and the areas where the pointers to fragged files is another(it goes by several names, which aren't important).
So, what tends to happen is that you will run into one of these limitations on writes, and it will be on a critical part of the SSD, such as the FAT/partition table/pointer table which is constantly being written. The only way the OS has to resolve this is to set the stack pointer for that file address to null, and allow the system to crash. The crash dump in MS will contain the location of the dead spot, and then the lower level drive manager utility will attempt to locate the bad block from the crash dump, if not from it's own internal parity checker, and will redirect the block to one of the spares. This allows you to recover, until it happens again.
I don't know how old the laptop is, or how you use it, or if the SSD is one of the newer style which are less susceptible to write endurance locks but the really simple answer may be that it's getting worn out at the FAT/partition/pointer table and will only get worse. As another poster above has said, your best bet is to image the current drive, then replace the SSD, then try to lay down the image again. Failing that, backup all your files, and replace the SSD, then use your MS recovery disk to re-install the OS, and your apps, and then your user data.
Sorry...
